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 chance to properly reply (until now).
I don't believe we can get rid of mentions of packaging, no matter how
much we would like to. Packaging is used extensively across all
repository types and if SWORD does not help with this it will not be
successful.
Also, interestingly, no one has previously questioned the use of ORE as
the description format for the repository objects (presumably since this
is its core use case). Does anyone else have such misgivings?
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>.
This is not practical, unfortunately. We have to give people something
that they can work with now, without having to care about registering
mime-types. If I want to use SWORD within my organisation to move data
around, do I really have to register a mime type just to announce my
(possibly custom) packaging formats to my other servers? Way too high
an entry barrier.
(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!?)
That would be very cool. What applications of the tech did you have in
mind? Could be interesting to register them in the SWORD use cases?
Cheers,
Richard
