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.
