Wednesday 25 May 2011 Annotations 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 or 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="">Wikipedia article</a></div>
 <div>Pleiades URI: <a rel="skos:related" href=""></a></div>

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

  <rdf:Description rdf:ID="corinth">
    <rdf:type rdf:resource=""/>
    <oac:hasBody rdf:resource=""/>
    <oac:hasTarget rdf:resource=""/>
    <dcterms:creator rdf:resource=""/>
    <dcterms:title> annotation linking to</dcterms:title>
    <rdfs:seeAlso rdf:resource=""/>

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 URI. Again on the basis of preliminary discussion, I'm using rdfs:seeAlso to link to the wikipedia page when knows that relationship. That falls into the "Why not?" category.'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 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 An RDF processor will pick that up and turn the @rdf:ID on each rdf:Description into a full URI along the lines of ''. This is a slight convenience for me. I don't have to make any adjustments to the 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=””/>' to the html head of 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 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 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 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 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: