-- Forwarded message --
From: Richard Jones rich...@oneoverzero.com
Date: 22 January 2011 01:57
Subject: Re: Key Changes and Justifications
To: Tim Brody t...@ecs.soton.ac.uk
Cc: techadvisorypa...@swordapp.org
Hi Tim,
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'.
Do you mean the service document? Each entry in there is a
Collection, in line with the Atom definition.
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.
During the original feedback to the white paper, it was felt that
doing this inline was insufficient, as the state information could be
extensive depending on your implementation decisions. Would your
atom:link go to another document for describing the state, as opposed
to the Statement (which describes the object and the state)?
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)?
We are not planning to include any semantics to allow the depositor to
change the state in this way. SWORD is a deposit tool only, and the
idea of relating the state back to the client is for informational
purposes only. I think it's a step to far to attempt to include
workflow controls into SWORD a) this early (before CRUD is even
settled in) or b) possibly even at all.
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.
I agree with this approach almost entirely: In the original proposal
the contents of the work were to be retrievable via the Statement
(located from a link-rel), for which we had proposed ORE as the
format. Nonetheless, the business case also stated that this format
would be content negotiable, so an application/atom+xml;type=feed
content type would be acceptable if you wanted to implement one.
After extensive discussion with Dave, he convinced me that the
Statement should be embedded in the Deposit Receipt, not available
under a separate URI - hence my confusion at the latest feedback.
Personally, I'd be happy to return to the original proposal with an
additional defined feature that the Statement be negotiable as an
atom:feed or an ore resource map. I would also like to ensure that
the atom:feed can suitably hold all the information that we would like
to include in the Statement, such as the state information (which
could, of course, be embedded as foreign markup).
Folks - Perhaps we could have a brief show of hands with regard to the
notion that the Statement be separated from the Deposit Receipt?
It strikes me that there are some opportunities here to leverage the
Aggregation-URI in ORE. At the moment it feels like a bit of an
appendix, existing only to be different from the other URIs that we
can't use for it. Perhaps instead the Aggregation-URI can be our main
entry point for the Statement in it's various forms, via content
negotiation? This would at least stem any proliferation of
unnecessary URIs.
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.
So the CMIS and GData approaches allow you to create a collection on
the server by POST? I had not proposed this approach because it is
not part of the AtomPub spec. Wouldn't it also make quite a big
back-compatibility issue, to change the deposit process in this way?
(not that there aren't such issues already, but at the moment updating
SWORD 1 code to SWORD 2 for POST only should be relatively minor -
this change would require more engineering).
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
I promise that it didn't fall on deaf ears, but it did fall on the
ears of someone who hasn't had the
