Hi Folks, Last week while Dave T was in town we met up and had a chat about a particular limitation of SWORD (and Atom, as it happens) which means it doesn't meet the DepositMO use case requirements.
The problem can be stated as follows: Given that the atom:link@rel="edit-media" IRI in an atom:entry (e.g. the Deposit Receipt) is a reference to the entire Media Resource in some format (e.g. a package), then when a deposit of additional content by POST to an existing container (identified by its Edit-IRI) takes place, the Deposit Receipt CANNOT return to the client an IRI for the resource (or derivative(s) of the resource) that was just created. This is problematic for the collaborative deposit use cases, where different clients will want to be able to track or at least know which files they were responsible for depositing. In order to address this problem as simply as possible, we have the following proposed additions to the SWORD spec: 1/ Add a section explicitly allowing a metadata-only object to be created by POSTing to the Col-IRI an Atom Entry which meets the requirements already laid out in the spec. At the moment there are sections (6.3.1 and 6.3.2) which detail how to deposit a single part binary content deposit, and a multipart deposit, but none which detail the addition of an Entry Resource only deposit. By adding this, clients which want to can create the container first - by POSTing an atom:entry - and then go on to add content to the container later. This works with point (2) to effectively fix the stated problem: 2/ Add a section to explicitly allow the client to GET an atom:feed and to POST content to the EM-IRI. The former of these is consistent with AtomPub as it stands at the moment, so is uncontentious. SWORD will profile AtomPub appropriately here. The second of these allows the client to create new resources inside the Media Resource itself, rather than the Entry Resource (identified by the Edit-IRI). At the moment SWORD allows POST to the SE-IRI (which is effectively the Edit-IRI) to add content to the container, but not to the EM-IRI. Neither is this in the original AtomPub spec. The purpose of doing this is that when the server responds, it can return an atom:entry for the deposited resource (or an atom:feed, see questions below), giving the client the identifier that it requires as per the stated problem. Note that this atom:entry is NOT the Deposit Receipt as described by SWORD (at least, we don't think so - see questions below). 3/ To add to the Deposit Receipt an atom:link@rel="edit-media" with href="application/atom+xml;type=feed" in order to support the GET of the EM-IRI as described in (2) above. This will not be a requirement of SWORD, we will just duplicate the language from the AtomPub spec with regard to how required it is! There are a couple of questions and possible answers regarding this approach: a/ If the response to a POST to an EM-IRI is NOT a Deposit Receipt in the full SWORD sense, is this a failure of consistency in the profile? Should all atom:entry responses from SWORD servers meet the criteria of the Deposit Receipt (or rather, be formally allowed to present the same additional elements). There is an extra complication here, which is that if the POST to the EM-IRI is a package which the server duly unpacks, what does it identify in the atom:entry as the resource which it takes deposit of. There are a few options i. it could just list the package itself, if the server has retained a copy after unpacking ii. it could list nothing if the package was removed after unpacking iii. it could return an atom:feed instead of an atom:entry, listing each created resource as an atom:entry in that feed Dave feels that the response should be either/or depending on what the server did with the content. I am more inclined to be prescriptive of an atom:entry which follows (i) or (ii) above for the purposes of simplicity. I also think that if you are POSTing content to the EM-IRI you should, in general, not be using packages. Adding packages can still be done via POST to the SE-IRI also. I also wonder whether it would be better to have all of the components of a deposit listed as atom:link elements with a sword specific @rel value to say that they were created during the deposit process. In that way, the response to the POST to EM-IRI could be a Deposit Receipt in the existing sense, ensuring consistency across the profile and making the client/server implementations easier. Thoughts? b/ Is the profile becoming too large? Is it worth dividing it into two parts, one for the operations which concern only the container (identified by Edit-IRI) and package-based operations and another for operations concerning the individual content items and the EM-IRI? c/ In light of the above, do we still need POST to the SE-IRI for adding further content to the container? I'm inclined to say yes, as this means that you can add (rather than replace) packages and metadata to the object. You can't, for example, modify the metadata with operations on EM-IRI as it represents the Media Resource not the Entry Resource. Without this option we limit the client to usage of PUT on the Edit-IRI only, which eliminates the option to add (not overwrite) metadata. There are also some other changes suggested, to do with how responses to Deletes are handled, and whether Location or Content-Location headers are provided. I will attempt to clarify those in the spec rather than enumerate the details here, for comment when the Alpha 3 version is available. Sorry about the huge email - I wanted to be as clear as possible. I will be implementing these changes and working out the guts of the detail as I go along, so there will be an Alpha 3 spec soon for you to look at. Cheers, Richard ------------------------------------------------------------------------------ Forrester Wave Report - Recovery time is now measured in hours and minutes not days. Key insights are discussed in the 2010 Forrester Wave Report as part of an in-depth evaluation of disaster recovery service providers. Forrester found the best-in-class provider in terms of services and vision. Read this report now! http://p.sf.net/sfu/ibm-webcastpromo _______________________________________________ Sword-app-techadvisorypanel mailing list Sword-app-techadvisorypanel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sword-app-techadvisorypanel
