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!
Perhaps I misunderstood your objections?
Do we need to leave the Atom/Atom Feed spec to solve this problem?
I don't like the idea of SIMPLE suddenly needing knowledge of 2 specifications
(ATOM and ORE)
I don't think there was anything sudden about it - it's been in the
design proposal since the start.
Cheers,
Richard
Dave T
On 19 Jan 2011, at 18:57, Richard Jones wrote:
Hi Rob,
I've just mocked up another deposit receipt serialisation which I think is a
valid Resource Map. I don't suppose you could give it a once over for me could
you?
I've kept the full RDF/XML part intact, although it now resides in an
oreatom:triples element rather than an rdf:RDF element. I have kept the
describes and isDescribedBy declarations, which are not in the Atom
implementation guide for ORE, but it didn't seem to hurt. Then I have
basically just created all the relevant atom:link and atom:category elements
that I need to. Oh, I also created a new URI form for Aggregations.
Cheers,
Richard
On 19/01/11 13:04, Richard Jones wrote:
Hi Rob,
* URIs used in Statements.
Could you either unpack this section a little, or give an example? When
reading in conjunction with the previous document, it seems that you're
reusing identifiers incorrectly.
I'm happy that the Edit-URI (URI of Atom Entry) is the Resource Map URI.
This is as per the ORE/ATOM spec (
http://www.openarchives.org/ore/1.0/atom ) and should be in
/entry/link[@rel=self] in the entry document.
I'm less convinced that you can reuse EM-URI as the URI of the
aggregation. EM-URI (and "almost always" Cont-URI) isn't a non
information resource that represents the set of aggregated resources.
From Cont-URI you can "retrieve representations of the object as it
resides in the SWORD server", making it a negotiable information
resource?
My understanding is that EM-URI / Cont-URI is the value of
link[@rel="edit-media"] and Edit-URI is the value of link[@rel="edit"]?
In RFC 5023, section 11, I think that the distinction is pretty clear
that
edit is to modify the entry (as you have) and edit-media is to modify an
associated media resource (the actual content). Thus the re-use of it as
the Aggregation URI seems very strange.
The practical requirements for the URI of the aggregation are that it
return a 303 status in response to a GET request, and a Content-Location
of a Resource Map. In the default SWORD case this would only be the Atom
Entry document, but that's perfectly acceptable as ConNeg could be
used to
get RDF serializations.
Basically, I think you need a new URI here.
Attached is a mock up of how I originally thought we would do this,
which is basically the original SWORD deposit receipt, but with a
resource map embedded into it (using the Edit-URI and EM-URI as the
REM-URI and Agg-URI respectively) as RDF/XML foreign markup.
I'm now starting to question this a little more.
For a start, I should have re-checked the ORE spec to make sure that
these URIs were used right - in some way we definitely need a new URI
for the aggregation as you suggest.
I was also just taking a look at the Atom serialisation for ORE and am
wondering whether the Deposit Receipt has to be a resource map as
described here, or whether my current approach of embedding the RDF/XML
resource map as foreign markup in the Deposit Receipt is ok. The thing
with the Atom serialisation of a Resource Map is that it is /really/
verbose, and not so straightforward to read from the perspective of
someone familiar with RDF/XML but not with ORE.
Cheers,
Richard
<sss_deposit-receipt.xml>
