Hi Richard, This is very off-the-cuff, but I'm wondering if it would help to split the SWORD profile into two parts:
Part 1 -- extending SWORD 1 to cover PUT and DELETE to 'edit' link IRI and 'edit-media' link IRI, but only ever treating the media resource as an opaque binary object, i.e., having no knowledge of unpacking the media resource or operations on the contents of the package (additions, partial updates, ...). Part 2 -- packaging-aware protocol operations I.e., part 1 would be basically just pure atompub, adding almost nothing new (no new inventions), and so *should* be relatively uncontentious and easy to get consensus on. You could then push part 1 through, and not get held up by work on part 2. For me, part 2 (anything that requires server and/or client to be aware of package contents in their conversations) is where the difficulties lie, because here is where you are doing the most invention. Here is also where it feels like trying to squeeze packaging-aware protocol operations into existing atompub conventions is the worst fit, because (of course) atompub was never designed with packaging in mind. Hope this makes sense, and is helpful. Cheers, Alistair On Tue, Apr 12, 2011 at 05:34:35PM +0100, Richard Jones wrote: > 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 -- Alistair Miles Head of Epidemiological Informatics Centre for Genomics and Global Health <http://cggh.org> The Wellcome Trust Centre for Human Genetics Roosevelt Drive Oxford OX3 7BN United Kingdom Web: http://purl.org/net/aliman Email: aliman...@gmail.com Tel: +44 (0)1865 287669 ------------------------------------------------------------------------------ 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
