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? 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) 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>
