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
<entry xmlns:sword="http://purl.org/net/sword/terms/"; xmlns="http://www.w3.org/2005/Atom";>
<title>SWORD Deposit</title>
<id>tag:container@sss/584511c0-50bb-4fb0-ac16-390b174cadfb/9e5b0167-ade7-4be4-b79a-5d33a9cca16d</id>
<updated>2011-01-19T18:50:08Z</updated>
<author>
<name>SWORD Client</name>
</author>
<summary type="text">Content deposited with SWORD client</summary>
<generator uri="http://www.swordapp.org/sss"; version="1.0"/>
<content type="application/zip" src="http://localhost:8080/cont-uri/584511c0-50bb-4fb0-ac16-390b174cadfb/9e5b0167-ade7-4be4-b79a-5d33a9cca16d"/>
<sword:package>http://purl.org/net/sword/package/default</sword:package>
<sword:treatment>Treatment description</sword:treatment>
<sword:verboseDescription>SSS has done this, that and the other to process the deposit</sword:verboseDescription>
<link rel="edit" href="http://localhost:8080/edit-uri/584511c0-50bb-4fb0-ac16-390b174cadfb/9e5b0167-ade7-4be4-b79a-5d33a9cca16d"/>
<link rel="edit-media" href="http://localhost:8080/em-uri/584511c0-50bb-4fb0-ac16-390b174cadfb/9e5b0167-ade7-4be4-b79a-5d33a9cca16d"/>
<link rel="alternate" href="http://FIXME/ALT/URL/HERE"/>
<link rel="self" href="http://localhost:8080/edit-uri/584511c0-50bb-4fb0-ac16-390b174cadfb/9e5b0167-ade7-4be4-b79a-5d33a9cca16d"/>
<link rel="http://www.openarchives.org/ore/terms/describes"; href="http://localhost:8080/agg-uri/584511c0-50bb-4fb0-ac16-390b174cadfb/9e5b0167-ade7-4be4-b79a-5d33a9cca16d"/>
<category term="http://www.openarchives.org/ore/terms/Aggregation"; label="Aggregation" scheme="http://www.openarchives.org/ore/terms/"/>
<link rel="http://www.openarchives.org/ore/terms/aggregates"; href="http://localhost:8080/part-uri/584511c0-50bb-4fb0-ac16-390b174cadfb/9e5b0167-ade7-4be4-b79a-5d33a9cca16d/2011-01-19T18%3A50%3A08Z_example.zip"/>
<oreatom:triples xmlns:oreatom="http://www.openarchives.org/ore/atom/"; xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"; xmlns:ore="http://www.openarchives.org/ore/terms/";>
<rdf:Description rdf:about="http://localhost:8080/edit-uri/584511c0-50bb-4fb0-ac16-390b174cadfb/9e5b0167-ade7-4be4-b79a-5d33a9cca16d";>
<ore:describes rdf:resource="http://localhost:8080/agg-uri/584511c0-50bb-4fb0-ac16-390b174cadfb/9e5b0167-ade7-4be4-b79a-5d33a9cca16d"/>
</rdf:Description>
<rdf:Description rdf:about="http://localhost:8080/agg-uri/584511c0-50bb-4fb0-ac16-390b174cadfb/9e5b0167-ade7-4be4-b79a-5d33a9cca16d";>
<ore:isDescribedBy rdf:resource="http://localhost:8080/edit-uri/584511c0-50bb-4fb0-ac16-390b174cadfb/9e5b0167-ade7-4be4-b79a-5d33a9cca16d"/>
<ore:aggregates rdf:resource="http://localhost:8080/part-uri/584511c0-50bb-4fb0-ac16-390b174cadfb/9e5b0167-ade7-4be4-b79a-5d33a9cca16d/2011-01-19T18%3A50%3A08Z_example.zip"/>
<sword:originalDeposit rdf:resource="http://localhost:8080/part-uri/584511c0-50bb-4fb0-ac16-390b174cadfb/9e5b0167-ade7-4be4-b79a-5d33a9cca16d/2011-01-19T18%3A50%3A08Z_example.zip"/>
<sword:state rdf:resource="http://purl.org/net/sword/state/archived"/>
</rdf:Description>
<rdf:Description rdf:about="http://localhost:8080/part-uri/584511c0-50bb-4fb0-ac16-390b174cadfb/9e5b0167-ade7-4be4-b79a-5d33a9cca16d/2011-01-19T18%3A50%3A08Z_example.zip";>
<sword:packaging rdf:resource="http://purl.org/net/sword/package/default"/>
<sword:depositedOn rdf:datatype="http://www.w3.org/2001/XMLSchema#dateTime";>2011-01-19T18:50:08Z</sword:depositedOn>
<sword:depositedBy rdf:datatype="http://www.w3.org/2001/XMLSchema#string";>sword</sword:depositedBy>
</rdf:Description>
<rdf:Description rdf:about="http://purl.org/net/sword/state/archived";>
<sword:stateDescription>The work has passed through review and is now in the archive</sword:stateDescription>
</rdf:Description>
</oreatom:triples>
</entry>
