Wednesday, 25 May 2011

Nomisma.org Annotations

Nomisma.org is a Pelagios partner that is "minting" stable URIs for concepts within numismatics. To date, we have URI's for mints, coin hoards, some rulers, and a few other general numismatic concepts. The small map below is just a quick overview of Nomisma's European, Asian and African mappable IDs.



An ID in nomisma takes the form of a short URI, as in http://nomisma.org/id/corinth or http://nomisma.org/id/igch1546. Clicking through to the Corinth ID shows you the location of the mint and as well as locations of hoards that have coins of Corinth in them. The reverse relationship is mapped for a hoard so you'll see the findspot of the hoard and the locations of the mints of coins found in it. These are nice maps of one aspect of economic and cultural exchange in the ancient world. A longer post would talk more about the vagueness of the concept "mint", but here I'll just let this mention stand-in for discussion of the issue.

Many of the mints identified in Nomisma are linked to Pleiades URIs so that they are well along the way to Pelagios compatibility. We use XHTML+RFDa to encode our data, meaning that Corinth is represented by the following source:


<div typeof="nm:mint" about="[nm:corinth]">
 <div property="skos:prefLabel" xml:lang="en">Corinth</div>
 <div property="skos:definition" xml:lang="en">The mint at the ancient site of Corinth in Peloponnesus.</div>
 <div>Latitude Longitude: <span property="gml:pos">37.933333 22.933333</span>.</div>
 <div><a rel="skos:related nm:latlongsource" href="http://en.wikipedia.org/wiki/Corinth">Wikipedia article</a></div>
 <div>Pleiades URI: <a rel="skos:related" href="http://pleiades.stoa.org/places/570182">http://pleiades.stoa.org/places/570182</a></div>
</div>

It is straightforward to turn this into a Pelagios compliant OAC annotation. You can find all the Nomisma.org annotations at http://nomisma.org/nomisma.org.pelagios.rdf. Here's what Corinth looks like there:

  <rdf:Description rdf:ID="corinth">
    <rdf:type rdf:resource="http://www.openannotation.org/ns/Annotation"/>
    <oac:hasBody rdf:resource="http://pleiades.stoa.org/places/570182"/>
    <oac:hasTarget rdf:resource="http://nomisma.org/id/corinth"/>
    <dcterms:creator rdf:resource="http://nomisma.org/"/>
    <dcterms:title>Nomisma.org annotation linking http://nomisma.org/corinth to http://pleiades.stoa.org/places/570182</dcterms:title>
    <rdfs:seeAlso rdf:resource="http://en.wikipedia.org/wiki/Corinth"/>
  </rdf:Description>



As per discussion on this blog and on the Pelagios list, the body of the annotation is set to the Pleiades URI and the target is the Nomisma.org URI. Again on the basis of preliminary discussion, I'm using rdfs:seeAlso to link to the wikipedia page when Nomisma.org knows that relationship. That falls into the "Why not?" category.

Nomisma.org's goal in participating in Pelagios is very simple. When Pelagios stands-up an aggregator by which users can find Internet resources relevant to the Pleiades URI for Corinth, we want Nomisma.org to show up in that list. I could phrase this as "providing open data within Internet enabled research environments..." or some other language, but I think it's better to keep things simple. We want people to use our data and if participating in Pelagios helps that, well then, here we are.

For those who care about technical details, we are using the rdf:ID construct in the rdf file linked above. If you look at the root element, you'll see the xml:base attribute is set to http://nomisma.org/nomisma.org.pelagios.rdf. An RDF processor will pick that up and turn the @rdf:ID on each rdf:Description into a full URI along the lines of 'http://nomisma.org/nomisma.org.pelagios.rdf#corinth'. This is a slight convenience for me. I don't have to make any adjustments to the Nomisma.org server other than putting the RDF file in an accessible location. I have added the element '<link rel=”x-pelagios-oac-serialization” title=”Pelagios compatible version” type=”application/rdf+xml” href=”http://nomisma.org/nomisma.org.pelagios.rdf”/>' to the html head of Nomisma.org so that any future "Pelagios crawler" can find the right RDF representation.

Overall, OAC is such a simple model that it's pretty trivial to instantiate the links between Nomisma.org and Pleiades using the conventions Pelagios is promoting. Being part of a community like Pelagios means, in part, adhering to the consensus that develops about its use of standards and I'm happy to do that.


But there was one decision that didn't go my way that I think is still interesting. To retrace some steps that have been discussed in previous posts and on the Pelagios list, an OAC annotation has two main parts: a body and a target.

An OAC body is defined as, "The body of the annotation. The Body is somehow about the Target resource. It is the information which is annotating the Target."


An OAC target is defined as, "The resource that is being annotated."

As the creator of annotations within the Pelagios ecosystem, it made sense to me that the body would be the Nomisma.org URI and the target would be the Pleiades resource. To the extent our ecosystem is distributed but bound together by our common use of Pleiades IDs, I find the metaphor of a number of annotations "targeted" at Pleiades URIs to be straightforward. I'm comfortable with the idea that the Pleiades URI http://pleiades.stoa.org/places/570182 is a definition of of the ancient site of Corinth and that I, as a contributor to Nomisma, am saying something about it; as in, providing "information which is annotating the Target". And there's a hint of concern that by making the Pleiades URI the body, Pelagios is suggesting that Pleiades completely defines what we as a community say about the concept of Corinth. I'm tempted by the converse modeling of the Pelagios eco-system: the definition of Corinth is the sum total of all the Pelagios annotations with the bodies of those annotations capturing the content generated at the edges, not at the center.

