We tried to model a bit more complex SPQR example using the Europeana data model (EDM). In this example we have two representations of the same papyrus. One is taken from the HGV and the other from the APIS database. We have decided to use papyri.info as a provider of URIs for these objects. We start with two resources identified by the following URIs
http://papyri.info/apis/perkins.apis.3997
http://papyri.info/hgv/21935
Both URIs could represent the actual non-information resource “the papyrus” and be linked by owl:sameAs. However, this may not be the case. Maybe the author wanted to represent a database entry not the PhysicalThing. For Europeana we would like to have an URI for the actual thing and crate two Aggregations linking to database entries. The default question is: who should provide this URI? The most sensible way to proceed is to create one in the SPQR (or Europeana) domain and link by owl:sameAs to any other future URIs. We could also liaise with papyri.info and let them define such an URI. In our sketchy graph we leave this problem as unsolved and our PhysicalThing has “2 URIs”.
In the papyri.info RDF for both resources (retrievable by adding /rdf to the URI) both URIs are related via the dc:relation property.
Another problem is that EDM kind of assumes that a view of a PhysicalThing will have a different URI than the WebResource representing a view. Similarly for the landingPage. In the LinkedData world different views are retrieved by means of content negotiation – not different URIs. This issue is known to the Europeana community. We have used a few Europana classes like: Agent for people, Place for places and TimeSpan for dates.
Take a look at our graph. It has some comments and includes EuropeanaAggregator just to demonstrate its use. The actual SPQR vocabulary is yet to be defined, but we have included a couple of SPQR specific properties as possible renderings of captured metadata.
