+1
> -----Original Message----- > From: Tim Brody [mailto:t...@ecs.soton.ac.uk] > Sent: 21 January 2011 11:04 > To: techadvisorypanel@swordapp.org > Subject: Re: Key Changes and Justifications > > 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.