But Nomisma.org conforms to the community convention and will going forward.  I'm just intrigued by the rhetorical aspects of how we're using OAC.

Saturday, 14 May 2011

The Other 15/10 Geo Projects

Pelagios is funded by JISC under the GECO (Geospatial Engagement and Community Outreach) activity. In all #jiscGEO has some twelve "15/10" geo projects, whose common overall aims include increasing the use of geospatial tools, establishing a trajectory for embedding geospatial resources within a research and learning environment, and promoting best practice (particularly interoperability) for transferring knowledge from specialist to user. Subjects range from working with trainee science teachers or monitoring the spread of moths with a smart phone app to making use of geospatial tools for solving real world problems and visualizing urban energy reduction. Pelagios is proud to be associated with these efforts and hopes that its work can help contribute to GECO’s overarching purpose to foster communities of users of geospatial resources (data, services and support).


For more information about these projects, please go to: geco.blogs.edina.ac.uk


Friday, 15 April 2011

Tagging Places on Old Maps: The DME Scenario

Following the productive Pelagios workshop at KCL, we (DME) have been busy tweaking our infrastructure to interoperate according to the "Pelagios Principles".

For DME, the situation is slightly different than for Pelagios' other data partners: First, our existing data model is already based on OAC - which does probably make our transition somewhat easier. Second, instead of owning an extensive existing data set, our "asset" is an end-user toolkit for manual annotation and semantic tagging of multimedia content (affectionately referred to as YUMA - the YUMA Universal Multimedia Annotator).

Tagging Maps with Pleiades References


In other words: instead of mapping existing place references in our data to URIs in the Pleiades namespace, our primary task was to modify YUMA in such a way that users can, from now on, tag media items with references to Pleiades places!

This has turned out to be quite straightforward: The simplest way by which users can add semantic tags to their annotations in YUMA is through an auto-completion textbox: As the user starts typing, available tags will appear in a drop-down box underneath the typed text. (The screenshot above shows this for the 'Corsica' example mentioned in an earlier post by Mathieu.)

Making Pleiades place references available as tags in YUMA involved two steps:
  • First, we needed to incorporate a list of Pleiades place names (and their URIs) into our Tag Server. The Tag Server is the component which hosts tag vocabularies and provides the tag suggestions for the auto-completion hints. We got a Pleiades CSV data dump, from which we built an index using Apache Lucene, and set up the index as an additional tag source.
  • Second, we needed to provide a 'Pelagios' view on our internal data to the outside world. The reason for this is that our existing RDF representation (although based on OAC) is close, but not identical to the Pelagios model. We therefore set up an alternative RDF output channel, mapped to a .pelagios suffix. Appending this suffix to the annotation URI will return Pelagios-compatible annotations, in either RDF/XML, N3 or Turtle notation based on content negotiation.
The 'Corsica' annotation, for example, is available at this URI: 

http://dme.ait.ac.at/yuma-server/api/annotation/618.pelagios

It will resolve to the following RDF (abbreviated for better readability, key parts red):

@prefix oac: <http://www.openannotation.org/ns/> .

<http://dme.ait.ac.at/samples/maps/oenb/AC04248667.tif>
   a  oac:Target .

<http://dme.ait.ac.at/yuma-server/api/annotation/618>
   a  oac:Annotation ;
   <http://purl.org/dc/elements/1.1/creator>
      "rsimon" ;
   <http://purl.org/dc/elements/1.1/title>
      "Corsica" ;
   <http://purl.org/dc/terms/created>
      "2011-04-11 11:12:34.295" ;
   <http://purl.org/dc/terms/modified>
      "2011-04-11 11:12:55.747" ;
   oac:hasBody
      <http://pleiades.stoa.org/places/991339> ;
   oac:hasTarget
      <http://dme.ait.ac.at/yuma-server/api/annotation/618#target> .
<http://dme.ait.ac.at/yuma-server/api/annotation/618#target>
   a  oac:ConstrainedTarget ;
   oac:constrainedBy
      <http://dme.ait.ac.at/yuma-server/api/annotation/618#ct> ;
   oac:constrains
      <http://dme.ait.ac.at/samples/maps/oenb/AC04248667.tif> .

Lessons Learned


Two concluding remarks: first, I would eventually like to see our 'YUMA OAC representation' unified with the Pelagios one. This is currently hindered a bit by the way the OAC model is organized (i.e. with only one body per annotation allowed, and no official specification on structured bodies). Right now, the difference is therefore that our oac:Body is a separate node that includes all elements that comprise the user's annotation (title, text body, multiple tags, etc.), whereas in Pelagios we consider the Pleiades reference to be the oac:Body directly. (For comparison, the YUMA OAC representation of the example above is here.)

Second, one of the benefits that we gain for YUMA from linking annotations to Linked Data resources is that we can get extra context information by dereferencing them. For example: if we link to DBpedia we can get things such as labels in different languages or alternative spellings for person names. This, in turn, provides us with a very lightweight mechanism for including (at least limited) multilingual and synonym search functionality in our system. (There's a video screencast demonstrating this here.) With our Pleiades integration, we don't quite get this yet: What's still missing is a mapping between Pleiades URIs and matching resources from e.g. Geonames or DBpedia where possible. (However, Pleiades+ might be just the way to address this I guess!)