Menu
▾
▴
sword-app-tech — Mailing list for discussion of SWORD implemenation and development.
You can subscribe to this list here.
| 2008 |
Jan
(22) |
Feb
(8) |
Mar
(9) |
Apr
(4) |
May
(17) |
Jun
(29) |
Jul
(11) |
Aug
(13) |
Sep
(17) |
Oct
(14) |
Nov
(41) |
Dec
(8) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2009 |
Jan
(17) |
Feb
(26) |
Mar
(18) |
Apr
(1) |
May
(11) |
Jun
(20) |
Jul
(5) |
Aug
|
Sep
|
Oct
|
Nov
(3) |
Dec
|
| 2010 |
Jan
(23) |
Feb
(7) |
Mar
(9) |
Apr
(13) |
May
(5) |
Jun
|
Jul
(3) |
Aug
(5) |
Sep
|
Oct
(1) |
Nov
(3) |
Dec
|
| 2011 |
Jan
(3) |
Feb
|
Mar
(2) |
Apr
(1) |
May
|
Jun
(14) |
Jul
(22) |
Aug
(1) |
Sep
(2) |
Oct
(11) |
Nov
(11) |
Dec
(35) |
| 2012 |
Jan
(17) |
Feb
(12) |
Mar
(41) |
Apr
(40) |
May
(41) |
Jun
(27) |
Jul
(9) |
Aug
(1) |
Sep
|
Oct
(6) |
Nov
|
Dec
(11) |
| 2013 |
Jan
|
Feb
(4) |
Mar
(2) |
Apr
(8) |
May
(1) |
Jun
(18) |
Jul
(10) |
Aug
(16) |
Sep
(2) |
Oct
(1) |
Nov
(14) |
Dec
(11) |
| 2014 |
Jan
(7) |
Feb
(2) |
Mar
|
Apr
|
May
(8) |
Jun
(1) |
Jul
(7) |
Aug
(10) |
Sep
(8) |
Oct
(8) |
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
(2) |
Mar
(2) |
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(4) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(6) |
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
(4) |
| 2018 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Scott Y. <sco...@an...> - 2008-11-04 23:31:49
|
Hi Stuart, Some of the issues we encountered have been addressed by the 1.3 spec (i.e. the user-agent, packaging, and sword types) which is great. I also had earlier provided some feedback regarding what we'd find useful in a DSpace implementation based on trying to implement a SWORD deposit of a specific METS profile packaging format for OJS journals. The limitations in the current DSpace implementation from our point of view are: 1. Assumption a SWORD collection equates to a DSpace collection The assumption a SWORD collection equates to a DSpace collection limits the package handling (either must force a mapping to a collection or work around it with hacks) and also prohibits other DSpace structures being exposed as collections. For example, when submitting an entire issue or journal, the target SWORD (ATOM) collection could be a DSpace community as single or multiple collections may be created as part of the submission. In addition, in the future should item or file-level submissions be required, a SWORD collection could be equivalent to an item or bundle. 2. Cannot handle multiple package formats DSpace METS ingester is the only supported package format. Currently the SWORDIngesterFactory returns the single DSpace METS handler, but ideally would instantiate an ingester based on package format and user agent (similar to how the DSpace Packager works but instantiates using a combination of SWORD deposit information and DSpace config). 3. Ingestion assumptions For SWORD to work effectively with the PackagerIngester classes some limitations in the packager interfaces either need to be removed or somehow bypassed through additional SWORD-friendly methods. See 3a and 3b for more detail. 3a. PackageIngester assumes 1 package = 1 DSpace item The assumption of the PackageIngester interface to ingest a single item to a collection causes issues when dealing with multi-item packages. The curent implementation requires a WorkspaceItem to be returned for subsequent install/processing/whatever whereas for compound packages this is not likely the case - the entire package would be unpacked and mapped to repository-specific structures within the context of the ingester. While this is a problem in the core code, it limits the flexibility of deposits if used with SWORD. 3b. PackageIngester assumes ingestion to a collection The assumption for a PackageIngester to have a deposit target of a DSpace Collection creates issues when wanting to ingest at a higher or lower level. It may be worth considering changing the ingest signature to be a DSpaceObject rather than Collection and let the implementers of PackageIngesters validate any object passed. (This also would require changes to the Packager class). The return value may also be better as a DSpaceObject, array of DSpaceObject or even a DepositRespomse so objects other than items can be returned (void or boolean are other options). Alternatively some optional SWORD-friendly methods could be added to the ingester interface to allow package ingester classes to support SWORD operations (e,g, myPackageIngester.getDepositResponse(), myPackageIngester.getDepositedObjects()) This could also lend itself to a nicer means of determining the appropriate DSpaceATOMEntry class to invoke during the deposit response as these need to differ based on what happens during ingest and what has been ingested. 4. Cannot support custom Service Documents and Deposit Responses We need to be able to provide Service Documents based on package format and user agent so a mechanism to allow configuration of service document classes is needed. Similarly for deposit responses which will vary based on the client (user-agent) and package being submitted (and will probably need to be created within the PackageIngester classes). The only other thing I'd suggest is that the reference implementations across Fedora, DSpace, EPrints, whatever have their service document and deposit responses aligned as closely as possible. This will make life easier for clients handling responses from SWORD Servers on the different platforms. I think this is pretty much ok in the current implementations, we didn't have any issues related to this, but just thought I'd mention it. I've also had a brief look at the Fedora side of things and I like the look of the FileHandler plugin setup but haven't really had a chance to code against it as yet. It seems a similar idea to the PackageIngester setup in DSpace and the use of the package format to determine the handler to instantiate provides some of the flexibility we need. We're intending to push SWORD in conjunction with our METS profiles to help provide some sort of consistency across deposit services, so all the work you SWORD guys do and continue to do is really appreciated. Any queries regarding the above feel free to get in touch. Scott. Stuart Lewis wrote: > Hi Scott, > > >> On a completely different topic, are the DSpace and Fedora SWORD >> implementations being updated to 1.3 as part of the SWORD 2 project? >> > > Yes. > > The three parties involved in these two implementations are due to have a > teleconference about the work soon, so if there's input you'd like to give > us before we start, that would be great. > > Thanks, > > > Stuart > _________________________________________________________________ > > Gwasanaethau Gwybodaeth Information Services > Prifysgol Aberystwyth Aberystwyth University > > E-bost / E-mail: Stu...@ab... > Ffon / Tel: (01970) 622860 > _________________________________________________________________ > > > |
|
From: Stuart L. <sd...@ab...> - 2008-10-31 07:34:23
|
Hi Scott,
> On a completely different topic, are the DSpace and Fedora SWORD
> implementations being updated to 1.3 as part of the SWORD 2 project?
Yes.
The three parties involved in these two implementations are due to have a
teleconference about the work soon, so if there's input you'd like to give
us before we start, that would be great.
Thanks,
Stuart
_________________________________________________________________
Gwasanaethau Gwybodaeth Information Services
Prifysgol Aberystwyth Aberystwyth University
E-bost / E-mail: Stu...@ab...
Ffon / Tel: (01970) 622860
_________________________________________________________________
|
|
From: Scott Y. <sco...@an...> - 2008-10-31 00:49:49
|
Hi, For some reason I haven't been getting the app-tech digest so I've missed a couple of messages, it still says I'm subscribed so not sure what's going on. So this email is a bit late, sorry. On the SWORD types document I think it would also be useful to specify the X-Packaging and acceptPackaging and packaging values associated with all registered values to remove any possible discrepancies between implementations. Probably also need to be clearer on the "URI" column - i.e. namespace URI or ?? Also given that current reference implementations make use of DSpace METS and Fedora METS/FOXML, should they be added to the known types list? The process for adding new types I guess depends on whether this is going to be a managed registry post-SWORD2, but a minimus set of requirements could be specified in order to create a new registry entry e.g. name, description, namespace URI, specification URI, contact point, version, other? On a completely different topic, are the DSpace and Fedora SWORD implementations being updated to 1.3 as part of the SWORD 2 project? Scott. |
|
From: Stuart L. <sd...@ab...> - 2008-10-28 07:24:19
|
Hi all, I've just finished version 0.2 of the SWORD APP client library: - http://php.swordapp.org/ It still only works with SWORD version 1.2, I'll upgrade it to work with 1.3 once we have some upgraded servers working to test it against. Included in version 0.2 is a packager to package items up in the mets/swap format. This was needed for the Facebook client so that users can upload metadata and a file, rather than having to have a pre-built package. The Facebook client which uses this library is now in the 90% finished stage - it works, but isn't particularly robust. If anyone wants to try it, give me a shout and I'll provide you with a username and password to my test SWORD server which can accept deposits. It does the web 2.0 thing of notifying your friends that you have made a deposit, along with the URL of the item. Now it needs a few more features such as storing a list of your deposits to look at later, and the ability to list (from within the application) deposits made by your friends. Any other suggestions of what it should do will be gratefully received. Stuart _________________________________________________________________ Gwasanaethau Gwybodaeth Information Services Prifysgol Aberystwyth Aberystwyth University E-bost / E-mail: Stu...@ab... Ffon / Tel: (01970) 622860 _________________________________________________________________ |
|
From: Jim D. <oj...@ca...> - 2008-10-21 16:36:45
|
Hi Stuart, 2008/10/21 Stuart Lewis <sd...@ab...>: > We've started implementing version 1.3 now, and have come to nested service > descriptions section, and have a few questions about it... > > The example shows: > > <collection > href="http://www.myrepository.ac.uk/atom/geography-collection" > > <atom:title>My Repository : Geography Collection</atom:title> > <accept>application/zip</accept> > <sword:collectionPolicy>Collection Policy</sword:collectionPolicy> > <dcterms:abstract>Collection description</dcterms:abstract> > <sword:acceptPackaging > q="0.8">http://purl.org/net/sword-types/bagit</sword:acceptPackaging> > <sword:service>http://www.myrepository.ac.uk/atom/geography-collection/serv > ice.atomsvc</sword:service> > </collection> > > Could you provide an example of what would appear in the nested service > description? (e.g. What would the workspace definition look like?) > > From the description of how they are supposed to work, I would have imagined > the collection section to be empty other than the reference to the nested > description. It seems messy to have descriptions in two places for the same > collection. How would precedence be decided? As a general remark, it wouldn't be the only time data is duplicated in AtomPub, e.g. Entry elements in their own documents as well as in feed documents. However I would imagine that the nested service doc in your example wouldn't reproduce the geography-collection, but would list "SmithGroupCollection", "JonesGroupCollection" etc etc. > Could we even go as far as to make the service URL part of the <collection> > tag, and to forbid the splitting of the collection definition over two > documents? > > <collection href="http://www.myrepository.ac.uk/atom/geography-collection" > sword:service=" > http://www.myrepository.ac.uk/atom/geography-collection/service.atomsvc" /> That would be possible, but it seems a little less clean than a new namespaced element. I don't know how widespread support for properly namespaced atts is. Best regards, jim |
|
From: Stuart L. <sd...@ab...> - 2008-10-21 13:02:32
|
Hi Jim,
We've started implementing version 1.3 now, and have come to nested service
descriptions section, and have a few questions about it...
The example shows:
<collection
href="http://www.myrepository.ac.uk/atom/geography-collection" >
<atom:title>My Repository : Geography Collection</atom:title>
<accept>application/zip</accept>
<sword:collectionPolicy>Collection Policy</sword:collectionPolicy>
<dcterms:abstract>Collection description</dcterms:abstract>
<sword:acceptPackaging
q="0.8">http://purl.org/net/sword-types/bagit</sword:acceptPackaging>
<sword:service>http://www.myrepository.ac.uk/atom/geography-collection/serv
ice.atomsvc</sword:service>
</collection>
Could you provide an example of what would appear in the nested service
description? (e.g. What would the workspace definition look like?)
>From the description of how they are supposed to work, I would have imagined
the collection section to be empty other than the reference to the nested
description. It seems messy to have descriptions in two places for the same
collection. How would precedence be decided?
Could we even go as far as to make the service URL part of the <collection>
tag, and to forbid the splitting of the collection definition over two
documents?
<collection href="http://www.myrepository.ac.uk/atom/geography-collection"
sword:service="
http://www.myrepository.ac.uk/atom/geography-collection/service.atomsvc" />
Thanks,
Stuart
_________________________________________________________________
Gwasanaethau Gwybodaeth Information Services
Prifysgol Aberystwyth Aberystwyth University
E-bost / E-mail: Stu...@ab...
Ffon / Tel: (01970) 622860
_________________________________________________________________
|
|
From: Adrian S. <a.s...@uk...> - 2008-10-20 09:03:13
|
Hi Sword-App-Techers As you're probably already aware, Jim Downing has finished version 1.3 of the SWORD application profile and this has now been released (http://wwmm.ch.cam.ac.uk/~ojd20/sword-profile-1.3-20081007.html ). An unresolved issue raised in one or two responses to the release is how to handle SWORD-TYPES. Jim has kindly put together an initial structure document at http://wwmm.ch.cam.ac.uk/~ojd20/sword-type-1.0-20081010.html and we would now like to invite some discussion about what should constitute a package type and how or whether changes should be managed. All contributions to the debate gratefully received. Cheers Adrian and Julie SWORD Project Managers __________________________________ Adrian Stevenson UKOLN Research and Development Team University of Bath Bath BA2 7AY UK Tel: +44 (0) 161 445 4934 Email: a.s...@uk... WWW: http://www.ukoln.ac.uk/ |
|
From: Ed S. <eh...@po...> - 2008-10-08 13:01:07
|
On Wed, Oct 8, 2008 at 6:43 AM, Jim Downing <oj...@ca...> wrote: > In a nutshell, yes. That makes me a bit sad, since Atom feeds are perhaps the best understood (by the general technical population) part of SWORD ... at least in my imaginary universe of technical people. /me throws caution to the wind and casts a +1 anyway (not sure I count) //Ed |
|
From: Jim D. <oj...@ca...> - 2008-10-08 10:44:05
|
Hi Ed, 2008/10/8 Ed Summers <eh...@po...>: > It's great to see SWORD moving forward, especially in this clear and > compact format. > > I guess it might be a bit late to ask questions (since you are > voting). I was just wondering if any more information is available > about SWORD-TYPES, which sword:packaging and sword:acceptPackaging > rely on? It isn't available yet. I'll pull together a starter for 10 based on the formats enumerated in the 1.2 spec, then I'd imagine there will have to be a fair amount of discussion of what to add as part of the SWORD2 project. > Also, I'm kind of curious about why implementations SHOULD provide > atom feeds at collection URIs, instead of MUST as it is in AtomPub. > Was it seen as too high a barrier to entry? In a nutshell, yes. Best regards, jim |
|
From: Adrian S. <a.s...@uk...> - 2008-10-08 10:37:23
|
Look great Stuart. Ta for the link. All good for the SWORD project. Adrian __________________________________ Adrian Stevenson UKOLN Research and Development Team University of Bath Bath BA2 7AY UK Tel: +44 (0) 161 445 4934 Email: a.s...@uk... WWW: http://www.ukoln.ac.uk/ On 8 Oct 2008, at 07:06, Stuart Lewis wrote: > In case you've not seen this, some good news from Microsoft: > > http://savas.parastatidis.name/2008/10/07/86c8cc56-d3e4-49d9-985f-2cfd011f6d > 54.aspx > > Or http://tinyurl.com/3t9dtz > > (Savas has written an *Open Source* SWORD deposit tool for MS Word > 2007) > > Cheers, > > > Stuart > _________________________________________________________________ > > Gwasanaethau Gwybodaeth Information Services > Prifysgol Aberystwyth Aberystwyth University > > E-bost / E-mail: Stu...@ab... > Ffon / Tel: (01970) 622860 > _________________________________________________________________ > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win > great prizes > Grand prize is a trip for two to an Open Source event anywhere in > the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > sword-app-tech mailing list > swo...@li... > https://lists.sourceforge.net/lists/listinfo/sword-app-tech |
|
From: Ed S. <eh...@po...> - 2008-10-08 09:58:12
|
It's great to see SWORD moving forward, especially in this clear and compact format. I guess it might be a bit late to ask questions (since you are voting). I was just wondering if any more information is available about SWORD-TYPES, which sword:packaging and sword:acceptPackaging rely on? Also, I'm kind of curious about why implementations SHOULD provide atom feeds at collection URIs, instead of MUST as it is in AtomPub. Was it seen as too high a barrier to entry? I apologize in advance if these questions have been asked and answered before. //Ed |
|
From: Stuart L. <sd...@ab...> - 2008-10-08 06:12:38
|
In case you've not seen this, some good news from Microsoft: http://savas.parastatidis.name/2008/10/07/86c8cc56-d3e4-49d9-985f-2cfd011f6d 54.aspx Or http://tinyurl.com/3t9dtz (Savas has written an *Open Source* SWORD deposit tool for MS Word 2007) Cheers, Stuart _________________________________________________________________ Gwasanaethau Gwybodaeth Information Services Prifysgol Aberystwyth Aberystwyth University E-bost / E-mail: Stu...@ab... Ffon / Tel: (01970) 622860 _________________________________________________________________ |
|
From: Scott Y. <sco...@an...> - 2008-10-07 23:06:03
|
Hi Jim, Sorry, just got back from leave, so kind of late but +1 (I assume others have voted, this listserv seems to just mail me randomly with out-of-date emails) Scott. > > Message: 7 > Date: Tue, 7 Oct 2008 15:23:44 +0100 > From: "Jim Downing" <oj...@ca...> > Subject: [sword-app-tech] SWORD 1.3 release vote > To: swo...@li... > Message-ID: > <2ab...@ma...> > Content-Type: text/plain; charset=UTF-8 > > OK, there haven't been any major comments on the latest draft, so > please could we have votes on releasing > > http://wwmm.ch.cam.ac.uk/~ojd20/sword-profile-1.3-20081007.html > > as the 1.3 release of the SWORD specification, please? The only change > from the last draft is that "University of Aberystwyth" has been > corrected to "Aberystwyth University". > > Voting closes Tuesday 14th October 1700 UTC. Vote is decided along the > Apache guidelines, simple majority, with at least 3 votes required. > > +1 > > jim > > > > ------------------------------ > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > > ------------------------------ > > _______________________________________________ > sword-app-tech mailing list > swo...@li... > https://lists.sourceforge.net/lists/listinfo/sword-app-tech > > > End of sword-app-tech Digest, Vol 10, Issue 1 > ********************************************* > > |
|
From: Stuart L. <sd...@ab...> - 2008-10-07 18:30:39
|
+1 (What needs doing with the lack of a '[SWORD-TYPES]' document? Do we perhaps need am updatable registry on the SWORD web site rather than a published document?) On 07/10/2008 15:23, "Jim Downing" <oj...@ca...> wrote: > OK, there haven't been any major comments on the latest draft, so > please could we have votes on releasing > > http://wwmm.ch.cam.ac.uk/~ojd20/sword-profile-1.3-20081007.html > > as the 1.3 release of the SWORD specification, please? The only change > from the last draft is that "University of Aberystwyth" has been > corrected to "Aberystwyth University". > > Voting closes Tuesday 14th October 1700 UTC. Vote is decided along the > Apache guidelines, simple majority, with at least 3 votes required. > > +1 > > jim > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > sword-app-tech mailing list > swo...@li... > https://lists.sourceforge.net/lists/listinfo/sword-app-tech |
|
From: Jim D. <oj...@ca...> - 2008-10-07 14:34:47
|
OK, there haven't been any major comments on the latest draft, so please could we have votes on releasing http://wwmm.ch.cam.ac.uk/~ojd20/sword-profile-1.3-20081007.html as the 1.3 release of the SWORD specification, please? The only change from the last draft is that "University of Aberystwyth" has been corrected to "Aberystwyth University". Voting closes Tuesday 14th October 1700 UTC. Vote is decided along the Apache guidelines, simple majority, with at least 3 votes required. +1 jim |
|
From: Scott Y. <sco...@an...> - 2008-09-29 22:10:23
|
Hi Glen, Yes, fixed that up - I posted a follow up to the lists the same day as this message (pasted below since Sourceforge appears to not want to show it - I really really really hate Sourceforge) Scott. ================== copy of previous message ============= Hi, Further to this, the problem looks to be caused by the SWORD Server using the MDTYPE as the ID meaning that where more than one dmdSec of the same metadata type occurs (as in our METS document), the METS document will not load. I think if the conversion to FOXML is generating IDs it needs to ensure they are unique. For a temporary fix, in METSObject.java we changed the line: tDatastreamList.add(new XMLInlineDatastream(tMDN ame, tNewMDDoc)); to: tDatastreamList.add(new XMLInlineDatastream(tMDN ame + tDMDSecEl.hashCode(), tNewMDDoc)); This got the METS package loaded without dramas. Once loaded, the MODS and file datastreams do not appear to be linked. For example my files are identified by what looks like the OWNERID, but the associated MODS is just known as "MODS12345 File". The other issue was the order of the issues/sections/articles as defined in the structMap is lost, meaning the default METS ingest does not preserve relations between the created datastreams, the only relation expressed is between the Fedora object and its owning collection via the RELS-EXT object. We could get around this problem by implementing a specific/more targetted file handler (e.g JournalMETSFileHandler) but I'm not sure whether this is considered a general issue or not (i.e. not being able to express the relationship of one datastream with other datastreams in the same object). There's a screenshot of the loaded object at http://pilot.apsr.edu.au/public/sword/viewItemIndex.htm (Note none of the object links will work since my laptop won't be operational, this is just to hopefully provide some clarity to the above). The METS package being loaded can be found at http://pilot.apsr.edu.au/public/sword/ojs-mets.xml. Note this is all for info in case it's of use for any coding updates developed under SWORD 2. There is a related project currently being developed at Monash University to deposit Crystallography datasets to a Fedora repository via SWORD which is likely to come across the same issues as they are wrapping experiment, dataset and ancillary data metadata and files within a similar METS package structure (see background and proposal at http://tardis.edu.au/wiki/index.php/Main_Page). Scott. Glen Robson wrote: > Hi, > > The METS ingest package is pretty basic and I think its falling over > because you have multiple MODS sections in your METS document. When > the METS document is submitted it extracts each metadata section into > its own datastream in Fedora and unfortunately uses the value of > MDTYPE to specify that datastream name so this can cause conflicts. > > Ill work on a fix as soon as possible and let you know when its > available. > > Thanks > > Glen > > p.s. If you can't wait the class you need to look at is > org.purl.sword.server.fedora.utils.METSObject and the method is > getMetadataDatastreams() > > On 26 Sep 2008, at 01:22, Scott Yeadon wrote: > >> Hi, >> >> We're just testing out the Fedora SWORD implementation. We are testing >> scenario #4 (see >> http://www.ukoln.ac.uk/repositories/digirep/index/SWORD_access#Fedora) >> with one of our journal METS packages, but getting an error which looks >> to be caused by some conversion to FOXML. The log output is at >> http://pilot.apsr.edu.au/public/sword/catalina.out. If the Fedora >> implementors are on this list can they provide any insight into what is >> happening? Thanks. >> >> Scott. >> >> ------------------------------------------------------------------------- >> >> This SF.Net email is sponsored by the Moblin Your Move Developer's >> challenge >> Build the coolest Linux based applications with Moblin SDK & win >> great prizes >> Grand prize is a trip for two to an Open Source event anywhere in the >> world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> _______________________________________________ >> sword-app-tech mailing list >> swo...@li... >> https://lists.sourceforge.net/lists/listinfo/sword-app-tech > > |
|
From: Glen R. <gle...@ll...> - 2008-09-29 09:29:10
|
Hi, The METS ingest package is pretty basic and I think its falling over because you have multiple MODS sections in your METS document. When the METS document is submitted it extracts each metadata section into its own datastream in Fedora and unfortunately uses the value of MDTYPE to specify that datastream name so this can cause conflicts. Ill work on a fix as soon as possible and let you know when its available. Thanks Glen p.s. If you can't wait the class you need to look at is org.purl.sword.server.fedora.utils.METSObject and the method is getMetadataDatastreams() On 26 Sep 2008, at 01:22, Scott Yeadon wrote: > Hi, > > We're just testing out the Fedora SWORD implementation. We are testing > scenario #4 (see > http://www.ukoln.ac.uk/repositories/digirep/index/SWORD_access#Fedora) > with one of our journal METS packages, but getting an error which > looks > to be caused by some conversion to FOXML. The log output is at > http://pilot.apsr.edu.au/public/sword/catalina.out. If the Fedora > implementors are on this list can they provide any insight into what > is > happening? Thanks. > > Scott. > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win > great prizes > Grand prize is a trip for two to an Open Source event anywhere in > the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > sword-app-tech mailing list > swo...@li... > https://lists.sourceforge.net/lists/listinfo/sword-app-tech |
|
From: Scott Y. <sco...@an...> - 2008-09-26 04:59:45
|
Hi, Further to this, the problem looks to be caused by the SWORD Server using the MDTYPE as the ID meaning that where more than one dmdSec of the same metadata type occurs (as in our METS document), the METS document will not load. I think if the conversion to FOXML is generating IDs it needs to ensure they are unique. For a temporary fix, in METSObject.java we changed the line: tDatastreamList.add(new XMLInlineDatastream(tMDN ame, tNewMDDoc)); to: tDatastreamList.add(new XMLInlineDatastream(tMDN ame + tDMDSecEl.hashCode(), tNewMDDoc)); This got the METS package loaded without dramas. Once loaded, the MODS and file datastreams do not appear to be linked. For example my files are identified by what looks like the OWNERID, but the associated MODS is just known as "MODS12345 File". The other issue was the order of the issues/sections/articles as defined in the structMap is lost, meaning the default METS ingest does not preserve relations between the created datastreams, the only relation expressed is between the Fedora object and its owning collection via the RELS-EXT object. We could get around this problem by implementing a specific/more targetted file handler (e.g JournalMETSFileHandler) but I'm not sure whether this is considered a general issue or not (i.e. not being able to express the relationship of one datastream with other datastreams in the same object). There's a screenshot of the loaded object at http://pilot.apsr.edu.au/public/sword/viewItemIndex.htm (Note none of the object links will work since my laptop won't be operational, this is just to hopefully provide some clarity to the above). The METS package being loaded can be found at http://pilot.apsr.edu.au/public/sword/ojs-mets.xml. Note this is all for info in case it's of use for any coding updates developed under SWORD 2. There is a related project currently being developed at Monash University to deposit Crystallography datasets to a Fedora repository via SWORD which is likely to come across the same issues as they are wrapping experiment, dataset and ancillary data metadata and files within a similar METS package structure (see background and proposal at http://tardis.edu.au/wiki/index.php/Main_Page). Scott. Scott Yeadon wrote: > Hi, > > We're just testing out the Fedora SWORD implementation. We are testing > scenario #4 (see > http://www.ukoln.ac.uk/repositories/digirep/index/SWORD_access#Fedora) > with one of our journal METS packages, but getting an error which > looks to be caused by some conversion to FOXML. The log output is at > http://pilot.apsr.edu.au/public/sword/catalina.out. If the Fedora > implementors are on this list can they provide any insight into what > is happening? Thanks. > > Scott. > |
|
From: Scott Y. <sco...@an...> - 2008-09-26 00:22:28
|
Hi, We're just testing out the Fedora SWORD implementation. We are testing scenario #4 (see http://www.ukoln.ac.uk/repositories/digirep/index/SWORD_access#Fedora) with one of our journal METS packages, but getting an error which looks to be caused by some conversion to FOXML. The log output is at http://pilot.apsr.edu.au/public/sword/catalina.out. If the Fedora implementors are on this list can they provide any insight into what is happening? Thanks. Scott. |
|
From: Glen R. <gle...@ll...> - 2008-09-16 08:16:09
|
Hi, The changes look great but I've got a couple of small points: * In section 1.1 it says: "The q attribute MUST have a short floating-point numberic value between 0 and 1, where 0 indicates no support (equivalent to omitting that sword:acceptPackaging element completely) and 1 indicates full support." Should it say something about preference rather than support? Should 0 mean I'll take it, but I don't understand what it is but Ill store the bits on disk and 1 means I understand and prefer this type of data. * In the example 1.4 should type="application/zip" be in bold? * In part B there are two mentions of editing a resource in sections 5.4 and 9.3 and I know these are in the app spec but could we add a "see section 9.3" to the end of 5.4 to avoid confusion. On 15 Sep 2008, at 10:23, Stuart Lewis wrote: > Hi Jim, > >> TODO: >> * We can either overload atom:source to contain the User-Agent, or >> else invent >> a new element to contain the information. Given the choice I'd >> prefer the >> latter, what does everyone else think? > > +1 for the latter too > > We might as well try and keep our use of atom clean, and therefore not > overload elements. I agree it looks like atom:source isn't really appropriate for the User-Agent string and we should try something else. Thanks Glen |
|
From: Stuart L. <sd...@ab...> - 2008-09-15 09:31:44
|
Hi Jim,
> TODO:
> * We can either overload atom:source to contain the User-Agent, or else invent
> a new element to contain the information. Given the choice I'd prefer the
> latter, what does everyone else think?
+1 for the latter too
We might as well try and keep our use of atom clean, and therefore not
overload elements.
Thanks,
Stuart
_________________________________________________________________
Gwasanaethau Gwybodaeth Information Services
Prifysgol Aberystwyth Aberystwyth University
E-bost / E-mail: Stu...@ab...
Ffon / Tel: (01970) 622860
_________________________________________________________________
|
|
From: Simeon W. <si...@cs...> - 2008-09-12 21:46:45
|
Finally got to reading the revised spec and I agree with other comments that
it is much improved.
I'm delighted to see the error document and URI for error code stuff in there
cleanly. Something with the same elements as at Atom Entry document but in a
different namespace seems a good compromise between easy parsing (contents are
the same to parse) and clean semantics (you get an Entry document back only
when it worked).
I'll add a +1 to not worrying about backwards compatibility with 1.2. I don't
think there is enough installed base to sacrifice simplicity (and I speak for
arXiv where we do have an implementation based on 1.2).
+1 to dropping sword:level as someone else suggested.
As I think someone else mentioned, I'm not sure whether the choice of
author/contributor is the right way around. What is the reasoning?
I think the note about the 3 decimal place restriction on q values in section
1.1 should point out that this is the same as HTTP. I went to check with a
plan to complain if it didn't match...
Third bullet of introduction ("A common server...") reads weirdly to me when
one considers it to follow "...of use when:". I suggest rewording as something
like: "Workflows may or may not include manual stages before deposited
resources become available as web resources".
Cheers,
Simeon
Jim Downing wrote:
> Are there any more comments on this draft? I know Julie wanted to freeze
> this asap.
>
> Best regards,
> jim
>
> 2008/9/10 Scott Yeadon <sco...@an...
> <mailto:sco...@an...>>
>
> Hi Jim,
>
> Re the open issue, I agree with addition of a new element rather
> than redefine use of atom:source.
>
> 1.1
> typo: "numberic"
>
> 1.3/1.4
> Does the server need to regurgitate the package type back to the
> client given the client is the one to specify this in the first
> place? I'm not sure I understand the context of this. The server
> response I would think is likely only to hold that information which
> the client needs to know post-deposit (e.g. identifiers of created
> objects, links to created objects, metadata allowing the client to
> map internal information to repository versions of objects, etc).
> There's nothing wrong in the example, I'm just not sure why this
> would be needed. In our journal example, we would only need to
> provide a response to OJS in order it can keep an audit trail as
> well as link to repository versions of a journal issue and its
> articles, for example see
>
> I still think some examples of complex object deposits would be
> useful however the statement in 9.8 regarding atom:content I think
> puts this out of scope for the 1.3 spec. Maybe these are better in
> an implementation guide that perhaps could be drafted as part of the
> eprints/Fedora/DSpace implementation deliverables?
>
>
> >From an implementation point of view, I think it's important for
> any server implementation to be able to make Service Document and
> Deposit Responses pluggable/configurable. In real-world
> implementations this is going to be needed as there will be great
> variation across client application requirements and
> package-to-data-model mapping in repository deposit targets. For
> example, in DSpace it may be possible to instantiate different SWORD
> service document- and deposit response- handler classes based on a
> combination of Package Ingester configurations and User-Agents (or
> something like that) allowing for context-based deposits.
>
> Scott.
>
> Message: 6
> Date: Tue, 9 Sep 2008 09:17:12 +0100
>
> From: "Jim Downing" <oj...@ca... <mailto:oj...@ca...>>
> Subject: [sword-app-tech] Fwd: SWORD 1.3
>
> To: swo...@li...
> <mailto:swo...@li...>
> Message-ID:
> <2ab...@ma...
> <mailto:2ab...@ma...>>
> Content-Type: text/plain; charset="utf-8"
>
>
> Hi all,
>
> A second draft of the SWORD revision 1.3 is available at
> http://sword-app.sourceforge.net/sword-1.3/sword-profile-1.3.html.
> A
> summary of the changes since the first draft: -
>
> * typso fixed
> * formatNamespace renamed
> * A potential mechanism for preferred packaging added
> * Error documents replace X-Error-Code. I was unhappy about
> returning an
> atom:entry in precisely the situation where one isn't created,
> so error
> documents are rooted at a new element.
> * More explanation of the service nesting mechanism.
>
> Some of these changes break compatibility with 1.2.
>
> Open Issue:
> * We can either overload atom:source to contain the User-Agent,
> or else
> invent a new element to contain the information. Given the
> choice I'd prefer
> the latter, what does everyone else think?
>
> Best regards,
> jim
>
> _______________________________________________
> sword-app-tech mailing list
> swo...@li...
> https://lists.sourceforge.net/lists/listinfo/sword-app-tech
|
|
From: Jim D. <oj...@ca...> - 2008-09-12 09:25:37
|
Are there any more comments on this draft? I know Julie wanted to freeze this asap. Best regards, jim 2008/9/10 Scott Yeadon <sco...@an...> > Hi Jim, > > Re the open issue, I agree with addition of a new element rather than > redefine use of atom:source. > > 1.1 > typo: "numberic" > > 1.3/1.4 > Does the server need to regurgitate the package type back to the client > given the client is the one to specify this in the first place? I'm not > sure I understand the context of this. The server response I would think is > likely only to hold that information which the client needs to know > post-deposit (e.g. identifiers of created objects, links to created objects, > metadata allowing the client to map internal information to repository > versions of objects, etc). There's nothing wrong in the example, I'm just > not sure why this would be needed. In our journal example, we would only > need to provide a response to OJS in order it can keep an audit trail as > well as link to repository versions of a journal issue and its articles, for > example see > > I still think some examples of complex object deposits would be useful > however the statement in 9.8 regarding atom:content I think puts this out of > scope for the 1.3 spec. Maybe these are better in an implementation guide > that perhaps could be drafted as part of the eprints/Fedora/DSpace > implementation deliverables? > > > From an implementation point of view, I think it's important for any server > implementation to be able to make Service Document and Deposit Responses > pluggable/configurable. In real-world implementations this is going to be > needed as there will be great variation across client application > requirements and package-to-data-model mapping in repository deposit > targets. For example, in DSpace it may be possible to instantiate different > SWORD service document- and deposit response- handler classes based on a > combination of Package Ingester configurations and User-Agents (or something > like that) allowing for context-based deposits. > > Scott. > >> Message: 6 >> Date: Tue, 9 Sep 2008 09:17:12 +0100 >> From: "Jim Downing" <oj...@ca...> >> Subject: [sword-app-tech] Fwd: SWORD 1.3 >> To: swo...@li... >> Message-ID: >> <2ab...@ma...> >> Content-Type: text/plain; charset="utf-8" >> >> >> Hi all, >> >> A second draft of the SWORD revision 1.3 is available at >> http://sword-app.sourceforge.net/sword-1.3/sword-profile-1.3.html. A >> summary of the changes since the first draft: - >> >> * typso fixed >> * formatNamespace renamed >> * A potential mechanism for preferred packaging added >> * Error documents replace X-Error-Code. I was unhappy about returning an >> atom:entry in precisely the situation where one isn't created, so error >> documents are rooted at a new element. >> * More explanation of the service nesting mechanism. >> >> Some of these changes break compatibility with 1.2. >> >> Open Issue: >> * We can either overload atom:source to contain the User-Agent, or else >> invent a new element to contain the information. Given the choice I'd >> prefer >> the latter, what does everyone else think? >> >> Best regards, >> jim >> >> >> > |
|
From: Jim D. <oj...@ca...> - 2008-09-12 09:24:15
|
Hi Scott, Thanks for your comments. 2008/9/10 Scott Yeadon <sco...@an...> > 1.3/1.4 > Does the server need to regurgitate the package type back to the client > given the client is the one to specify this in the first place? I'm not > sure I understand the context of this. The server response I would think is > likely only to hold that information which the client needs to know > post-deposit (e.g. identifiers of created objects, links to created objects, > metadata allowing the client to map internal information to repository > versions of objects, etc). There's nothing wrong in the example, I'm just > not sure why this would be needed. In our journal example, we would only > need to provide a response to OJS in order it can keep an audit trail as > well as link to repository versions of a journal issue and its articles, for > example see There's not a lot of point it being in the response, but it should be in the Atom Entry Document, so for the sake of consistency it might as well be the same. I still think some examples of complex object deposits would be useful > however the statement in 9.8 regarding atom:content I think puts this out of > scope for the 1.3 spec. Maybe these are better in an implementation guide > that perhaps could be drafted as part of the eprints/Fedora/DSpace > implementation deliverables? I'd hope this could be done too. Best regards, jim |
|
From: Scott Y. <sco...@an...> - 2008-09-10 02:26:53
|
And of course I left the link to the example out of previous email, see: http://pilot.apsr.edu.au/public/sword/sword-example.txt Scott Yeadon wrote: > Message: 6 > Date: Tue, 9 Sep 2008 09:17:12 +0100 > From: "Jim Downing" <oj...@ca...> > Subject: [sword-app-tech] Fwd: SWORD 1.3 > To: swo...@li... > Message-ID: > <2ab...@ma...> > Content-Type: text/plain; charset="utf-8" > > Hi all, > > A second draft of the SWORD revision 1.3 is available at > http://sword-app.sourceforge.net/sword-1.3/sword-profile-1.3.html. A > summary of the changes since the first draft: - > > * typso fixed > * formatNamespace renamed > * A potential mechanism for preferred packaging added > * Error documents replace X-Error-Code. I was unhappy about returning an > atom:entry in precisely the situation where one isn't created, so error > documents are rooted at a new element. > * More explanation of the service nesting mechanism. > > Some of these changes break compatibility with 1.2. > > Open Issue: > * We can either overload atom:source to contain the User-Agent, or else > invent a new element to contain the information. Given the choice I'd > prefer > the latter, what does everyone else think? > > Best regards, > jim > > |
13 messages has been excluded from this view by a project administrator.
