It is suggested that the default manifest is based upon OAI-ORE [18], and its RDF serialisations [19]. This standard was developed to enable the description of web based complex digital objects, and is therefore well suited to describing the structure of repository objects in a way which is compatible with the ethos of SWORD. In fact, some repositories have already implemented some form of support for this standard either as embedded RDFa in web pages or in explicit publication of ORE Resource Maps in a variety of formats.
OAI-ORE concerns itself with describing aggregations of web resources, and does not contain any semantics which allow us to represent the state of the item in the repository as we discussed above. Because the OAI-ORE is expressible as RDF – the format upon which the Linked Data [20]
movement relies – it is trivial to construct a manifest document which contains both the OAI-ORE Resource Map as well as additional statements in RDF asserting the workflow state of the item. Consider the following basic example manifest document, serialised in RDF/XML:
lt;rdf:RDF xmlns:rdf=http://www.w3.org/1999/02/22-rdf-syntax-ns# xmlns:ore=http://www.openarchives.org/ore/terms/ xmlns:sword=http://swordapp.org/terms/gt; lt;!-- standard way of declaring ORE Resource Map describing a resource --gt; lt;rdf:Description rdf:about=http://swordapp.org/rem/rdfxml/100gt; lt;ore:describes rdf:resource=http://swordapp.org/aggregation/100/gt; lt;/rdf:Descriptiongt; lt;!-- description of the repository item --gt; lt;rdf:Description rdf:about=http://swordapp.org/aggregation/100gt; lt;ore:isDescribedBy rdf:resource=http://swordapp.org/rem/rdfxml/100/gt; lt;!-- the files associated with the repository item --gt; lt;ore:aggregates rdf:resource=http://swordapp.org/object/100/file1.pdf/gt; lt;ore:aggregates rdf:resource=http://swordapp.org/object/100/file1.pdf/gt; lt;ore:aggregates rdf:resource=http://swordapp.org/object/100/file1.pdf/gt; lt;!-- SWORD relationships regarding the items repository state --gt; lt;sword:state rdf:resource=http://swordapp.org/terms/under-review/gt; lt;sword:state-description rdf:resource=http://swordapp.org/repo/under-review/gt; lt;/rdf:Descriptiongt; lt;/rdf:RDFgt;
Here we see a simple ORE Resource Map which provides us with a description of an object which contains 3 files, as indicated by the ore:aggregates elements. It then goes on to assert two further relationships in the form of sword:state, which indicates the SWORD standard dictionary term for the state the item is in (or the repository specific term for the items current state), and sword:state-description, which would allow the repository to provide its own detail to the client as to what that state means to them.
It is acknowledged that since some repositories already implement OAI-ORE, they may be able, by default, to provide more information in the resource map than we show above. The SWORD specification should apply no limits to these cases, and is only acting as a profile of OAI-ORE for the purposes of providing a manifest which is widely comprehendible. That is, all the specification will say is that ore:aggregates elements must be provided for each file in the repository item that the repository wishes to alert the client to.
The ultimate objective is to ensure that the SWORD profile of OAI-ORE provides enough information that the following operations will be possible:
- HTTP POST of a new file into the repository item; for example, onto the URI for the aggregation (http://swordapp.org/aggregation/100 in the above example);
- HTTP PUT of a new file over an existing file; that is, onto the resource referenced in ore:aggregates
- HTTP DELETE of an existing file; again, requested of the resource referenced in ore:aggregates
- HTTP GET of individual files inside the repository item, requested of the resource referenced in ore:aggregates
Notice that these 4 standard HTTP operations are not on the repository item itself, or the package which was deposited, but on the contents of the repository item created from the original package deposit, as described by the resource map.
I’m ok with state being described in the manifest, but think that state transitions should be communicated in the AtomPub Protocol using the app:control element.
It is already possible to indicate if something is private or published (using app:control.draft=yes/no). It should be possibleto extend this vocabulary for the other state transitions. See the state transition diagrams in http://www.ands-partners.org/blog/2010/10/ingest-or-how-do-you-get-things-in-there/ for simplified example
OK wordpress strips tags!
so what I was trying to say was:
Can i just say I despise your use of sword:state and sword:state-description when the better (and RDF standard!) way to do this is:
sword:state rdf:resource=”http://swordapp.org/terms/under-review”
rdf:description rdf:about=”http://swordapp.org/terms/under-review”
rdfs:label = Under Review
rdfs:comment = This item is under review, stage 2 of 3.
ore:next? rdf:resource=”http://swordapp.org/terms/publised”
/rdf:description
Can i just say I despise your use of sword:state and sword:state-description when the better (and RDF standard!) way to do this is:
Under Review
This item is at stage 2 of 3 (under review), next state is published.
Is state properly part of the manifest? (as I asked in an earlier comment).
To some extent, using RDF allows this issue to be finessed, but I’m still minded to suggest that state information should be defined separately, even if it is ultimately serialized in the same blob of RDF as the manifest.