---------- Forwarded message ---------- From: Tim Brody <t...@ecs.soton.ac.uk> Date: 22 January 2011 00:03 Subject: Re: Key Changes and Justifications To: techadvisorypa...@swordapp.org
On Thu, 20 Jan 2011 19:36:13 -0000, Richard Jones <rich...@oneoverzero.com> wrote: > > > On 20/01/11 17:41, David Tarrant wrote: >> >> >> While this is all lovely... >> >> Why is it that Google docs API and CMIS both use THE SAME solution to >> returning an ATOM entry which has a link rel to a feed which outlined the >> resources which are part of this object? >> > > Wouldn't this require an extra URI? > > In the original proposal we had a Deposit Receipt as an Atom Entry, and a > Statement as a separate document (which you could content negotiate for, so > rdf or an atom feed would have been fine), but when we discussed it you were > against this approach. It was, in fact, you who convinced me that the > Statement should become part of the Deposit Receipt rather than a document in > its own right! The root feed in SWORD contains a list of atom entries that (I think) we all agree should be the top level of the 'work'. The workflow state is the state of the 'work' so lives at this level. It isn't overly controversial to have this as inline or as a link-rel. What's more important is the mechanism to change that state - do you PUT to the <atom:entry>, do a pseudo-move (see CMIS/GData) between collections or use some new RPC (POST?args)? What Dave is talking about is how the media is represented (which relates to 'packaging'). What we've discussed at Soton and decided, before looking at CMIS & GData, is that the simplest representation of the *contents of the work* is a link-reled <feed> that aggregates the 0 or more media resources. As Scott has previously suggested creating a complex object involves multiple POSTs to the link-reled feed. CMIS & GData use this mechanism to support folders. My previous attempt to explain this approach fell on deaf-ears, so let me try to headline this: 1) Get rid of all mentions of "packaging" 2) Get rid of OAI-ORE 3) Use <atom:entry> with an <atom:category> of 'sword:work' (or similar), with a link-rel to an <atom:feed> Anyone who wants to use 'packages' to bundle metadata and files into a single .zip should document it and mint a MIME-type. For instance, BibTeX is plain text but has a commonly accepted MIME-type. If your repository supports "BibTeX" then it can do <accept>application/x-bibtex</accept>. OAI-ORE can be supported through a <link-rel> of the work's <atom:entry>. (Ideally I would like SWORD to be compatible with Google Docs, so we can leverage any tools built for that API with SWORD and vice-versa - now how cool would that be!?) All the best, Tim. ------------------------------------------------------------------------------ Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d _______________________________________________ Sword-app-techadvisorypanel mailing list Sword-app-techadvisorypanel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sword-app-techadvisorypanel
