I’m going to blog some more substantial notes on last Friday’s RepoCamp as and when time permits. In the meantime, a cool idea and a plea for collaborators.

The RepoCamp involved the announcement of not one, but two developer challenges in the style of the one at Open Repositories 2008. The first is a general challenge (for which I can’t easily find a reference: help please, WoCRIG!) to do something cool involving interoperating systems. The second challenge is specific to the OAI-ORE specification, and involves creating a prototype that makes the usefulness of ORE visible to end-users.

I’ve got a cool idea for this, but I’m going to need to collaborate to get it done in time, so I’m blogging it in the hope that someone with a bit of time on their hands will get in touch.

The idea: a javascript library (or userscript) that follows all the links on a page and if the link is an ORE Resource Map, or if a Resource Map can be auto-discovered from it, the link is decorated with an ORE icon. Clicking the ORE icon pops up a display of the contents of the ORE aggregation, a la Stacks in OS X 10.5.

There are some fun bells and whistles in there;  including making the interface super shiny and minimizing bandwidth.

Anyone want to help out? I was planning to use John Resig’s jQuery and HTML parsing libraries and possibly processing.js.

Neat ORE shorthand

February 5, 2008

A useless piece of trivia, perhaps, but since ORE requires resource maps to dereference to the resource map document, the resource map URI is implicitly the base URI for the document. This means you can use relative URIs in the ORE document for the aggregation and the resource map itself. In Turtle, the following would be a valid complete resource map document.

@prefix ore
ore:describes .
ore:aggregates ,


Warning! Here be RDF and ORE concepts. Some pre-reading is required. I’m referring to the alpha version of the specs in this – things may have changed without my knowledge – I’m hoping that someone from the technical committee will correct me if so. RDF prefixes are used as in the ORE specs

In this post I think out loud about the ramifications of the implicit types in ORE…

An ORE resource map graph is stitched together with two main predicates: ore:describes and ore:aggregates. The resources at either end of these predicates have implicit RDF types; ore:ResourceMap for Resource Maps, ore:Aggregation Aggregations, and ore:AggregatedResource for (you guessed it) AggregatedResources. So this: –

@prefix eg .
eg:myResourceMap ore:describes eg:myResourceMap#aggregation.
eg:myResourceMap#aggregation ore:aggregates eg:myResource1,

is implicitly equivalent to this: –

eg:myResourceMap ore:describes eg:myResourceMap#aggregation;
rdf:type ore:ResourceMap.
eg:myResourceMap#aggregation rdf:type ore:Aggregation;
ore:aggregates eg:myResource1,
eg:myResource1 rdf:type ore:AggregatedResource.
eg:myResource2 rdf:type ore:AggregatedResource.
eg:myResource3 rdf:type ore:AggregatedResource.

So what? Well, in the basic case, you shouldn’t use those types for querying, since they might well not be present. So: –

?ar a ore:AggregatedResource;
dc:author .

Could work, but only if the types have been put in there manually, or if you know that the end point has reasoned over the RDF. In general, the query that will work more reliably would be: –

?a ore:aggregates ?ar.
?ar dc:author .

I think this will also have an impact when extending ORE. Say I’m using ORE to describe a journal paper and it’s supplemental data. I could create a hasSupportingInformation property as a sub class of ore:aggregates, but that will break queries like the one just above (unless the end-point has reasoned over the graph). So it looks like it’s safest to create a SupportingInformationResource subclass of ore:AggregatedResource instead; then clients that know about SupportingInformation can make specific queries, without breaking generic queries or requiring RDFS reasoning in the end-point.

Background: An alpha version of the OAI-ORE specifications was released in December, and has prompted less public discussion than I’d hoped for, so I’m going to post some of the issues as I perceive them in an attempt to promote awareness. I’ll inevitably fail to be comprehensive, so I won’t try – I’ll stick to the ones that interest me.

ORE is a way of describing aggregations of web resources; complex objects in digital library / repository parlance. It’s based on semantic web principles and technology and is RESTful (unlike PMH, but that’s a story for another day), which is a Good Thing.

So what is it good for: –

i) Provides an alternative to content packaging. Content packaging standards and security are two of the biggest hurdles to repository interop. ORE could provide a route around one of them, and bring the repository world closer to the web in doing so.

ii) Takes forward named graphs for defining boundaries on the semantic web. The semantic web can be visualized as a big network of statements about things, that lacks a way of defining a chunk of the network (in order to make statements about it…). You perhaps have to be a bit of a semantic web geek to appreciate the importance of this at first flush.

The alpha of the standard itself stood out for a couple of things too. It seemed to have been written with a mindset of “what is the least we can specify whilst being useful?”. It’s also a well rounded spec; there are constraints to make it simple, but they’re not out of balance with the amount of specification and support provided.

ORE is likely to be important to the repository community; there is a lot of momentum behind it (on which more later), and it provides a piece of perviously-missing infrastructure. So it might well be worth your while to read the spec, join the discussion group and maybe even read some of the following posts…