---------- Forwarded message ---------- From: Richard Jones <rich...@oneoverzero.com> Date: 21 January 2011 08:36 Subject: Re: Key Changes and Justifications To: David Tarrant <d...@ecs.soton.ac.uk> Cc: rsander...@lanl.gov, techadvisorypa...@swordapp.org
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> > > ------------------------------------------------------------------------------ Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d _______________________________________________ Sword-app-techadvisorypanel mailing list Sword-app-techadvisorypanel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sword-app-techadvisorypanel
