PELAGIOS

PELAGIOS Overview Presentation

2012-02-06T08:41:00.000Z

We've recently presented the slides embedded below at an event at the German Archaeological Institute. Since they contain a compact overview of the project so far, we thought we'd post them at our blog as well! The original presentation (.pptx format) is available here.

PELAGIOS Project Overview

View more PowerPoint from aboutgeo

Discovering the Discovery Programme

2012-01-26T16:11:00.000Z

As we are still funded by JISC, you may not have realised that the second phase of Pelagios is actually part of a different programme (also in its second phase, as it happens): the Resource Discovery Programme. Its aims are to help academics and students discover content relevant to their research interests. In particular they are interested in resources that are openly available to anyone. As part of that programme we will be attending several events organised by JISC in order to interact with our sister projects, and learn from each other.

The first meeting was held in Birmingham on January 10th and broke down into two parts. In the first half representatives from each project gave a short (5 minute) presentation about what they intend to achieve. It was interesting to me to see how many projects have a textual angle, especially given that texts are fundamental to Pelagios partners like GAP and Perseus. One project that particularly caught my eye is DiscoverEDINA who (among other things) will be looking to improve the place-based metadata associated with media resources. It's early days for them yet but there may well be opportunities for our projects to learn from each other.

The second part of the day was a series of rotating group discussions on topics associated with data access and usability. These were relatively short and snappy affairs and principally an opportunity for JISC to get a feel for the state of play amongst the groups concerned. They were also intended to trigger our own thinking about such issues and the day ended with a request that each group respond to a series of issues throughout the lifetime of its blog. They are:

Adopting open licensing
Requiring clear reasonable terms and conditions
Using easily understood data models
Deploying persistent identifiers
Establishing data relationships by re-using authoritative identifiers
Providing clear mechanisms for accessing APIs
Documenting APIs
Adopting widely understood data formats

What I found notable was a broad interest, if not wholesale adoption, of semantic approaches across the groups. Anyone who's read my PhD thesis (anyone?) will know that I think semantic technologies really only come into their own in an open data environment, so this seems positive to me. I'm also glad to see that JISC have broken down many of the challenges concerned (especially minting and re-using identifiers) so that they can be addressed independently. None of these are trivial issues and although there's no space to start delving into them here, expect to hear more from us about these topics as Pelagios continues to unfold.

Scenarios of use and potential end users

2012-01-19T18:24:00.001Z

Some of us within IET here at the OU have been thinking about the design and evaluation of the Pelagios tools and interfaces/widgets that are going to be developed and tested over the next few months, and we'd like some feedback from all of you please, to help us answer a few questions.

In particular, we're thinking about:

our user base - in the final JISC proposal document, it mentions super users, end users and policy makers. We think the most important of these are the first two groups: super users and end users. But who exactly are these people - our target groups? could you give us some examples - and also, if anyone is happy to be included in one or both of these groups, please could you email me your contact details so we can include you in some of the design and evaluation tasks? or could you propose other people/institutions who might be happy to be involved?
scenarios of use - why will our users want to use these tools and interfaces? what drives them to look at these resources - what are their interests or goals? what do they need to get out of these resources?

If you think you could help us with this information, please either post your comment on here or email me directly - many thanks!

FASTI Online - New Project Partner

2012-01-16T16:59:00.004Z

As Fasti Online is one of the newest Pelagios partners, I thought it was about time we introduced ourselves to the project and let everyone know why we have joined and what we are hoping to bring to the table, and also what we hope to gain from Pelagios ourselves.

Between 1946 and 1987 the International Association for Classical Archaeology (AIAC) published the Fasti Archaeologici. It contained very useful summary notices of excavations throughout the area of the Roman Empire. However, spiraling costs and publication delays combined to render it less and less useful. AIAC's board of directors thus decided in 1998 to discontinue the publication and to seek a new way of recording and diffusing new results. The Fasti Online is the result of this effort.

Working with L - P : Archaeology [creators of the Archaeological Recording Kit (ARK)] AIAC and our project partners[1] have created an online database of over 2,700 archaeological sites in 13 different countries[2]. Each of these sites has had at least one excavation season since the year 2000 (in fact we have over 4000 excavation seasons in the database). Fasti Online, therefore, is a database of ongoing and recent archaeological projects, and not really a database of ancient places. This is what has made Pelagios so interesting to us, as by linking to the data provided by the other partners we can enrich our own and hopefully enrich theirs as well.

As to how we are planning on making the linkages, one of the fields recorded by the Fasti partners is the Ancient Site Name (where available). For the first round of linking we plan on matching our Ancient Site Names with those held in Pleiades, doing a check on the coordinates to make sure that they are the same place and then adding the Pleiades URI to the Fasti database. An initial run of the linking code has left us with 355 sites that match with Pleiades sites (only 955 of the Fasti sites have an Ancient Site Name attached) so that is not too bad at all for a first run.

We hope that at some point in the future we may be able to supply some of our Ancient site names back to Pleiades and of course the Pelagios partners should be able to link to the Fasti database to see if there are any ongoing excavations in their area of interest!

We'll write a further post once the linking script has been run, and we have managed to get an RDF representation of it all. Watch this space!

[1] the project is generously supported by the Packard Humanities Institute, while the Italian and Ukrainian sites receive additional support from the Ministero dei Beni e le Attivita' Culturali and the Ukrainian Studies Fund, respectively.

[2] the countries that are currently part of Fasti are Italy, Serbia, Bulgaria, Romania, Macedonia, Malta, Morocco, Croatia, Albania, Slovenia, Kosovo, Montenegro and Ukraine

Progress in CLAROS towards Pelagios

2012-01-10T16:58:00.005Z

I have been working on getting data into CLAROS (http://www.clarosnet.org/) to make it a proper contributing partner to Pelagios. Not new data exactly (we have millions on RDF triples already), but new connections between data. Finally, we're almost there, as Alex Dutton will explain in a subsequent post, able to list all the objects and people in CLAROS which can be linked to Pleiades places. But it may be instructive to informally describe the process we go through, and the tools we use.

The starting point for data providers in CLAROS is a supply of RDF against the CIDOC CRM (obviously, that takes some doing at their end; the wiki at http://www.clarosnet.org/wiki/index.php?title=CIDOC_CRM_RDF/XML helps explain how and what). This RDF (I give examples in XML) typically describes a set of objects, eg an <crm:E22_Man-Made_Object rdf:about="http://www.beazley.ox.ac.uk/record/AA1CD952-927D-41D7-B7AF-39520936CF95"> which has a section saying where they think it comes from, in the slightly tortuous way familiar to users of the CRM:

<P16i;was_used_for>
  <E7_Activity>
   <P2_has_type rdf:resource="http://id.clarosnet.org/vocab/Event_FindObject"/>
   <P7_took_place_at>
     <E53_Place>
       <P87_is_identified_by>
         <E48_Place_Name>
           <rdf:value>VULCI</rdf:value>
         </E48_Place_Name>
       </P87_is_identified_by>
       <P89_falls_within>
         <E53_Place>
           <P87_is_identified_by>
             <E48_Place_Name>
               <rdf:value>ETRURIA</rdf:value>
             </E48_Place_Name>
           </P87_is_identified_by>
         </E53_Place>
       </P89_falls_within>
     </E53_Place>
   </P7_took_place_at>
 </E7_Activity>
</P16i_was_used_for>

This is not wrong, but not ideal, since

the E53_Place objects are not identified by a URL and so are not addressable in the RDF
there is no indication of the geographical location of Vulci
there is no link to any other record for Vulci

The CLAROS ingest procedure reads this data, and enhances it by taking the place name "Vulci" and comparing it to a list of known places in an internal gazetter called Metamorphoses. This has been built up by pulling together ad hoc catalogues from the various projects at Oxford, and gradually enhancing the entries with latitude and longitude acquired by finding places on Google Maps or Earth, and cross-referencing sites from Geonames (http://www.geonames.org/). By then consulting PleiadesPlus (http://googleancientplaces.wordpress.com/2011/01/24/pleiades-adapting-the-ancient-world-gazetteer-for-gap-%E2%80%93-by-leif-isaksen/), we can enhance the gazetteer still further with links to Pleiades. The end result looks like this, utilizing the skos:closeMatch relationship to link up our internal place Vulci: with Pleiades and Geonames

<E53_Place rdf:about="http://id.clarosnet.org/places/metamorphoses/place/vulci">
 <rdfs:label>[IT] Vulci</rdfs:label>
 <P87_is_identified_by>
   <E48_Place_Name rdf:about="http://id.clarosnet.org/places/metamorphoses/placename/vulci">
     <rdf:value>Vulci</rdf:value>
   </E48_Place_Name>
 </P87_is_identified_by>
 <P87_is_identified_by>
   <E47_Place_Spatial_Coordinates rdf:about="http://id.clarosnet.org/places/metamorphoses/place/vulci/coordinates">
     <claros:has_geoObject>
       <geo:Point xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#">
         <geo:lat>42.4167</geo:lat>
         <geo:long>11.5833</geo:long>
       </geo:Point>
     </claros:has_geoObject>
   </E47_Place_Spatial_Coordinates>
 </P87_is_identified_by>
 <skos:closeMatch rdf:resource="http://pleiades.stoa.org/places/413393#this"/>
 <skos:closeMatch rdf:resource="http://sws.geonames.org/3163940/"/>
 <P89_falls_within rdf:resource="http://id.clarosnet.org/places/metamorphoses/country/IT"/></E53_Place>

Now we can match the "VULCI" from earlier on with this "vulci", and rewrite the <P7_took_place_at> as <P7_took_place_at rdf:resource="http://id.clarosnet.org/places/metamorphoses/place/vulci"/>; this now lets us assert that http://www.beazley.ox.ac.uk/record/AA1CD952-927D-41D7-B7AF-39520936CF95 is associated with http://pleiades.stoa.org/places/413393#this in some way, which is where we meet Pelagios.

Most of the normalizing process is done in a single XSLT 2.0 transform (which also does quality checks of the RDF) of incoming RDF XML, working with the Metamorphoses RDF and a lookup XML file listing common spelling mistakes. When the resulting rewritten RDF is loaded into the triple store, additional inferences are performed to make subsequent retrievals easier. This process is, of course, very open to change and refinement, and as CLAROS develops we will no doubt rewrite it all.

Does it work? CLAROS' gazetter currently defines about 7300 places, of which only 1442 are linked to Pleiades. But bearing in mind that CLAROS has a lot of modern place names, and a lot of ones in the middle and far east, we are not dissatisfied with progress. Our next step will be to gradually go over places in the obvious countries (Greece, Italy, France, Germany etc), and check them against Pleiades, with the target of complete synchronization across the Mediterranean. It will be slow work...

Converting the Ure Museum data

2011-12-13T14:15:00.016Z

The Ure Museum of Classical Archaeology in Reading, is one of the most recent Pelagios partners. I have just started work on converting the collection data into a Pelagios-compliant format with the help of the curator, Amy Smith.

The main task involved in this is finding a way to figure out for each item in the collection whether there are any places in Pleiades associated with the item. Once we have done this, it should hopefully be straightforward to turn this data into OAC annotations for Pelagios.

You can browse the Ure Museum database online here. There are about 3000 objects in the collection. Any information about places associated with an object is generally under either the 'Fabric' or 'Provenance' listed for the object. The fabric is usually an adjective describing where the item was thought to have been made e.g. Boeotian, Etruscan, Daunian. The provenance is generally less structured. Here are some examples of the contents of this field for a selection of different objects:

Probably made in Cyprus (Stubbings)
Found on Mount Helicon with an arrowhead, 26.7.13
Northern Boeotia (?), provenience unknown
From a burial somewhere in the Argolid.
Thought to be from Cyprus: T.146.II. From Poli? Cf. JHS 1890.
Unknown, similar to Larnaca, Kamelarga finds
From Carthage (or other North African site)
Central Italian, possibly from the vicinity of Rome.
Cast from an original in the Acropolis Museum, Athens
Said by vendor to have come from between Thebes and Chalcis

I have been given all the data as an XML dump and want to write a script to match any places in Pleiades with this information from the 'Fabric' and 'Provenance' fields in the data. I also have a copy of Pleiades+ which provides toponyms from GeoNames for the places in Pleiades. You can read more about Pleiades+ here and here.

The rough approach I have taken is to go through each item in the collection and then for each item, go through all the places in Pleiades+ and see if any match with anything in the Fabric or Provenance field. I am hopefully not far off getting all the special cases sorted out and should have this completed in the early new year.

Here are a few of the challenges and issues that I have encountered so far.

1) Uncertainty in the data

This was one of the first things that concerned me. As you can see from the examples above there is often a large degree of uncertainty about where items are from. In addition, items may not have been found in some spot that even has a name and may have more than one place associated with them if they have moved locations. However, as I was reminded by Leif, these are annotations we are providing. So you can provide multiple annotations for an object, it's perfectly fine to annotate an object with any location that it is remotely associated with and an annotation does not indicate an object's definite origin.

2) Location-based adjectives

Most of the fabric information is give as adjectives rather than as the place name e.g. as Corinthian rather than Corinth. Even in the Provenance data there are still lots of adjectives. Adjectives associated with a place are outside the scope of Pleiades+, so I have compiled a list of how adjectives map to places with the help of Amy. It is relatively limited because it's restricted to adjectives used in the Ure Museum database as it stands, but would it be useful for us to share this list and allow other people to add to it in some way?

I should point out that there are still some question marks even with this approach e.g. would you want a reference to Roman Britain to map to Rome? However, I suspect the number of controversial mappings is going to be small.

3) Disambiguating places

Sometimes there are multiple places with the same name. For example, there is more than one place called Salamis. How do we make sure that if we know we want the Salamis in Cyprus then it matches to http://pleiades.stoa.org/places/707617/ rather than say this Salamis? Again this is where the 'connections with' information in Pleiades would help in theory. However in practice, it looks likely that we are going to have to deal with these ambiguities as special cases in the script.

4) Granularity of annotations

If we have an object from Salamis in Cyprus, do we annotate it with both Salamis and with Cyprus or just with the more precise location, Salamis? You wouldn't necessarily expect every item from Rome to also be annotated with Italy so using the more precise location feels sensible. On the other hand it may not do any harm to annotate with both and if we do have two places associated with an object, how do we tell that one is contained within another? Pleiades has information about which places 'connect with' other places and according to Sean Gillies of Pleiades, 'you'd almost never go wrong in Pleiades by inferring containment between a precisely located place of small extent and a much more extensive place' if you used this data. However, there is a great deal of connection information missing from Pleiades, so in practice this approach is unlikely to work well.

5) Pleiades locations enclosed in text not related to the location

If you just go through the Pleiades+ data and search for each place in term in the text associated with the object, you get lots of false hits, partly because there is some slightly odd data in Pleiades such as http://pleiades.stoa.org/places/324652/. Most of these you can rule out by assuming that place names will be capitalised in the Ure Museum data and by insisting on whole word matches. However there are still occasional problems. For example the Pleiades place Artemis matches 'Sanctuary of Artemis Orthia, Sparta' and you may also want to rule out locations of museums mentioned. I have been writing special cases in my script for these. I can do this because the collection isn't too large, but I can see that with a larger collection I can see that you could easily miss some instances like these. I have wondered if the GeoParser used for GAP might help with dealing with this type of unstructured data.

6) Alternative toponyms not in Pleiades+

Pleiades+ doesn't claim to be comprehensive and I have come across a fair number of alternative toponyms, again with Amy's help, not in Pleiades+, also writing these into my script as special cases. Some of these are from the Barrington Atlas Notes in Pleiades but there are others as well. As with the adjectives, I'm wondering if there is some way of sensibly sharing alternative toponyms that we have found so as to prevent other people having to duplicate our work.

7) Vague geographical data

There are quite a few provenance entries which include locations like 'South Italy' or 'Greek Islands'. There is no way of specifying these that I have found in terms of Pleiades locations, so I have had to resort to annotating them just with 'Italy' or 'Greece', losing some of the information. Objects are also often described as being found in modern countries or places that don't always have a clear equivalent in Pleiades.

8) The historical scope of Pelagios

The Ure Museum contains objects from a wide range of periods. Pleiades focuses on the Greek and Roman world and Pleiades in a sense defines the scope of Pelagios. However, should I still annotate a Neolithic object for example with the larger region from which it comes even if the precise location is not in Pleiades?

9) Spelling mistakes in the data

There aren't too many of these, but I have also had to include some special cases for spelling mistakes (as well as for alternate transliterations of place names). Obviously the ideal solution is to get the spelling mistakes fixed in the database itself and then get a new download of the data, but I thought I should highlight this as a potential issue. If the data has only been read by humans previously who unlike a computer can easily understand what is intended, it is easy for these typos to slip through.

10) Dealing with updates to the data

It is obviously likely that more data is going to be added to the Ure Museum database as time goes on. It would obviously be possible to rerun my script but there are enough special cases that it would hard to guarantee that any new results would be comprehensive and accurate.

Next stages

Overall this is proving a really interesting exercise and good introduction to the world of Pelagios. Once I have finished on the special cases, the next stage will then be to turn the data into OAC annotations and arranging where the data is going to be hosted. In the meantime, I'm off for the next few weeks seeing what my one-year-old makes of Christmas!

Pelagios Phase 2: Project Plan

2011-12-09T15:46:00.000Z

Phase two of Pelagios looks to build on our lightweight framework, based on the concept of place (a Pleiades URI) and a standard ontology (Open Annotation Collaboration), by publishing the Pelagios Toolkit-a set of services and documentation that will assist people in annotating, discovering and vizualizing references to places in open online ancient world resources.

In all, there are four Work-Packages:

§ WP1 casts the net beyond the existing partners in order to allow anyone to publish their data in a way that maximizes its discoverability. This webcrawling and indexing service will find material and - based on the Pelagios framwork and semantic sitemaps - aggregate place metadata in order to create value for the holders of that data.

§ WP2 aims to explore further ways of exploiting the concept of place. The place/space-based APIs and contextualisation service will help other users and data-providers discover relevant data and do interesting things with them.

§ WP3 tackles end-user engagement: i.e. subject specialists who lack the technical coding expertise to use the data underlying what it seen on the screen. The visualization service will explore ways of allowing these users to get to grips with the data both in a single Pelagios interface but also as embedded widgets hosted on each partner’s site.

§ WP4 distils the guidelines into a cookbook providing explicit recipes for producing, finding and making use of geoannotations for the community as a whole. In short, you won’t need to be a Pelagios partner to be able to join-in in making your data discoverable and usable.

The evolving nature of the Pelagios collective reflects the shift towards community engagement. While partners from the original Pelagios proof-of-concept project will continue to be involved, the main work for phase two of Pelagios will be carried out by: Arachne, CLAROS, DME, Fasti-online, GAP, IET (the Open University), Nomisma, Southampton, SPQR, the Ure Museum.

Deliverables

The outcomes, in more detail, are as follows:

D 1.1: Web Crawling and Indexing Prototype. This infrastructure component traverses resource sets on the Web (registered manually or discovered using semantic search engines like Sindice) and catalogues their place metadata. Place metadata encompasses geographical coordinates as well as Pleiades and Geonames URIs.

D 1.2: Pelagios 2 Graph API. This deliverable is an HTTP API that allows querying of the aggregate data graph generated by the Indexing Prototype. The API will provide responses in JSON and RDF format; and possibly in additional formats (e.g. KML or GeoRSS) if the need is identified in WP3. The initial range of possible queries is based on the outcome of the Pelagios project. The exact scope and structure of the final API will be driven by the requirements identified in WP3.

D 1.3: API Statistics and Reporting Interface. This deliverable will extend the Pelagios 2 Indexing Prototype with means to extract statistics and reports on the use of the API. Data partners can use this interface to gain insight into how their data is being discovered, queried and re-used within the larger online community.

D 2.1: Place-based API. This deliverable will extend the Pelagios 2 API with queries that return resources relevant to specific places or those with mereological (part-whole) relationships.

D 2.2: Space-based API. This deliverable will extend the Pelagios 2 API with queries that permit searches based on geographic scope, e.g. within a certain geographic buffer around a given location set.

D 2.3: Contextualisation Prototype. This deliverable is a service that provides ranked, relevant materials for a certain place or particular Named Entities. Results will be enriched with additional data from sources such as GeoNames, DBpedia and Freebase.

D 3.1: Evaluation of User Needs. This deliverable will report on the results of a formal evaluation of user needs regarding data visualization. The evaluation will be conducted in conjunction with project partners, and will inform the design of a set of online visualization widgets. This deliverable will have the form of a series of blog posts.

D 3.2: Widget Suite, Alpha version. This deliverable encompasses the first (alpha) version of the visualization widgets.

D 3.3: Evaluation of Widget Design. This deliverable will report on the results of observational and participatory design studies. The studies will be conducted on the Widgets as they are continuously and iteratively being developed from alpha state to final (beta) prototype. This deliverable will have the form of a series of blog posts.

D 3.4: Widget Suite, Beta version. This deliverable encompasses the final (beta) version of the visualization widgets.

D 4: Pelagios 2 Cookbook. Content Partners will produce regular documentation on data preparation, practices, tool use, etc. in the form of blog posts. The PI, assisted by the Co-Is will distil this information into a “cookbook” which will make it easier for anyone with Ancient World content to publish their data online in conformance with the Pelagios 2 common open standards.

Welcome to Pelagios - Phase 2

2011-12-03T15:40:00.023Z

Pelagios is a growing collective of ancient world projects who are linking together their data so that scholars and members of the public are able to discover all different kinds of stuff about ancient places.

Phase 1 has been the proof of concept. In this stage we have linked some core ancient world projects to each other through the concept of place (a Pleiades URI) and a baseline ontology (Open Annotation). The value of those linkages is demonstrated in the Pelagios Explorer, which allows users to discover and investigate the data from those different projects in a handy search interface.

The second phase of Pelagios is to formalize that process by which anyone can join or enjoy the fruits of the Pelagios superhighway. We will provide a ‘digital toolkit’ for anyone producing material about the ancient world—not just universities but also museums, libraries, etc—, so that their data will be more discoverable and usable. We will also be experimenting further with methods of visualizing that data so that subject specialist users and the general public can discover information about places that interest them, without having the technical expertise to do the digging themselves.

The Pelagios kick-off meeting in Greenwich: (back row) Andy Meadows (Nomisma), Sebastian Rahtz (CLAROS), Liz Fitzgerald (IET), Amy Smith (Ure Museum), Elton Barker (OU), Rainer Simon (DME), Alex Dutton (CLAROS); (front row) Leif Isaksen (Southampton), Simon Hohl & Rasmus Krempel (Arachne), Juliette Culver (IET)

It was taken by a plaque reading "Greenwich: still the centre of space and time"

How do we balance supporting novice spatial users alongside experts? Or, is geospatial analysis necessarily GIS?

2011-11-30T09:14:00.001Z

The task for table 5 at the #jiscGEO breakout discussion was to come up with a recommendation about how to balance the needs of newcomers to geospatial analysis with those of ‘experts’ in using Geographical Information Systems (GIS). To have greatest impact and value for the community, there was general agreement that any strategy should address the needs of the subject specialist user community. This means exploring how the technology can be made to work for the user, rather than necessarily ‘up skilling’ the user to become a technical expert (say, in GIS).

By focusing simply on technology training, there is the danger that, as well as being seen as irrelevant, too difficult or simply just boring for users (academics or students), the data gets overlooked or is made to fit a ‘system’ of analysis. For example, one problem of using GIS in humanities is the issue of ‘fuzzy’ data. This isn’t just a case of the system failing to cope with fuzziness: it also betrays an underlying assumption that data can, and should be, disambiguated and clear. For humanists, however, the questions driving research are often precisely those that look to nuance or complicate the material. We like messy results. Humanists need worry less about producing an accurate and/or truthful representation and more about how maps can be used as entry points to explore the data—this is seeing maps as part of the investigative process rather than as an end in and of themselves.

Ideally, then, users should be involved in the development, enrichment and adaptation of geospatial technologies, to make those tools work for them. Therefore, we recommend that JISC should build on their contacts within the HE sector to have teams of subject specialist users (i.e. the successful projects) go into universities, where this is already a JISC presence to help co-ordination, to show the target group the kinds of geospatial technologies that can be used and get them involved in shaping these tools for the future—the ‘show and tell’ unconference rolled out across the sector, as it were.

Elton, Nicola, Rasmus, Claire, Ryan, Addy

Growing use of OAC - an inventory (no doubt incomplete) of initiatives

2011-11-27T10:25:00.002Z

As the Pelagios project’s Common Ontology for Place References (COPR) is based on the Open Annotation Collaboration ontology, JISC (in the person of David Flanders) suggested a blog post on the growing use of OAC in HE and research. It’s a bit late - blogger’s block - but here it is. Many thanks to Rob Sanderson for his useful input.

A lot of the work being done is in the humanities, where research practice is more human-centric and “annotation” - with various meanings - is a core component of research, or a fundamental “scholarly primitive”. Textual studies is a particularly active area:

Stanford University has been using AOC for work on annotating digitised mediaeval manuscripts. As these are frequently illustrated, this involves annotating structured text (maybe already marked up using TEI XML) and images within the texts. This has been taken up more widely in the SharedCanvas project, whose results are being used by various libraries and universities for annotating mediaeval manuscripts, including the British Library, Bibliotheque National de France, and the Bodleian in Oxford, among others.

Emblem Books are another fruitful area for annotation. These form a genre of book, popular during the 16th and 17th centuries, containing collections of emblematic images with explanatory text, usually aiming to inspire the reader to contemplate some moral issue or other. The University of Illinois at Urbana-Champaign and Herzog August Bibliothek Wolfenbüttel have been collaborating with the Emblematica Online project on using OAC for annotating digitised emblem books. This also involves annotating structured text and images, although in printed books rather than manuscripts.

The AustLit project, based at the University of Queensland in Australia, has been applying OAC to the development of scholarly critical editions, specifically for annotating variations between different versions of a literary work.

An analogous approach could be used with variants within a “stemma” or family of manuscripts. In fact a use case of our own may be provided by the HERA-funded SAWS project, which is looking at complex relationships between mediaeval Greek and Arabic manuscripts of “wise sayings”, so-called gnomologia. I will be looking into this further.

A little (but not entirely) beyond textual studies, OAC is also being used for annotating historical maps - the Digital Mappaemundi project at Drew University is looking at methods of dealing with mediaeval maps and related geographical texts - in fact these maps can be thought of as complex images with original annotations, so the model may fit very well. Also at Cornell, the YUMA Universal Media Annotator (YUMA) tool has been used with OAC to annotate historical map collections.

OAC has also found applications in the digital libraries and archives world (the applications are not entirely disjoint from the above):

The US National Information Standards Organization (NISO) and the Internet Archive have launched an initiative for developing standards for creating and sharing bookmarks and annotations in e-books (announced October 2011), with various publishers interested. This will take on board the work done in OAC, although the standards developed will go beyond this.

Brown University Library is developing an annotation framework for the Fedora digital repository software based on OAC, linking the annotations created directly with TEI-encoded texts in their repository, and exploring how annotations can be attached to structural and semantic elements within those documents. Brown’s Women’s Writers Project will provide one of the initial test cases.

MITH (Maryland Institute for Technology in the Humanities) have been collaborating with the Alexander Street Press on using OAC to store annotations on their streaming library of educational videos. As an example of what they intend, they have produced a working prototype that allows shapes to be drawn so as to select regions of video for annotation.

And just to show that the sciences are not being ignored here, BIONLP at the University of Colorado - who work on natural language processing of biological texts - are investigating the use of OAC with entities and relationships automatically mined from such texts, and the FP7 Wf4Ever (Workflow Forever) project is using OAC for annotating research objects.

Any more contributions to this list happily accepted!

The Pelagios Graph Explorer: An information superhighway for the ancient world

2011-11-11T21:06:00.000Z

Just as the settlements around the Ancient Mediterranean would seem disconnected without the sea to join them, so online ancient world resources have been separated, until now. Meaning “of the sea”, Pelagios has brought this world together using the principles of Linked Open Geodata. The Pelagios Graph Explorer allows students, researchers and the general public to discover the cities of antiquity and explore the rich interconnections between them.

The Pelagios Graph Explorer
Alice is an archaeology student from Memphis, TN. When not collecting Elvis singles, she loves nothing better than to find out about cities of the past. Recently she has come across Arachne, the database of images and finds from the German Archaeological Institute. She's interested in her hometown's namesake, Memphis, Egypt, and so she types it into the search box (fortunately it's the same word in German) and finds quite a few interesting results: 21 objects and 16 sets of photos. But what do they mean? What stories do they tell? And what role did Memphis play in the ancient world? What Alice doesn't know is that there are many other open resources out there with information about Memphis, its history and material culture and has no way to find out.

Enter the Pelagios Graph Explorer. Using the principles of Linked Open Data, the Pelagios Explorer allows people like Alice to discover those resources (including Arachne). When she types 'Memphis' into the Explorer's search box she is presented with a graph of information that shows her a range of different resources that relate to the city. Hovering the mouse over the pink circle, a balloon pops up about the Perseus Digital Library which seems to have 13 separate references to it. And clicking on a reference in the data view takes her straight there.

Now that's all well and good, but it rather begs the question: How would she find out about Pelagios in the first place? The answer is simple. As well as being a human interface, Pelagios is also an API, allowing resource curators to embed links right next to their own content. For instance, Carlo the classicist might be exploring the geographic flow of Herodotus's Histories using GapVis which has lots of handy info - a map, related sites, photos, etc. But the handy 'Pelagios Graph Explorer' link takes him straight to Pelagios and even fills in the details for him. This is the power of Linked Open Data - content providers such as Arachne can open up up a world of contextual information with a single link.

There's a lot more we could tell you about Pelagios - the fact that you can use the Explorer to find relationships between multiple cities for instance, or that it's an ever-growing collective of content providers committed to the principle of openness and public access. We could also tell you about the plans we have for Pelagios2 - to refine the data, improve the search facilities, and expand the community. But we think the best way to explore it is to have a go yourself. So why not check out our user guides and dive in!

Who are Pelagios?

Pelagios is a collective of projects connected by a shared vision of a world - most eloquently described in Tom Elliott’s article ‘Digital Geography and Classics’ - in which the geography of the past is every bit as interconnected, interactive and interesting as the present. Each project represents a different perspective on Antiquity, whether map, text or archaeological record, but as a group we believe passionately that the combination of all of our contributions is enormously more valuable than the sum of its parts. We are committed to open access and a pragmatic lightweight approach that encourages and enables others to join us in putting the Ancient World online. Pelagios is just the first step in a longer journey which will require many such initiatives, but we welcome anyone who shares our vision to join us in realising it.

Members of the Pelagios Team at our February 2011 kick-off workshop. From left to right: Rainer Simon, Greg Crane, Mark Hedges, Reinhard Förtsch, Mathieu D’Aquin, Elton Barker and Sean Gillies. Missing from the photo are: Leif Isaksen, Sebastian Rahtz, Sebastian Heath, Neel Smith, Eric Kansa, Kate Byrne, Tom Elliott, Alex Dutton, Rasmus Krempel, Bridget Almas, Gabriel Bodard and Ethan Gruber

Pelagios was made possible by the following organizations:

TABLE OF CONTENTS
Project Plans

Budget

Budget Plan

Project Progress

Technical Progress

Usability

General Commentary

What Makes Spatial Special?

2011-11-09T15:28:00.000Z

One of the nice aspects of being part of the jiscGEO programme is that occasionally we're thrown slightly more philosophical questions to chew on. The most recent one is simple but broad: 'What makes spatial special?' This is hardly a new topic of course, as one of our co-projects has pointed out. A lot of people have discussed the
significance of the Spatial Turn and Kate Jones has done an excellent job in summarizing many of the key arguments. Rather than repeat them here I thought I'd approach them from a different angle: 'Why has Space become special and not Time?'

On the face of it the two have a great deal in common. For a start they are both values that not only underpin virtually any kind of information you can think of, but as dimensions (or a set of them) they also form a ratio scale which enables us both to order it and calculate relationships such as the closeness and density of data. As the simpler of the two (with just one dimension to deal with, rather than two or three), time seems by far the easier value for people to engage with. And yet there are no Temporal Information Systems, no Volunteered Temporal Information, no Temporal Gazetteers, no 'Temporal Turn' to speak of. So why has space, and not time, become the darling of the digital zeitgeist? Here's my theory: Because we experience space statically but time dynamically, a social asymmetry exists which makes spatial descriptions more useful socially.

Both time and space are affected by the Inverse Square Law of Relevance: as every good hack knows, a person's interest in a topic tends to fall off the further away they are from it, temporally and spatially. Of course that's not an absolute rule, but on the whole people are considerably more interested in today's home game than they are in foreign matches from yesteryear. The difference between space and time is that populations perceive themselves as being randomly dispersed throughout space, whereas time seems to be experienced simultaneously[1]. As a result, maps appear to be universally relevant because the distribution of relevance is spread across them. In contrast, almost our entire global attention is focussed on just one (travelling) moment in time. So while a map of Britain is equally relevant to people in London, Bangor and Inverness, a timeline of Britain is not equally relevant to Saxons, Normans and ourselves because the Saxons and the Normans are dead.

Enough of the beard-stroking, why should we care? It seems to me that there are two important conclusions to be drawn from this. The first is that the importance of maps is created socially and not individually. Because their relevance is determined by having multiple points of view, they can be enormously enhanced through social Web
technologies which is why Webmapping, despite having far less functionality than GIS, has rapidly outstripped it in utility. The less obvious lesson is that despite its ubiquity, spatial relevance is not spread evenly. Sparsely populated parts of the world (i.e. most if it) are not considered highly relevant by many people. By the same token, places in which mankind congregates (cities) tend to be seen as highly relevant. We see this most clearly in the number and diversity of named places they create. Whereas unoccupied spaces tend to have a just a handful of big named places, densely occupied spaces have a name for every nook and cranny. That means to create really powerful, socially relevant maps we need to start thinking about visualizing places, rather than just spaces.

And what of poor old temporal technologies? Will we ever get people to be as interested in the past as they are in the present? That's for another blog post, but if you are interested, come and join us for the NeDiMAH/JISC workshop in Greenwich on November 30th where we'll be devoting plenty of space and time to the subject.

[1] Actually, physics gives us plenty of reasons to doubt that this is the case at all, but it certainly feels that way, which is what's...er...relevant here.

SPQR triples - inscriptions and papyri

2011-11-04T20:50:00.004Z

The SPQR project has produced just over half a million triples, describing approximately 57,500 inscriptions and papyri. The triples were derived from the following epigraphic and papyrological datasets:

The Heidelberger Gesamtverzeichnis der griechischen Papyrusurkunden Aegyptens (HGV), a collection of metadata records for about 65,000 Greek papyri from Egypt
The Inscriptions of Aphrodisias, a corpus of about 2,000 ancient Greek inscriptions from the city of Aphrodisias in modern Turkey.
The Inscriptions of Roman Tripolitania, a corpus of about 1,000 inscriptions from modern Libya.

The triples can be downloaded as RDF/XML from the following links:

Perseus and Pelagios

2011-11-04T12:31:00.005Z

The Perseus geospatial data now includes annotations of ancient places with Pleiades URIs. Beginning next week, the Places widget in the Perseus interface will include links to download the Pleiades annotations in OAC compliant RDF format. These links will appear for any text with place entity markup which also has places from this dataset. We are also providing a link to search on the top five most frequently mentioned of these places in the Pelagios graph explorer.

In addition, RDF files containing annotations for the occurrences across all texts in each collection will be available from the Perseus Open Source Downloads page.

To produce these annotations, we used the normalized and regular place names from the Pleiades+ dataset to identify likely matches with the Perseus places, and then the longitude and latitude coordinates from each source to validate and disambiguate these matches. Places which matched via this method are annotated with an "is" relationship to the Pleiades URI. For Perseus places which were not automatically mapped to a Pleiades URI via this method, we do a second pass at matching using the location coordinates, looking for Pleiades places within a certain range of the Perseus coordinates. Places which matched via this method are annotated with a "nearby" relationship to the Pleiades URI. These mappings are all stored with the Perseus place data in our database, and are available along with the other geospatial data for occurrences of these entities in the Perseus texts.

Going forward, we hope to be able to continue to work on improving the automatic alignment of the Perseus and Pleiades+ place data, as well as providing the means for manual refinement and correction of the annotations. In this initial pass, we were able to automatically annotate a little over 15% of the distinct ancient place names already identified in the Perseus texts. We would like not only to increase the percentage of matches with the Pleiades data, but also to begin to take advantage methods for automatically identifying place entities in the many texts in the Perseus repository which do not yet have this level of curation.

Adding more Nomisma Annotations to Pelagios: Direct links to Hoards

2011-10-31T03:13:00.000Z

I've updated the file of annotations that link Nomisma.org and Pleiades URIs. It's available at http://nomisma.org/nomisma.org.pelagios.rdf .

As a reminder, Nomisma.org is a project establishing stable web addresses (URIs) for concepts in numismatics, which is the study of coins. We have simple definitions of mints, as in the page at http://nomisma.org/id/athens. Go there and you'll see there's not yet much information about the ancient mint of Athens itself. You will, however, see a map of hoards in which coins of Athens were recorded. That's important evidence for economic connections in the ancient Mediterranean and beyond.

The first version of the Pelagios-compliant file that Nomisma published made simple "one-to-one" links from Nomisma mint URIs to the relevant Pleiades URIs. I've now updated the file so that all hoards are linked to the Pleiades URIs of the mints of coins within them. Or at least to the Pleiades URIs that we've entered to date. As in, the following XML excerpt indicates that hoard http://nomisma.org/id/igch0039 is linked to the Pleiades URI http://pleiades.stoa.org/places/579885.

<rdf:Description rdf:ID="igch0039">
<rdf:type rdf:resource="http://www.openannotation.org/ns/Annotation"/>
<oac:hasBody rdf:resource="http://pleiades.stoa.org/places/579885"/>
<oac:hasTarget rdf:resource="http://nomisma.org/id/igch0039"/>
<dcterms:creator rdf:resource="http://nomisma.org/"/>
<dcterms:title>Nomisma.org annotation linking http://nomisma.org/id/igch0039 to http://pleiades.stoa.org/places/579885</dcterms:title>
</rdf:Description>

It's important to note that the annotation doesn't make the nature of the relationship clear. As in, there's no suggestion here that the URI http://nomisma.org/id/igch0039 is itself an alternate definition of Athens. The annotation only says that http://nomisma.org/id/igch0039 makes reference to or adds to our understanding of Athens. In this case, the additional information is that coins of Athens are found in that place. But once this new file is ingested, it will be up to the user to click through from the Pelagios browser to find out why the annotation was made. That's the case for all the varied information that is making its way into the rich Pleagios ecosystem.

Pelagios usability testing results

2011-09-27T11:36:00.000+01:00

In my earlier posts, Evaluating Pelagios' usability and Evaluating usability: what happens in a user testing session?, I promised I'd share some preliminary results. Because my last posts were getting rather long, I'll keep this short and sweet.

I had two main questions going into the user testing: could a user discover all the functionality of Pelagios, and could they make sense of what they were shown? In short, the answer to the first question is 'no', and the answer to the second is 'yes'.

I'm a big fan of testing the usability of a site with real users. Test participants not only give you incredibly useful insights into your site or application, but they help you clarify your own thoughts about the design. It was exciting to see test participants realise the potential of the site - particularly the map and data views, which is a cue to make them more prominent when the site first loads - but it was clear that the graph interface needs improvements to make the full range of actions available for selecting, linking and exploring datasets more visible to the user. The test participants also used search heavily when looking for particular resources, so this would be a key area for future work.

If you've been working on a project, user testing is wonderful and painful in equal measures. It's definitely easier to test someone else's project, not least because it's easier to prioritise tasks from the users' point of view when you don't have to deal with the details of implementing the changes.

The overall goal of the usability testing was to produce a prioritised list of design and developmenttasks to improve the usability of the Pelagios visualisation for a definedtarget audience (non/semi-specialist adults with an interest in the ancient world), and this user testing was really successful in giving the team a clear list of future tasks.

Evaluating usability: what happens in a user testing session?

2011-09-23T15:14:00.004+01:00

In my last post I talked about the test plan for assessing the usability of the Pelagios 'graph explorer' for the project's (deep breath) 'non/semi-specialist adults with an interest in the ancient world' audience. Before I get into the details of what happens in a usability test session, I thought I'd introduce you to our design persona, Johanna.

Image credit: @ANDYwithCAMERA
Johanna is 21, and is a third year History student. She moved from her native Germany to the UK three years ago for university. Her goal is to get a First so she has more options for future academic work, perhaps in the Classics. She's slightly swotty, and is always organised and methodical, but finds that she's easily distracted by Facebook and chat when she's working on the computer. She can often be found having coffee or in the pub with friends, at her part-time job in a clothing store, or in the library (her shared house is often noisy when she's trying to work). She dislikes distractions when she's trying to study, and hates rude customers at work. She likes her bike, RomComs and catching up with friends. Her favourite brands are Facebook, MacBook, Topshop, Spiegel Online and The Body Shop. Her most important personal belongings are her laptop, her mobile phone, and photos of friends and family from Hamburg and college.

Johanna is technically competent, and prefers to learn through trial and error rather than reading manuals or instructions. But she also has limited patience and will give up on interfaces that are too difficult. Johanna is a heavy user of social networks and also uses online research databases and library catalogues.

Johanna has an assignment on inscriptions due in a month. She hates the emphasis on big battles and big men in the subject, and finds inscriptions dry, but has been told they can also convey interesting social history and cultural values. She's not convinced (and she's not sure whether she'll be able to make much of the language of the inscriptions) so she wants to find an ancient place that also has other historical material about it to make the assignment more relevant to her own interests.

To create our persona and design the test tasks, I quizzed Elton on the types of questions people ask when they find out he's a Classicist to get a sense of common (mis)perceptions and interests, and about the types of students he's encountered.

So, onto the usability tests themselves. The time and venue for each test was organised directly with the participant, with the restriction that we had to be able to get online, be in an environment where it was ok to talk aloud, and ideally we'd meet somewhere the participant would feel comfortable.

In my last post I mentioned writing and testings some set tasks for the usability test, a short semi-structured interview, and an introductory script. Once the participant had arrived, and was settled with a cup of tea or whatever, I'd introduce myself and explain how I came to be working with the project. I've included the basic introductory script below so you can get a sense of how a test session starts:

Thank you for agreeing to help us test the usability of the current interface for Pelagios.

We'll be using these tests to produce a prioritised list of design and development tasks to improve the Pelagios visualisation for people like you.

The session will take up to an hour and will start with a short interview, then your initial impressions of the site, and finally we'll go through some typical tasks on the site. I'll ask you to 'think aloud' as you use the site - a running stream of thoughts about what you're seeing and how you think it works. I might also ask you questions to clarify or explore interesting things that come during the session.

I want you to know that you're not being tested! We're testing the interface - anything that goes wrong is almost definitely its fault, not yours! Also, I haven't been involved in the project design, so you don't need to worry about hurting my feelings - be as direct as you like about what you're seeing.

I won't be recording this, but I will be taking notes as we go, and summarising them to pass them on the project team.

You can stop for a break or questions at any time.

Do you have any questions before we begin?

The next phase of the test session was the short interview. Again, I've included the questions below:

Demographic data: what is your age, gender, educational level, nationality/cultural background?
What websites do you use regularly (on a daily/weekly basis)?
What's your favourite website, and why?
What websites do you use in your research/daily work?
Have you seen sites like [Guardian, Gapminder, etc] that feature interactive visualisations?
How would you describe your level of experience with the classics? (e.g. a lot, a little). Do you focus on any particular area?
What is your definition of the classics? (Geographical, chronological scope)

Once the questionnaire was over, and any questions that had arisen had been discussed, the test began. The first part of the test covered first impressions of the 'look and feel' of the site, what they thought the site might be about, and what content it would include, and what they thought the 'blobs' that are the first view of the graph visualisation represented. I was also observing the kinds of interactions participants tried with the visualisation, whether single or double mouse-clicks, dragging, right-clicking, etc, because I wanted to know how much of the functionality of the site was intuitively discoverable.

The first formal task was: "find all the resources related to Cyrene" [or a place related to their own interests]. I'd note the actions the participants took along with their comments as they 'thought aloud'. Sometimes I'd ask for more information about why they were doing certain things, or remind them to tell me about the options they were considering. I also noted the points where the participant expressed confusion or frustration, or gave up on a task, though I didn't time the tasks or record a qualitative count of errors.

After the task, I'd ask (if it hadn't already come up):

What do you think these resources are?
How do you think they relate to your actions?
What contextual information might you need to make sense of these resources?

These questions were based on the team's review of the site and were aimed at making sure we understood the participant's 'mental model' of the site. If there's a mismatch between the users' mental model and what your site actually does, you need to help users develop a more appropriate mental model.

The second task, "Are there links between [Place 1, Place 2]? If so, what are they and how many are there?" was more open-ended and designed to see how participants managed small result sets on the site. Again, I had questions prepared as prompts in case they hadn't already been answered during the task:

What do you think you're looking at here?
What does the screen tell you?
What do you think the links mean/are?
What do you think the movements on the screen mean?
How do you interpret the results?
How do you think they're selected?

Finally, I asked some questions aimed at giving the project some metrics to measure improvement in the usability of the site after design updates: 'would you use the site again?', 'how likely are you to recommend it to a friend?'. The final questions were: 'what would you suggest as first priority?' and 'any final comments?'.

After running each test, I'd tidy up my notes and summarise the key points for the team so they could prioritise the next items of design or development work. Which leads me onto my next post, which will include some preliminary results...

Evaluating Pelagios' usability

2011-09-20T17:29:00.000+01:00

Hello! I'm Mia, and I was drafted into the Pelagios project to run some usability testing on the 'graph explorer'. (These days I'm working on a PhD in Digital Humanities in the department of History at the Open University, but until quite recently I worked as an analyst/programmer and user experience designer, mostly in museums, and in early 2011 I completed City University London's MSc in Human-Computer Interaction).

There's a range of usability methods we could have used to evaluate Pelagios' usability, but the 'gold standard' is user testing (basically, showing the site to typical users and gathering their feedback as they complete set tasks). It requires more resources to set up and run the user tests than other usability techniques, but it's particularly useful for 'novel' interfaces like the Pelagios visualisation. Other common methods are testing with paper prototypes (e.g. if you haven't got a working site), card sorting, or having experts review the site according to usability checklists (AKA 'heuristic evaluation').

Quite a bit of work goes into preparing and piloting user testing. Once I'd written a usability testing plan, I worked with Elton, Leif and Rainer to define the key audiences ('subject specialists' and 'non-specialists with an interest in the classics/ancient world' - specialist is a relative term in this context) and create a persona to represent the specific target audience we were going to test for,the snappily-titled 'non-specialist adults with an interest in theclassics/ancient world'. In addition to focusing our minds on the usability requirements of this audience and typical tasks they might undertake on the site, this persona would be used in future design processes to ensure the project delivers user-centred designs.

We also reviewed the available functionality and interfaces to design test tasks that would help us understand where improvements were needed to make the graph visualisation more useful to its audiences. The trick is to write tasks that make sense to the test participants that will also lead them to use key areas of the site. I also included an initial open-ended question to elicit overall impressions of the site, as it's a good way to gather feedback on the overall design and get a sense of what the participant thinks the scope of the site might be.

I also designed a short semi-structured interview - a set list of questions to ensure consistent data collection, with the flexibility to explore interesting issues that will provide insight into user requirements, expectations and mental models as they arise. I included questions on other sites the participants use regularly for research or leisure, as these will give some idea of their expectations of other sites. It's helpful to order your questions so the easy ones are first, as it gives the participant a chance to relax and get used to the situation. User tests use the 'think aloud' protocol, where the participant, well, thinks aloud, sharing the thoughts and questions that are running through their minds as they use the site and go through their tasks.

Meanwhile, Elton was recruiting participants - we were aiming to include people interested (but not yet specialist) in the Classics or ancient world, to match our target audience as closely as possible. Once I had the test tasks and interview in order, I wrote a short introductory script to read at the start of each testing session. This script helps the tester remember to give everyone the same information so the tests are consistent and the participant has a positive experience. I then ran a pilot test with a volunteer participant, including the interview and intro script - this is one of the most important stages, because it helps you refine your language so it's clear to people new to the project, check the timing of tasks and make sure everything works as expected.

In my next post I'll explain what happens in a usability test session, and share our design persona with you. In the post after that, I'll share some of the results... Post below if you have any questions or comments!

The Child of 10 standard

2011-09-16T08:31:00.008+01:00

While Pelagios has been largely about building an alliance of leading ancient world research groups with the aim of linking their data in an open and transparent way, the 'front end' of our product has never been far from our minds. After all, many of the partners are also users of the data that they gather, or, if not the actual users, they have their own user groups to think about and appeal to. As a classicist myself - that is, as someone who spends most of the time reading and analysing ancient Greek texts - I want to be able to access sources easily and trust the data that I get: in other words, I want to be able to turn on the tap and find that the water runs (either hot or cold, depending on what I'm doing); I'm not interested in the plumbing that brings the water to me.

So it is with timely fashion that JISC brought to our attention a fellow jiscGEO project, called G3. In an earlier post, they had talked about a useful benchmark in user interface design being the Child of 10 standard, meaning that a child of 10 should be able to learn to do something useful with the system within 10 minutes. This indicates whether a system is “easy to use” or not.

Will our tool, the Pelagios Graph Explorer, fit the bill, I wonder? While our natural target audience are university researchers (lecturers and undergrads), given the seemingly never-ending appeal of Classics in popular culture, we would be mad not to take seriously the point that a 10 year old should be able to use our tool to find out interesting stuff about the ancient world. Indeed, the technical skills of the average Classicist researcher - not least this one - makes it imperative that we address this question. At the time of writing, then, we are currently engaging in user testing of the Graph Explorer with a sample representative audience, the results from which we will help inform our delivery of the product at the end of October (though it's already clear that this will be a work-in-progress...). All next week Mia Ridge, who has been conducting the user testing, will blog about it, setting out the methods (why we chose them, what prep is done), what actually happens in a session, and then some initial results.

But I can give a sneak preview here of the answer to that question, does the Pelagios Graph Explorer pass the *child of 10* test. On current performance, that would be a 'no'. Which is not to say that things haven't gone well! On the contrary, the very fact that issues are being raised with what you can do now that stuff is linked shows how successful we've been in linking our data: when we started out, it simply wasn't possible to imagine an ancient world of linked data, let alone think seriously about traversing it. But now that we have linked stuff together, the bar has been raised and people - rightly - want to do more with it. This presents a challenge to all the Pelagios partners to provide as much detail as possible in their metadata, in order to allow the kind of free play that a 10 year old - or a classicist - might want.

Perhaps we could start with the name: the Pelagios Graph Explorer isn't very sexy. Suggestions on the back of a postcard, or, ideally, on this blog, welcome.

(Re-)Using the Graph Explorer Pt. 3: Getting Your Data Inside

2011-09-08T05:59:00.000+01:00

With a little delay, I'd like to conclude our 3-part introduction to the PELAGIOS Graph Explorer (see here for part 1 and part 2). This time we're looking at data importing.

Data Preparation - the Basics

Getting our initial batch of data from the PELAGIOS partners into the Graph Explorer was both easy and a bit of a challenge at the same time. As for the easy part: the two 'PELAGIOS principles' of...

aligning place references with PLEIADES and
using the OAC vocabulary to express them in RDF

make the 'baseline' import almost effortless. We can simply parse the RDF, pick out the OAC annotations, verify whether they point to a valid Pleiades URI - job done. Therefore, if you want to make your own data PELAGIOS-ready, complying with these two principles is really all you need to do. We've included some RDF samples into our code repository, which you can use as a reference regarding the exact RDF syntax. Furthermore, we are also working on a (yet unfinished) online application that generates maps from properly-formatted data dumps, thereby providing online validation for your data.

Structuring the Data

Now on to the advanced part... Once you have produced your OAC-formatted list of PLEIADES URIs, it's really just that: a long, flat list of places. Already that's useful for building basic visualizations - such as maps showing a dataset's geographic extent, or Google-Map-mashups where pushpin-markers link to source texts. But for the Graph Explorer, we wanted to show a more fine-grained picture of the connections within the data.

Usually, a dataset will have some sort of internal hierarchy: a subdivision of an archaeological collection into different sub-collections perhaps; or a structuring of a text corpus into books, subdivided into volumes, chapters, paragraphs and so on. Speaking in terms of the Graph Explorer, this means that when we search for, say, Memphis and Delos, it can tell us that both are mentioned on Herodotus, page 125, rather than giving us the (somewhat less useful) information that both are referenced in GAP's Google Books dataset.

Unfortunately, the 'PELAGIOS principles' don't define an explicit mechanism for expressing such structural information at the moment. Nonetheless our partners' datasets often reflect hierarchy in the design of their resources' URIs: for example, GAP's Google Book URIs carry book IDs and page numbers; annotations provided by Perseus include subdivisions into individual chapters, sections, poems, etc.

To make the Graph Explorer's output more useful, I therefore exploited this implicit information to build the hierarchy in the import script. The import scripts also generate human-readable labels for the hierarchical dataset units, based either on consultation with partners (e.g. we simply agreed on how we would name SPQR's sub-collections and coded that into the import script), or additional metadata in the data dumps (e.g. GAP has rdfs:labels included in the data dump to define the labels).

In hindsight, it may have made sense to think about such an additional 'principle' to cover this (e.g. by including an RDF vocabulary like VoID). But then again, at the start of the project the discussion was very much revolving around the groundwork of getting datasets aligned at all, and the Graph Explorer was still yet a vague idea. (Not to mention that the sheer diversity of the datasets would make the development of a consistent, reasonably fine-grained description scheme a project in its own...)

Importing your Data

The bottom line of all this is: getting a hierarchical, custom-labeled dataset into the Graph Explorer will still require some manual tweaking (read 'coding effort') at the moment. With a little bit of Java development skills, the process should be fairly viable, however: the essential importer classes are fairly well documented, and there are a number of code examples in the repository.

By the way: we've implemented most of the importers in the Java-based scripting language Groovy, which worked really well for us and helped us trim down the size of the import scripts by some lines of code, compared to plain old Java. In particular I'd recommend taking a look at the GAP and Perseus importer source code to get started.

P.S.: The online demo of the PELAGIOS Graph Explorer is available here. Screencasts explaining the basic usage are in this blogpost: The PELAGIOS Graph Explorer: A First Look

An Update for the Arachne-Pleiades annotations

2011-08-25T15:45:00.013+01:00

After some bug fixing and general fiddling, we are happy to announce a 'new and improved' version of the 'Arachne to Pleiades matching'. The earlier blogpost explains the main efforts behind this work: here I will mention what has been improved since the first delivery of annotations.

The major new features are:
* Human readable contents behind the Arachne URIs (places, topographical units, objects)
* Improved matching labels using regular expressions
* Annotation of Arachne objects

1. Human readable content behind an URI

This means that the URIs in the annotations can now be used to check what lies behind them and deliver the results in a human friendly form. Normaly an URI is "just" an Identifier, but If you copy the URI of Arachne Dataset to your adressbar the Brower redirects you to the identified Arachne Entity in the Arachne Database. The URI can also be used as an URL.

Examples:
Object: http://arachne.uni-koeln.de/entity/1075708
Place: http://arachne.uni-koeln.de/entity/1206008
Topographical Unit: http://arachne.uni-koeln.de/entity/5152

2. The matching of the labels from Pleiades has been enhanced in the following way:

The old matching like described in step 2 has been enhanced by using regular expressions in the SQL-queries. Regular Expression are a standard, for the expression of text-search patters. These expressions .The Pleiades labels have been cleaned of any regular expression characters like . ? * [ ] and (), which would interfere with the matching process. In addition labels smaller than three characters are ignored because with the regular expressions they could create too many meaningless matches. The new matching, for example, handles that the labels of the Pleiades data set are correctly matched to fields that contain enumerations of Place names.

For Example a field with alternative Placenames contains "athen,atenes,athens" Then it wont match exactly to the string "athen" (the german Version). Its a substring of the String "athen,atehes,athens".
On the otherhand we don't want to match "athen" with "rathenow". Rathenow is not even near Athens. This Problem can only be solved with an Text search pattern like a Regular Expressions.

Also some bugs have been fixed that unintentionally lead to skipping some Pleiades labels in the matching process.

3. Annotations of Arachne Objects:

The data has also been extended, so now the annotations contain links to objects, which form the largest part of the Arachne Database. For every matched place in Arachne the objects that refer to these places are collected.
for example:
A Pleiades Places Links an Arachne Place which Links some Arachne Objects.
Now the script links the Arachne Objects directly to the Pleiades Place, skipping the Arachne Place.

This is done in context of Step 4.

These changes sound quiet small but they have an imense impact. The bugfix and some other changes have been more than doubling the ammount of Arachne Place to Pleiades Place annotations. The Annotations of Objects nearly exploded. As seen in the Example pictures each Place Link creates several Annotations linking Arachne Objects to Pleiades Places.
Connections Links these tend to explode. If the average Arachne Place is connected to 5 Arachne Objects there are 5 Times more Pleiades Place to Arachne Objects Annotations than there are Pleiades Place to Arachne Place annotations!

(Re-)Using the Graph Explorer Pt. 2: API

2011-08-11T15:21:00.003+01:00

The PELAGIOS Graph Explorer HTTP API exposes the data from the visualization in JSON format, with Place geometry encoded as GeoJSON. Since the Graph Explorer runs entirely on the API internally, all of the operations you can see in the visualization are also available through the API - from place search to finding intersections between datasets, to getting the source data references.

The design of the API has been somewhat ad hoc: the approach was to be pragmatic, quick, and build in the essentials needed for the visuals, no more, no less. If you are re-using it for other purposes which we haven't anticipated (different types of visualizations, analyses, etc.) you are likely to encounter situations where you lack certain features, would have expected things to be named or organized differently, or miss a bit of documentation here and there, I assume. But bear with us - it's an alpha version & this is exactly the kind of feedback that's valuable for us! We're excited about anyone trying out things with the API we haven't thought of!

Visit our Wiki to learn the basics and see some live examples.

P.S.: An online demo of the PELAGIOS Graph Explorer is available here. Screencasts explaining the basic usage are in this blogpost: The PELAGIOS Graph Explorer: A First Look

(Re-)Using the Graph Explorer Pt. 1: Technology

2011-08-11T08:02:00.009+01:00

As announced, I would like to use the next couple of posts to provide a little technical information on our PELAGIOS datavisualization demo, aka the Graph Explorer.

In this post I'll provide a quick rundown of the technologies we have used to implement the demo. So if your interest is in understanding the code, deploying it on your own server, etc. then this post is for you!

If you don't care about the details under the hood, but want to use the API to build your own mashups: this will be covered in the next post.

If you're not interested in tinkering with the application at all, but rather want to know how you can get your own data into the graph, or create your own data aggregations: we'll cover that in part III, which will focus on the data-end of things.

Architecture

In terms of architecture, the Graph Explorer is a pretty standard Web application: the user interface is implemented in JavaScript, so it should run in any reasonably modern browser, with no need for extra plugins (i.e. no Flash or Silverlight involved). It makes heavy use of Scalable Vector Graphics to visualize the graph, aided by a few little helper libraries underneath for added functionality and eye candy.

The server side is implemented in Java. To make things work at reasonable speeds, the Graph Explorer keeps an aggregation of PELAGIOS partners' data in a database. (Right now it's actually just a small sample subset of about 75.000 data records total.)

Rather than using a relational database, we have used the Neo4j NoSQL graph database. Not only does this fit better with the graph-like structure of our source data (which is RDF), it also has the added benefit that we get a range of graph algorithms for free: e.g. the shortest path search, which is what you will see when you search for multiple places (example). Personally, I also found it easier to work with Neo4j rather than a triple store: the recommended Neo4j practice of defining your own domain model (and then working with concrete instances of Datasets, Places and OAC Annotations, rather than a generic model of Nodes and Edges or Resources and Properties) just felt much more straightforward, results in more concise and readable code, and (in my opinion) easily makes up for the sacrifices in terms of 'genericness' and lack of a standardized query language.

Source Code & License

As all our work, the Graph Explorer is open. We're licensing it under the GNU General Public License v3.0. You can get the source code from our GitHub repository, which also contains detailed build and deployment instructions.

P.S.: An online demo of the PELAGIOS Graph Explorer is available here. Screencasts explaining the basic usage are in this blogpost: The PELAGIOS Graph Explorer: A First Look

PELAGIOS Graph Explorer - The Live Demo

2011-08-08T10:41:00.002+01:00

Just a short post to announce the availability of a live demo installation of the PELAGIOS Graph Explorer! Feel free to play with it at

http://pelagios.dme.ait.ac.at/graph-explorer

Mind that this is our development server, so the demo may be down occasionally as we are working on it.

The PELAGIOS Graph Explorer: A First Look

2011-08-05T09:33:00.005+01:00

The PELAGIOS project blog has been a little silent recently. But certainly not because of the summer - but rather because of some busy work that has been going on behind the scenes! Today I'd like to present some results of this work: the alpha version of the PELAGIOS Graph Explorer (working title ;-)

The Graph Explorer is a visualisation tool which lets you play with the data provided by the PELAGIOS partners, and explore the relations that now exists thanks to:

the alignment of all data with the Pleiades Gazetteer
the use of a common vocabulary to express place references

I'm planning to discuss the details - the components underneath the hood, the implementation, the Graph Explorer API - in a follow-up post. And there will also be a public demo instance you can try hands-on. But for now I'd just like to keep it short - and show what the tool looks like!

The first screencast explores how datasets from different PELAGIOS partners are related to each other through place. You can also view the original-resolution video for a clearer picture.

The second screencast takes the "inverse perspective" (so to speak) - and explores how different places in the PELAGIOS data are related to each other through data. The original-resolution video is here.

Creating the Pleiades to Arachne annotation

2011-07-13T17:11:00.016+01:00

Below I describe how the Arachne Places and Topographical Units are used to annotate the Pleiades Places. The output format will be OAC RDF, as it has been agreed upon. The approach towards annotation is fully automated and preformed by a PHP script.

The Datasources:

Pleiades+:

Pleiades+ CSV file, ordered by the Pleiades ID converted form the initial excel file of Pleiades. The ordering by Pleiades ID makes the computation of alternative names easier, because there is one alternative name after another.

http://googleancientplaces.wordpress.com/pleiades/

Link to the sorted version used by the script

Arachne Database:

The Arachne Database is a Mysql database with a structure that has evolved over time. It uses the utf8_general_ci encoding. The Arachne places have place names which are more or less ordered.

http://arachne.uni-koeln.de

All places contain information about their larger entities: for every place there is the country in which it falls. The Pleiades Places are described by identifiers: therefore a country is described in the same way as a city or a village.

In Arachne, places are defined by a list of name attributes. These names contain the specific place (Aufbewahrungsort), ancient place name (Ort_antik), city name (Stadt), country name (Land), and their synonyms(Aufbewahrungsort_Synonym,Stadt_Synonym). Specific Places describe the place in the most Specific way. They are often freetext descriptions of places, addresses, directions (after 300 meters on road XY on the left side) , Museums and many other forms of Place descriptions. This field is unlikely to match one of the Pleiades labels. The annotations will therefore often describe the more general place in which an Arachne place forms a part.

For example, the place “Corso d` Italia 35 b, Rome, Italy, Europe” will refer to “Italy” and “Rome” in Pleiades the address “Corso d` Italia 35 b” is much too specific for Pleiades.

The script is focused on precision rather than recall. This means that the script will try to produce exact results rather than many results, even if there could be more "real" matches.

The five steps to annotation

1. Collecting synonyms of Pleiades places

Example:

Pleiades ID : 1094

Names:

Lopadusa Ins.

lopadusa

lampidusa

2. Query the database for all synonyms

The collected synonyms of the Pleiades+ dataset have been rewritten as SQL-queries.

The collection of labels:

Lopadusa Ins.

lopadusa

lampidusa

The resulting SQL-queries:

SELECT `PS_OrtID` From `ort` WHERE `Aufbewahrungsort` LIKE 'Lopadusa Ins.' OR `Aufbewahrungsort_Synonym` LIKE 'Lopadusa Ins.' OR `Ort_antik` LIKE 'Lopadusa Ins.' OR `Stadt` LIKE 'Lopadusa Ins.' OR `Stadt_Synonym` LIKE 'Lopadusa Ins.' OR `Land` LIKE 'Lopadusa Ins.';

SELECT `PS_OrtID` From `ort` WHERE `Aufbewahrungsort` LIKE 'lopadusa' OR `Aufbewahrungsort_Synonym` LIKE 'lopadusa' OR `Ort_antik` LIKE 'lopadusa' OR `Stadt` LIKE 'lopadusa' OR `Stadt_Synonym` LIKE 'lopadusa' OR `Land` LIKE 'lopadusa';

SELECT `PS_OrtID` From `ort` WHERE `Aufbewahrungsort` LIKE 'lampidusa' OR `Aufbewahrungsort_Synonym` LIKE 'lampidusa' OR `Ort_antik` LIKE 'lampidusa.' OR `Stadt` LIKE 'lampidusa' OR `Stadt_Synonym` LIKE 'lampidusa' OR `Land` LIKE 'lampidusa';

The SQL statements check all the fields of the Arachne database where place names are mentioned for a specific place. If one of the names in Pleiades+ matches one of the name description fields in Arachne, the key of the dataset is returned and added to the list of matching IDs of all synonyms.

The synonymous names of a Pleiades data sets are matched by the SQL "LIKE" statement. The "LIKE" comparison is case insensitive and special characters for example 'a' matches on 'ä'. For Further Information on this issue see:

http://dev.mysql.com/doc/refman/5.0/en/string-comparison-functions.html

3. Collect all results and remove duplicates

Result examples: 1001,2001,1001,3001,1001,2001,3001

After removing the duplicates: 1001,2001,3001

4. Convert Internal IDs

The internal Arachne IDs are converted to general Arachne entity IDs.

5. Convert results to OAC-RDF

The matching datasets in Pleiades and Arachne are then annotated in OAC.

The annotation URI:

A typical annotation URI produced in this workflow looks like this.

"http://arachne.uni-koeln.de/oacAnnotaion/1310384539/Pleiades991319toArachneEntity8003997"

"1310384539" represents a unix-timestamp of the date of creation.

"Pleiades991319toArachneEntity8003997" describes the annotation in a more or less human readable form.

The timestamp and the combination of IDs provide the uniqueness of the annotation URI. The fact that the URI scheme is human readable is NOT a requirement of an URI and shouldnt be expected in general!

The main goal of a URI is to be unique reference to a piece of data. In this case even if the same annotation is done another time it must not have the same URI. The annotated things are the same but the annotation itself is different. The annotation represents knowledge at a specific time. The Arachne database is still growing and corrected, so the results will change over time, even if the script that produces them remains the same.

The Annotation in RDF:

The date is also represented in the "dc:created" triple of the annotation.

<http://arachne.uni-koeln.de/oacAnnotaion/1308218223/Pleiades991319toArachneEntity8003997> dc:created "2011-06-16 11:57:03".

The name of the script is represented in the "dc:creator" triple.

<http://arachne.uni-koeln.de/oacAnnotaion/1310384539/Pleiades991319toArachneEntity8003997> dc:creator "ArachneEntityToPleiadesPlacesScriptv0.2" .

This is just a string, but when you get conflicting or wrong interpretations you can just blame a bad version of a script that has produced the results.

There is also the advantage of identifying old annotations.

A complete set of triples of an Arachne Pleiades annotation:

<http://arachne.uni-koeln.de/oacAnnotaion/1310384539/Pleiades991319toArachneEntity8003997> rdf:type oac:Annotation .
<http://arachne.uni-koeln.de/oacAnnotaion/1310384539/Pleiades991319toArachneEntity8003997> dc:created "2011-07-11 13:42:19".
<http://arachne.uni-koeln.de/oacAnnotaion/1310384539/Pleiades991319toArachneEntity8003997> dc:creator "ArachneEntityToPleiadesPlacesScriptv0.2" .
<http://arachne.uni-koeln.de/oacAnnotaion/1310384539/Pleiades991319toArachneEntity8003997> oac:hasBody <http://pleiades.stoa.org/places/991319>.
<http://arachne.uni-koeln.de/oacAnnotaion/1310384539/Pleiades991319toArachneEntity8003997> oac:hasTarget <http://arachne.uni-koeln/entity/8003997>.
<http://pleiades.stoa.org/places/991319> rdf:type rdfs:Resource .
<http://pleiades.stoa.org/places/991319> rdf:type oac:Body.

The annotation of topographical units is similar to this. But it uses a different table and different fields.

Conclusion:

The fact that a Pleiades place is most of the time more general than the Arachne Place could not be expressed in the annotation. This is a unsatisfying trade-off produced by using such general frameworks as the OAC. The information expressed in it is very unspecific.

Maybe there will be a way for the next version expressing this fact as an optional piece of information that can or cannot be used. If you want just a Link then you just ignore the other links. If you are very hungry, you can eat millions of good spaghetti as well as millions of very cheap spaghetti. But the good ones you can also enjoy, if you want to.

A web of linked data could not be typed in by hand. That would be extremely time consuming and produce different errors than letting the computer handle it. Everyone that tries to keep two long numbers in mind will mess up something every once in a while. What I'm missing is a simple controlled way to annotate machine authorship. This could help to back check results and to handle messy data. Who is to blame if the data is messy? The data-source or the automated process in the background.

Rasmus Krempel, Arachne Database, CoDArchLab University of Cologne

sorted version of pleiades+

PHP script to create annotation

Open Licenses

2011-07-07T13:38:00.000+01:00

One of the most important things for any online resource to think about is the license they will make their data available under. Naturally we're very much into the Open variety here at Pelagios (in fact our work would essentially be meaningless otherwise), but that word can mask a good degree of philosophical (and occasionally bureaucratic) diversity. Creative Commons have a done a remarkable job of trying to simplify this process but it remains a fact that when bringing different datasets together we may be faced with the need to deal with multiple licenses. Pelagios in fact uses four: CC-ZERO, CC-BY, CC-BY-SA, CC-NC-ND. There are two reasons for this, a pragmatic one and a philosophical one.

Pragmatically, we essentially have no choice when working with a sizeable (and growing) consortium. Many of the projects we are working have been established for years (occasionally decades) and although all subscribe to a policy of open content they have different needs and histories of licensing. There is simply no way for us to require that they change to a new licensing regime. Philosophically however we see this as no bad thing. Indeed, the purpose of Pelagios is not to serve up a new aggregation of content under a new license and we doubt whether such an imperative could ever be scalable in principle. Rather, we wish explore complementary ways that resource providers can make their content available that facilitate integration with third parties, but under their own license terms. Resource combinations should always be created with specific goals in mind - not simply ad hoc aggregations - that take into account the licensing requirements as well as the content.

We are aware that in some cases the desired data will not always be available under the terms and conditions one might wish but that is simply the nature of cultural content. Trying to force the issue will only make potential future partners more hesitant to collaborate. We are keen to work together with any provider with ancient data, just as long as they are truly interested in sharing what they have with the wider world.

Information about all the licenses we use is available at:
http://pelagios-project.blogspot.com/2011/03/pelagios-project-plan-part-4-ipr.html

CLAROS joins the Pelagios Project

2011-06-10T11:01:00.007+01:00

On the 17th of May 2011, CLAROS went live with a launch event at Wolfson College, Oxford. The project aims to "bring the world of ancient art onto the semantic web", and comprises the CLAROS Explorer, an image search interface, and a site which exposes the data as RDF. Data are provided by partners, who model their collections using RDF and the Erlangen OWL-DL 1.0 implementation of the CIDOC Conceptual Reference Model.

Shortly after launching we were invited to join the Pelagios consortium, and we're delighted to be on board.

What we've done so far

We're in the process of co-referencing all the places referred to by our partners. For example this ewer was found within the Ashmolean's conceptualisation of Henan province, which is (eventually) contained within a 'centralised' concept of China.

This allows us to find fifty things from Greece, Buddha-related objects from Thailand, and lots of places we believe are within Greece.

We've created a dump of our data should anyone else want to play with it. At some point soon we'll change the names of the graphs in the triplestore to match these, so that the graphs are also dereferenceable. In the interests of trend-setting, we've also got a semantic pingback server running on the off-chance that there are similarly-minded people out there.

What next

We need to keep co-referencing our places. We've done a lot of the low-hanging fruit (those that are mentioned a lot and/or are easily found), but from here on in it's the law of diminishing returns. So far we're linking against Pleiades and Geonames where we can, and using the CRM's "falls within" property to create a hierarchy of containment.

We've also discovered a few instances of places in the source data we don't know how to model. For example, "between Kermanshah and Dezful"; look these places up on a map and you discover they're 352km apart by road, so taking a colinear equidistant point isn't very helpful. As well as 'betweenness', we can't do uncertainty (e.g. "Athens (?)"), or proximity (e.g. "near Athens").

I still need to get my head around OAC and how that relates to what we're doing. At the moment we're using skos:closeMatch and skos:exactMatch to link our places to their Geonames and Pleiades counterparts. I had thought about using property reification vocabulary (PRV) to create something to attach provenance information to, but it's possible that this could all be handled within OAC. Suggestions welcome (and probably much needed!).

Nomisma.org Annotations

2011-05-25T17:38:00.000+01:00

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.

The Other 15/10 Geo Projects

2011-05-14T10:31:00.003+01:00

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

Tagging Places on Old Maps: The DME Scenario

2011-04-15T12:24:00.012+01:00

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!)

To ASCII or not to ASCII

2011-04-13T11:36:00.002+01:00

So, you've got your locations all beautifully geoparsed, but how is anyone going to search for Liévin, let alone Łódź or Uherské Hradiště?

In the old days of the web, this wasn't a problem. They couldn't. At least, not without a huge amount of learning and expense on everyone's part. In the English-speaking world, text on the web meant ASCII. This restricted you, basically, to the characters on a standard US keyboard: 128 characters, a third of which were things like 'tab' and 'line feed'. If you wanted your readers to read 'é', you sent them a something called an entity (é in this case). If you wanted your readers to read 'Ł', you might even have to send them a little image of the letter.

This was stupid, obviously. And, thank god, we now have browsers, databases, and programming languages that speak a different text 'language': UTF-8 (Unicode). This gives us millions and millions of characters, and means that if you want people to read 'š', or even 'אַ', you can send them plain text and not have to worry too much about operating systems, browser support, or reproducing 2000 .gif files whenever you change your site design (been there, done that, please don't judge if you haven't supported Internet Explorer 4).

But this only solves half of the problem: reading, but not writing. If you have to type 'Ł', and you're using a standard US/UK keyboard, we haven't come very far. The existing methods are either clumsy, slow, or require a lot of memorisation (or all three). It's all very well expecting admins to take a bit of extra time to enter the correct name - although a little bit of AJAX and GeoNames means that they don't have to. But, as this rather forthright blog points out, is it realistic to expect this from our users?

To give you an example of how this applies to the Pleiades data, take the case of Mérida, in Spain. Mérida (Roman Emerita Augusta, Pleiades 256155, GeoNames 2513917) is quite an important location for the APGRD (Archive of Performances of Greek and Roman Drama), as its wonderfully preserved Roman theatre is the venue for many new versions of classical plays - last year's Lysistrata, for example (warning, very slightly NSFW!).

Because the APGRD has no time frame - we're interested in every single performance, from antiquity onwards - many of our users won't know that Mérida used to be Emerita Augusta, so I can't rely on them searching for that. However, a search on the Pleiades dataset for Merida (no accent) returns no results because for the computer, 'Merida' and 'Mérida' are two different values.

I imagine those of a non-English-speaking background will be tempted to say "so what, we've been typing non-ASCII characters all our lives - you do know our keyboards look different, don't you?". Likewise, those who've spent the effort learning the betacode or combining unicode commands to get the best out of TLG and Perseus may be less forgiving.

However, I must admit that my own sympathies lean somewhat toward the author of that post. My own experience, and what I've learned from geoparsing our database's locations (entered over 10 years by a variety of people) is that:

people don't necessarily know that a location has non-ASCII characters, or what the right ones are (pop quiz, no googling: how do you (properly) spell Liege?). They'll get no results and not realise that they've entered the wrong search string.
a substantial proportion of people, even academics, have no idea how to enter non-ASCII characters - and even those that can are generally only good at doing it in languages/ character sets with which they are familiar.
of these, how many are going to cut-and-paste text from elsewhere (which does not always give you the characters you want)?

So, I'm sure of the problem, but not necessarily of the solution. It seems to me that the best way to do this might be to convert all search strings to ASCII before matching them against ASCII-ised locations (at least, for user search). But does this lead to a horrible loss of precision? Are there better ways?

And I have it easy - all my locations are at least in the Latin alphabet!

A new comer to Pelagios: the Ptolemy Machine

2011-04-05T11:59:00.009+01:00

In our extant literature from the Greco-Roman world, Claudius Ptolemy's Geography is a unique treatise on mathematical cartography. Its relevance for Pelagios is in part that it includes the largest scientific data set to survive from antiquity: more than 6000 named points are located with longitude-latitude coordinates in books 2-7, and more than 350 key cities are again located in an alternate astronomical coordinate system in book 8. The text of book 1 provides a systematic introduction, including two methods for drawing world maps. Books 7 and 8 include instructions for other kinds of visualizations.

With its combination of methods and data, Ptolemy's text is a kind of software for GIS. Ptolemy includes specific suggestions about how to realize his plan in hardware: he goes beyond the mathematical theory to discuss machinery and physical procedures for constructing maps. Scribes manually copying the text of the Geography applied these procedures directly to create maps in their manuscripts, but print editions have obscured the nature of Ptolemy's project as a dynamic (if not rapid) GIS.

To understand Ptolemy's work today, his software should be implemented in software. I have recently completed an initial digital edition of the Geography that is currently accessible via the Canonical Text Services protocol from http://ptolemymachine.appspot.com. From this edition, I can automatically extract all the named points with their lon-lat coordinates and several other attributes that Ptolemy assigns them in his text (e.g., type of feature, political unit, larger physical aggregate it belongs to...), and can serialize this information in a variety of formats for use in a GIS, including KML for direct use in Google Earth or Google Maps. (Above, Ptolemy's points in Google Earth colored by Roman province or foreign "satrapy.")

I am currently applying a variety of automated tests to the source text. In addition to traditional Greek "spell checking," I am analyzing Ptolemy's data for the spatial consistency of his attributes. (When all but one of the points assigned to a given Roman province fall uniquely within the convex hull of that group, but one point falls within the cluster of a different province, the most probable cause is a textual error. I'll blog a couple of telling examples in a later post.)

During the period of the Pelagios project, I'm planning to complement the text-view of the Geography at ptolemymachine.appspot.com with a GIS view of Ptolemy's text exposed through one or more network services. (I am still experimenting with a variety of options; I'm a newcomer to Google's Fusion Tables, but am impressed with their easy access to people who want to mash up geographic features, in the spirit of Pelagios.) I'm looking foward to seeing what others might do with this material.

Neel Smith

College of the Holy Cross

Worcester, MA

Pelagios Workshop SPARQL Demo & RDFa

2011-03-23T14:45:00.001Z

Note: The following post is heavily based on notes by Mathieu D’Aquin andSebastian Heath.

Prior to the workshop we have made a test SPARQL endpoint available foranyone who wants to test our approach and see what might be possible. TheDemonstrator was built by Mathieu D’Aquin based on our weekly Skype meetingsand discussion list (which you can follow at our Google Group). The endpoint isavailable at:

http://kmi-web01.open.ac.uk:8080/openrdf-workbench/repositories/pelagiosTest/query
using theOWLIM triple store with a Sesame interface.

Testwith DME data
We haveloaded the store with test data from the OAC descriptions available at: http://dme.ait.ac.at/yuma-server/timeline

Forexample, http://dme.ait.ac.at/yuma-server/api/annotation/369 is described with thefollowing triples (see http://kmi-web01.open.ac.uk:8080/openrdf-workbench/repositories/pelagiosTest/explore?resource=%3Chttp://dme.ait.ac.at/yuma-server/api/annotation/369%3E)

<http://dme.ait.ac.at/yuma-server/api/annotation/369>     rdf:type   dfs:Resource
<http://dme.ait.ac.at/yuma-server/api/annotation/369>     rdf:type       oac:Annotation
<http://dme.ait.ac.at/yuma-server/api/annotation/369>     dc:title       "Algier"
<http://dme.ait.ac.at/yuma-server/api/annotation/369>     j.1:created    "2011-03-17 15:14:17.899"
<http://dme.ait.ac.at/yuma-server/api/annotation/369>     j.1:modified   "2011-03-1715:14:17.899"
<http://dme.ait.ac.at/yuma-server/api/annotation/369>     dc:creator     "guest"
<http://dme.ait.ac.at/yuma-server/api/annotation/369>     oac:hasBody            <http://dme.ait.ac.at/yuma-server/api/annotation/369#body>
<http://dme.ait.ac.at/yuma-server/api/annotation/369>     oac:hasTarget  _:node341

_:node341            rdf:type            rdfs:Resource
_:node341            rdf:type            oac:ConstrainedTarget
_:node341            oac:constrainedBy   _:node342
_:node341            oac:constrains      "http://dme.ait.ac.at/samples/maps/oenb/AC04248667.tif"

<http://dme.ait.ac.at/yuma-server/api/annotation/369#body>   rdf:type   rdfs:Resource
<http://dme.ait.ac.at/yuma-server/api/annotation/369#body>   rdf:type   oac:Body
<http://dme.ait.ac.at/yuma-server/api/annotation/369#body>   rdfs:label "Control Point for'Algier' (36.752887, 3.042048)"

Examplequeries:
selectdistinct ?x where {
   ?x a oac:Annotation
}

gives the list of available annotations. (see http://kmi-web01.open.ac.uk:8080/openrdf-workbench/repositories/pelagiosTest/query?queryLn=SPARQL&query=PREFIX%20oac:%3Chttp://www.openannotation.org/ns/%3E%0A%0Aselect%20distinct%20%3Fx%20where%20{%3Fx%20a%20oac:Annotation}&limit=0&infer=true)

selectdistinct ?lab where {
    ?xa oac:Annotation.
    ?xoac:hasBody ?b.
    ?brdfs:label ?lab.
    ?xoac:hasTarget ?t.
    ?toac:constrains "http://dme.ait.ac.at/samples/maps/oenb/AC04248667.tif"

}

gives thelist of texts associated to the document http://dme.ait.ac.at/samples/maps/oenb/AC04248667.tif

AddedPleiades links:
A simpleassociation based on similarity was applied to detect when the annotationrelated to a place known to Pleiades. For each of such annotations (e.g., http://dme.ait.ac.at/yuma-server/api/annotation/366 about “Corsica”,which is http://pleiades.stoa.org/places/991339), triples similar tothe following were added:

<http://dme.ait.ac.at/yuma-server/api/annotation/366> oac:hasBody <http://pleiades.stoa.org/places/991339>
<http://pleiades.stoa.org/places/991339> rdf:typewgs84_pos:SpatialThing

Smallextension of the Ontology:
A new classwas created called GeoAnnotation. Intuitively, this class represent theoac:Annnotation(s) that point to (oac:hasBody) geographical objects(wgs84_pos:SpatialThing).
It istherefore defined in abstract OWL syntax as

class(GeoAnnotation partial oac:Annotation)
class(GeoAnnotation complete restriction(oac:hasBodysomeValuesFrom(wgs84_pos:SpatialThing))

In otherwords, GeoAnnotation is the class of annotations that have a body which is aSpatialThing. In triple form:

<http://pelagios-project.org/ontology/oac-geo/GeoAnnotation>  rdf:type   owl:Class
<http://pelagios-project.org/ontology/oac-geo/GeoAnnotation>  rdfs:subClassOf oac:Annotation
<http://pelagios-project.org/ontology/oac-geo/GeoAnnotation>  owl:equivalentClass _:node417
_:node417            rdf:type               owl:Restriction
_:node417            owl:onProperty   oac:hasBody
_:node417            owl:someValuesFrom       wgs84_pos:SpatialThing

Based onthis definition, the system is able to infer that the annotations that havebeen connected to Pleiades objects are GeoAnnotation. The query:

selectdistinct ?x where {
?xa <http://pelagios-project.org/ontology/oac-geo/GeoAnnotation>

}
gives thecorresponding results (see http://kmi-web01.open.ac.uk:8080/openrdf-workbench/repositories/pelagiosTest/query?queryLn=SPARQL&query=select%20distinct%20%3Fx%20where%20{%3Fx%20a%20%3Chttp://pelagios-project.org/ontology/oac-geo/GeoAnnotation%3E}&limit=100&infer=true )

The query:
selectdistinct ?d ?b ?l where {
  ?xa <http://pelagios-project.org/ontology/oac-geo/GeoAnnotation>.
  ?xoac:hasBody ?b.
  ?xoac:hasTarget ?t.
  ?toac:constrains ?d.
  ?ba wgs84_pos:SpatialThing.
  ?brdfs:label ?l

}
gives thelist of relationships between documents and Pleiades places (see http://kmi-web01.open.ac.uk:8080/openrdf-workbench/repositories/pelagiosTest/query?queryLn=SPARQL&query=PREFIX%20oac:%3Chttp://www.openannotation.org/ns/%3E%0APREFIX%20wgs84_pos:%3Chttp://www.w3.org/2003/01/geo/wgs84_pos%23%3E%0APREFIX%20rdfs:%3Chttp://www.w3.org/2000/01/rdf-schema%23%3E%0A%0Aselect%20distinct%20%3Fd%20%3Fb%20%3Fl%20where%20{%3Fx%20a%20%3Chttp://pelagios-project.org/ontology/oac-geo/GeoAnnotation%3E.%0A%3Fx%20oac:hasBody%20%3Fb.%20%3Fx%20oac:hasTarget%20%3Ft.%20%3Ft%20oac:constrains%20%3Fd.%20%3Fb%20a%20wgs84_pos:SpatialThing.%20%3Fb%20rdfs:label%20%3Fl}%0A&limit=100&infer=true )

Testwith Arachne Data

Using thefollowing query:
http://arachne.uni-koeln.de:8080/solr/select?indent=on&version=2.2&q=*:*&fq=kategorie:topographie&start=0&rows=10000&fl=+Pfad,+id,+kurzbeschreibung,+antikeRoemProvinzTopographie,+ort,+Genauigkeit+Ort_antik,+antikeGriechLandschaftTopographie,+Geonamesid&qt=standard&wt=json&explainOther=&hl.fl=
we canobtain a list of potential annotations from Arachne, with information aboutimages relating to places, that can have modern and ancient names.

There are(apparently) a bit more than 5000 items in this list, running the samesimilarity-based process as above, we could relate a bit more than 2000 of themto Pleiades URIs.

They allappear, with the previous queries, as Annotations and GeoAnnotation. With thisdataset, there are now many documents refering to the same place. We can forexample obtain the list of documents referring to “” with the query:

selectdistinct ?x where {

?y oac:hasBody <> .

?y oac:hasTarget ?x

}

Forexample, the place “Hispania” (http://pleiades.stoa.org/places/1027) is the body of 1 DME(geo)annotation and 4 Arachne (geo)annotations (see http://kmi-web01.open.ac.uk:8080/openrdf-workbench/repositories/pelagiosTest/explore?resource=%3Chttp%3A%2F%2Fpleiades.stoa.org%2Fplaces%2F1027%3E.

The list of all the (geo)annotationsrelating to it can be retrieved through the query:

PREFIXoac:<http://www.openannotation.org/ns/>
select?x where {
?xa <http://pelagios-project.org/ontology/oac-geo/GeoAnnotation>.
?xoac:hasBody <http://pleiades.stoa.org/places/1027>
}
http://kmi-web01.open.ac.uk:8080/openrdf-workbench/repositories/pelagiosTest/query?queryLn=SPARQL&query=PREFIX%20oac%3A%3Chttp%3A%2F%2Fwww.openannotation.org%2Fns%2F%3E%0A%0Aselect%20%3Fx%20where%20{%0A%20%20%20%3Fx%20a%20%3Chttp%3A%2F%2Fpelagios-project.org%2Fontology%2Foac-geo%2FGeoAnnotation%3E.%0A%20%20%20%3Fx%20oac%3AhasBody%20%3Chttp%3A%2F%2Fpleiades.stoa.org%2Fplaces%2F1027%3E%0A}%0A%0A%20&limit=100&infer=true

Otherpossible extensions
There aredifferent kinds of GeoAnnotation (and different types of documents considered).For example, some data would mention both documents about the location, anddocuments that cite the location, but are about something else. Maps ofparticular locations might have a specific status, as well. We could addsub-properties of oac:hasTarget for example or subclasses of GeoAnnotation.

Using html link element to indicatepresence of Pelagios ingestible RDF

In additionMathieu’s work, Sebastian Heath has been considering implmentations in RDFa. Itis common to use the html element ‘link’ within an html ‘head’ to indicate thelocation of alternate versions of web resource. The most common application ofthis convention is to indicate the presence of Atom or RSS feeds.

E.g. <linkrel="alternate" type="application/atom+xml"title="Atom feed" href="<URI Here>" />

Resourceauthors/publishers can use the following convention to indicate the location ofRDF-serialized Pelagios-compatible oac:Annotations.

The @rel MUST be equal to "x-pelagios-oac-serialization".
The @type SHOULD match the mime type of the resource pointed to by @href.
The @type SHOULD be one of:

text/turtle
application/rdf+xml
text/rdf+n3 http://www.w3.org/DesignIssues/Notation3
text/plain http://www.w3.org/2001/sw/RDFCore/ntriples/ (if correct, this is annoying)
application/xhtml+xml (for RDFa)
text/html (for RDFa. Because we should be robust and not assume that all servers are correctly configured.)

The value of the title attribute is not significant. Authors MUST NOT use it to communicate any information to the Pelagios crawler.

ThePelagios Crawler (TM) will recognize the presence of the link @rel combinationand expect to find Pelagios-compatible annotations at the referenced URI.http://kmi-web01.open.ac.uk:8080/openrdf-workbench/repositories/pelagiosTest/query?queryLn=SPARQL&query=PREFIX%20oac:%3Chttp://www.openannotation.org/ns/%3E%0A%0Aselect%20distinct%20%3Fx%20where%20{%3Fx%20a%20oac:Annotation}&limit=0&infer=true

Pelagios Project Plan Part 7: Budget

2011-03-14T16:19:00.003Z

Budget forecast*

Total Staffing costs 59%
Partner collaboration activities (incl. the workshop) 16%
Overheads (Estates and Indirects) 27%

*This is the total budget, including contributions In Kind from partners (see below)

Budget Management

The Arts Faculty Research Grants Manager is Suzanne Duncanson-Hunter. She is working closely with both the PI and CoI to make sure that the project keeps to budget. The PI and CoI are also in close correspondence with the JISC manager over how best to manage costs and utilise resources. In addition, the Open University, through Suzanne's efforts, have already drawn up an external consultancy contract with Rainer Simon of DME for work to be undertaken on Pelagios in WP3.

Budget Justification

The ontology work undertaken by LUCERO in WP1 complements the funding that they already have from JISC. Furthermore, all work on ontology specification, mapping and alignment done by the data and documentation partners (GAP, Perseus, DME, SPQR, Arachne) and Pleiades is payment In Kind. Because all of our partners are already committed to linked open data research and have secured sustainable and significant funding for themselves, Pelagios is able to make substantial research and infrastructural advances on a relatively modest budget, thus greatly maximizing Return On Investment for both JISC and project partners.

This is encapsulated by our 'start-up' event, the one-day workshop at KCL, which presents a unique opportunity for an intensive exchange of knowledge and experience on Linked Open GeoData from the community at large, as well as from all of our partners. For this reason we are intending to record the proceedings to help document the discussion of issues and methods relating to linking open data ontologies, so that it may be of use for other groups working in this area in the future. Our budget ensures that all invited external expert speakers will have UK costs borne, while also paying for the time and expenses of all the Pelagios partners, for both their participation at the workshop and the project meeting on the following day.

Choosing an ontology: OAC

2011-03-12T12:07:00.000Z

Part of Pelagios' first Workpackage is to decide on a Common Ontology for Place References (COPR). In doing so we are not attempting to reinvent the wheel - far from it. Good Linked Open Data practice is to reduce, reuse and recycle. To that end we have been investigating a variety of options and are now basing our approach on the Open Annotation Collaboration ontology.

The OAC is also a work in progress but, as luck would have it, they are holding their workshop in Chicago on exactly the same dates as ours (we now have a great line-up, btw, so register soon as places are filling up). Their fundamental principles seem to be exactly what we are looking for though: the ability to connect a target web document with some information about it (in our case, an ancient place).

The basics should look something like this:

ex:ann1 oac:Annotation
oac:hasBody "http://pleiades.stoa.org/places/423025"
oac:hasTarget <some resource identifying the text + fragment>

But a number of interesting issues remain - should we use Blank Nodes for the annotations themselves (especially in RDFa)? If not, where do we store them? Should we subclass the OAC ontology to specify that it is a geographic annotation? If so should it be the oac:Annotation or oac:hasBody that we subclass, and where should that ontology be hosted? We are fortunate to have the assistance of Bernhard Haslhofer and Robert Sanderson in this discussion, who are both involved with OAC and look forward to them reporting back from OAC's workshop. In the meantime Mathieu D'Aquin is putting together our own SPARQL demonstrator to see how useful this approach may be in practice.

If you have any thoughts on this do let us know and you can follow the discussion itself over on our Google Group.

Pelagios Project Plan Part 6: Projected Timeline, Workplan & Overall Project Methodology

2011-03-10T13:11:00.005Z

Project plan

Pelagios is divided into three work packages (WP), centred on the three stated outputs of the project: core ontology development; application of that ontology to the project partners’ sample datasets, and documentation of the process; and development of web resources to trial and show the value of the ontology for users.

WP1 Ontology Specification - LUCERO, Southampton ACRG, Pleiades

WP1 has three key elements:

1. First, to develop a core ontology for (ancient) place references (COPR) with help from the partners. This involves:

· Gathering from the project partners sample dataset ontologies that describe references to places in their documents, identifying common elements, and evaluating their robustness

· Constructing a core ontology that can be applicable for all the different datasets represented by the partners (text, database, map), and then testing its implementation with a SPARQL demonstrator

2. Second, to hold a two-day workshop on developing a core ontology for linking open geodata. This involves:

· Disseminating around the project partners and workshop invitees the proposed ontology as well as abstracts from all the speakers

· Hosting a one-day workshop that is open to all members of the community* with three sessions dedicated to: 1) Issues of referencing ancient and contemporary places online; 2) Lightweight ontology approaches; 3) Methods for generating, publishing and consuming compliant data. Each session will consist of several short (15 min) papers followed by half an hour of open discussion.

· Hosting a project meeting on the day following the workshop, which will be devoted to incorporating feedback from the community and then deciding upon the core pelagios ontology that will be used by each of the project partners

3. Lastly, to publish the COPR in RDF (hosted by Pleiades)

*For more information about the community workshop, including registration details, please visit: http://pelagios.eventbrite.com/

WP2 Documentation of Uniform Resource Identifiers (URI) Mapping and RDF publication - GAP, Perseus, SPQR, Arachne, DME

WP2 is divided into 5 parallel streams (A-E) according to the different document types hosted by each of the partners. Each stream will:

i) Detail the process by which local place references are aligned with Pleiades URIs and COPR-compliant RDF is generated and hosted

ii) Make recommendations for document-type extensions to COPR

· Stream A: GAP will document processes related to narrative free texts

· Stream B: Perseus will document processes related to XML-encoded freetext (In Kind)

· Stream C: SPQR will document processes related to fragmentary free texts

· Stream D: Arachne will document processes related to database records

· Stream E: DME will document processes related to rasterized maps

WP3 Development of Web services and tools to facilitate consumption - DME

This last WP trials and develops the various web-applications to which the ontology may be put. This includes:

· Developing a Representational State Transfer (REST) webservice to output COPR-compliant RDF in alternative output formats, e.g. Keyhole Markup Language (KML), GeoJSON

· Developing a suite of three web visualization tools: a map view, a table view, and an ‘ordered’ view (for chronological or narrative timelines)

· Incorporating further feedback from each partners’ user groups in order to permit agile development of the ontology webresources

The Pelagios GANTT chart (01 February 2011 – 31 October 2011)

Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct
WP1	WP1	WP1	WP2	WP2	WP2	WP2	WP2
	w/shop				WP3	WP3	WP3	WP3

Project Management

Most project meetings take place via skype:

· A monthly meeting comprising of the PI, Co-I and one representative from each of the partners is established for checking progress, identifying and resolving common issues, planning for the forthcoming month’s activities, ensuring aims are met, and disseminating the project outcomes.

· In the run-up to the workshop, a smaller group comprising of the PI, Co-I one representative from the development partners meet to discuss the ontology development.

· The PI and Co-I meet once a month with their JISC PM, David Flanders, to ensure that the project is on target.

The project uses a google group email for more regular, bi-weekly communication:

· This email group keeps partners informed of deadlines and to-dos.

· It also hosts discussion of work flows, issues and methodologies. All communication is archived for the benefit of the broader community.

In addition, the PI and Co-I will make one visit to each partner during the ontology application process. Rapid-iteration Agile methods will be used for software development.

Pelagios workshop on Linking Open (geo)Data

2011-03-09T13:43:00.005Z

The Pelagios project is hosting a workshop on Linking Open GeoData in the Humanities on Thursday 24 March at KCL. The event is free of charge, but, if you would like to attend, please sign up at http://pelagios.eventbrite.com/

Further details:

The Pelagios workshop is an open forum for discussing the issues associated with and the infrastructure required for developing methods of linking open data (LOD), specifically geodata. There will be a specific emphasis on places in the ancient world, but the practices discussed should be equally applicable to contemporary named locations. The Pelagios project will also make available a proposal for a lightweight methodology prior to the event in order to focus discussion and elicit critique.

The one-day event will have 3 sessions dedicated to:

1) Issues of referencing ancient and contemporary places online

2) Lightweight ontology approaches

3) Methods for generating, publishing and consuming compliant data

Each session will consist of several short (15 min) papers followed by half an hour of open discussion. The event is FREE to all but places are LIMITED so participants are advised to register early. This is likely to be of interest to anyone working with digital humanities resources with a geospatial component.

Preliminary Timetable

10:30-1:00 Session 1: Issues

2:00-3:30 Session 2: Ontology

4:00-5:30 Session 3: Methods

Confirmed Speakers (including affiliation and relevant project)

Johan Alhlfeldt (University of Lund) Regnum Francorum online

Ceri Binding (University of Glamorgan) Semantic Technologies Enhancing Links and Linked data for Archaeological Resources

Gianluca Correndo (University of Southampton) EnAKTing

Claire Grover (University of Edinburgh) Edinburgh Geoparser

Adam Rabinowitz (University of Texas at Austin) GeoDia

Sebastian Rahtz (University of Oxford) CLAROS

Sven Schade (European Commission)

Humphrey Southall (University of Portsmouth) Great Britain Historical Geographical Information System

Pelagios on Big Data

2011-03-08T12:28:00.005Z

Recently JISC commissioned a reporter to go to the O'Reily Strata (Big Data) Conference in California. The report, which can be accessed here, throws up a number of interesting questions that are pertinent to our own project. We sketch out some initial responses here—but we’d welcome further comments from within the team or from any of our readers.

Given the opening questions asked about Big Data—What information is out there? How can we find it? And how can it be accessed?—it is perhaps no surprise to find that the Pelagios team is sympathetic to much of the discussion. From a brief reading of this document, three things strike us as being of particular relevance:

1. Open access. The concluding point, ‘if data is less open, it is less useful—limiting access limits value’, is one with which we are in total accord. The importance of data being open is particularly acute in an academic environment, where cutting edge research depends fundamentally on the ability to access datasets of all different kinds. If somewhat more geared towards a science model of research, nevertheless open access could transform (in a positive way) the Humanities, making it incumbent on the researcher to show his/her working out: just what is the evidence for this or that interpretation, and so on. But access is not the only issue; data must also be reusable—which presents its own range of technological and intellectual challenges. Furthermore, care must be given if we are to avoid a tyranny of openness, by virtue of which research that (for whatever reason) is less open (whatever that might mean) is passed over or fails to gain funding or prestige. Or, to put that differently, does the mere fact that something is open make it worthwhile research?

2. Infrastructure. This issue seemed to be the keynote of the blog. It is raised by (among others) Mike Olson (Cloudera), Rod Smith (IBM) and Abhishek Metha (Tresata); and by Steve Midgley (U.S. Department for Education). How do we find and identify valuable resources? And how can it be connected up? Just such an issue has been the concern too at the European Science Foundation (http://www.esf.org/research-areas/humanities/strategic-activities/research-infrastructures-in-the-humanities.html)—the practice to be guarded against being termed ‘data silos’. But, given the importance of ‘infrastructure to store and share data within sectors’, how can it be achieved? Various ‘top-down’ approaches (whether commercial or educational) have thus far fallen flat either because of insufficient user uptake or the lack of reusability of the data, tools, etc. Accordingly, Pelagios supports a ‘bottom-up’ Linked Data approach, by which a variety of user groups work together to connect their resources in an open and transparent way, which others can assess and to which they may add their own. We certainly support the idea that resources should be shared wherever possible and that research (particularly in the Humanities) needs to move beyond a narrow competitive mentality.

3. Users. This is something touched upon in our previous response and that is implied in much of the blog—but whose fundamental importance is not really addressed. Focus seems to be rather on the producers and how they can provide context for the data or an expert ability to disseminate knowledge and understanding. But what about the user-end of the communication (something which Humanities teaches us to pay attention to)? Who are the users? Why do they use some Big Data and not others? And how can they be empowered to bring together for themselves different kinds of information? This is the critical challenge facing anyone working in the digital medium. In a commercial context it is clear that there is increasing demand for ‘Data Scientists’ capable of making sense of it all. Arguably that has always been the role of academics, yet few of us have the requisite technical skills and domain knowledge demanded by these new resources. Pelagios is a consortium project for this very reason and we suspect that multidisciplinary research groups will, almost of necessity, be the organizational structure best suited to exploiting academic Big Data.

Pelagios Project Plan Part 5: Project Team Relationships and End User Engagement

2011-03-08T10:47:00.012Z

Pelagios is made up of an international consortium of projects leading digital research on the ancient world, the more established of which already have large user communities: in short, these groups are the end users of the Pelagios project. Each partner has at least one prominent member on the Pelagios working group to represent them. So, welcome to the team:

Elton Barker (GAP, The Open University) Principal Investigator

Elton is the non techie on the project: he’s a lecturer in Classical Studies at the OU with a specialism in all things Greek (Homer, tragedy, historiography...). But he’s slowly slipping into the murky world of Digital Humanities having been Principal Investigator of HESTIA - a project investigating spatial concepts in Herodotus - and now GAP. (He’s also assisting in the promotion and understanding of DH at the OU.) Elton is in overall charge of all things Pelagios related, like overseeing progress of the work packages and making sure that the team delivers on what it promised: in other words, it's his neck on the JISC chopping-block if things go pear-shaped - not that he's worried. He’s also responsible for GAP’s contribution to project documentation (meaning that he’ll try to put the techie talk into plain English).

Leif Isaksen (GAP, Southampton) Co-Investigator

Leif, a strange hybrid - part philosopher, part classicist, part archaeologist, and total computer geek - is a Research Fellow at the Archaeological Computing Research Group (Southampton). Having been the technical consultant on HESTIA, Leif has moved on to be Co-I for both GAP and Pelagios. Leif is the go-to man for all the technical components of the project, working in conjunction with Development Partners to ensure infrastructural outputs are delivered. He’s also responsible for GAP’s data contribution to the project (i.e. the techie stuff).

Tom Elliott, Sean Gillies and Sebastian Heath (Institute for the study of the Ancient World) Development Partners

Tom is managing editor of Pleiades, an innovative ancient world online atlas, which was established with a grant from the U.S. National Endowment for the Humanities and which he has since developed as Associate Director for Digital Programs in the Institute for the Study of the Ancient World at New York University.
Sean Gillies is Pleiades’ chief engineer and representative in open source web and GIS initiatives. Together, he and Tom will provide support and expertise in mapping ancient place references to Pleiades’ uniform resource identifiers for each location (so called URIs). As part of this task they are helping to develop the core ontology by which different projects can point their place reference data to the Pleiades URIs.

Sebastian Heath is a Ceramics specialist with expertise in Linked Data and also responsible for nomisma.org.

Mathieu d’Aquin (LUCERO, The Open University) Dev Partner

Mathieu is a researcher at the OU’s Knowledge Media Institute and project director of the JISC-funded LUCERO project, which is exploring the means of integrating Linked Data practices for research and education in higher-educational organizations. As our ontology guru, Mathieu is looking to inject some Linked Data goodness into our project: he’s responsible for implementing the core semantic infrastructure, and will assist all the partners in its delivery and documentation.

Rainer Simon (DME, Austrian Institute of Technology) Dev Partner

Rainer is presently involved in the EuropeanaConnect project, where he leads research and development activities concerned with semantic media annotation, including the development of demonstrators for annotating and linking digitised maps and geospatial content. Rainer, then, has the coolest job of us all - to come up with funky ways of experimenting with and visualizing what Pelagios can do for you. He’s also responsible for DME’s data and documentation contributions to the project.

Greg Crane (Perseus, Tufts) Data + Doc Partner

Greg is Editor-in-Chief of the Perseus project, a trail-blazer in the world of Digital Humanities for its programme of digitizing classical texts - it currently hosts the world’s largest classical online library - with a particular focus on organising the data to meet user needs. Among supporters of Perseus are: the Annenberg/CPB Projects; the Digital Library Initiative Phase 2; the National Endowment for the Humanities and the National Science Foundation; the Institute for Museum and Library Services; the Mellon Foundation; and Google. Overseeing this vast digitised Classical empire, Greg is responsible for Perseus’ data and documentation contributions to the project.

Reinhard Foertsch (Arachne, Cologne) Data + Doc Partner
Reinhard is director of the CoDArchLab (computing archaeology) at Cologne University and leads the Arachne project, the central object-database of the German Archaeological Institute (DAI), which has over 6,000 registered users and approximately 981,000 scanned images and documentation for roughly 270,000 sites accessible free of charge and, helpfully, in English. Arachne is a partner of CLAROSnet and has recently won, like GAP and Perseus, a Google Digital Humanities Research Award. Reinhard is responsible for Arachne’s data and documentation contributions to the project.

Mark Hedges (SPQR, KCL) Data + Doc Partner

Mark is Deputy Director of the Centre for e-Research at KCL and Director of SPQR, which is not a project about the famous phrase describing the constituent part of the Roman Republic (Senatus Populusque Romanus) but rather one that adopts Semantic Web and Linked Data approaches to allow researchers to formalise resources and the links between them more flexibly. Mark is responsible for SPQR’s data and documentation contributions to the project.

Neel Smith (Ptolemy, Holy Cross) Data + Doc Partner

Neel is Associate Professor of Classics at the College of the Holy Cross (Worcester, Mass.), an architect of the Homer Multitext project, a principal designer of the Center for Hellenic Studies' CITE architecture, and is editing a geographically-aware digital edition of Ptolemy's Geography. He has been involved in digital scholarship since the early 1980s and still uses ed for quick edits.

Sebastian Rahtz (CLAROS, Oxford) Data + Doc Partner
Sebastian is the head of the Information and Support Group of Oxford University Computing Services. In this capacity he provides the technical support and development for CLAROS. He also directs the Lexicon of Greek Personal Names and works on and for the Text Encoding Initiative.

Other key project members are:

Andreas Geissler & Karin Hoehne (Arachne), Tobias Blanke + Gabriel Bodard (SPQR), Kate Byrne + Eric Kansa (GAP), Alex Dutton (CLAROS)

End-User Engagement
Pelagios has received feedback from a range of national and international organisations and initiatives including Google, EDINA, ADS, STELLAR, EnAKTing, UKLP, GeoNames, GeoDia, the European Commission, Open Context, Orbis, Regnum Francorum Online, Digital Atlas of Roman and Medieval Civilizations (Harvard) and Open Encyclopaedia of Classical Sites (Princeton). Many of these groups will be participating in the Pelagios workshop at KCL on 24 March. This event is open to ALL. Anyone wishing to attend should contact Elton at e.t.e.barker@open.ac.uk.

In addition to this blog, we are also archiving all group email discussions under pelagios-project@googlegroups.com. At the end of the project (October 2011) we will wrap up with a Web-launch of the ontology, tools and services to maximise impact.

Pelagios has consulted closely with JISC in finalizing the plan, budget and website and will also interact with, and solicit feedback from, the JISC Geospatial Working Group.

Pelagios Project Plan Part 4: IPR (Licensing for Content, Source Code and Data)

2011-03-01T12:54:00.003Z

Update 8 July 2011:

GAP now makes its place reference metadata available under a CC ZERO license:

http://googleancientplaces.wordpress.com/public-domain/

-----------------------

Pelagios will make its outputs publicly available under the following open licenses:

* The ontology will be put in the public domain under a CC 1.0 BY license (http://creativecommons.org/licenses/by/1.0/) and hosted by the Pleiades Project

* Web services, tools and code will be made available under the European Union Public Licence - EUPL v.1.1 (http://ec.europa.eu/idabc/eupl) by DME

* Perseus’ contribution to Pelagios is entirely self-funded and therefore its IPR remains its own released under CC BY-SA (http://creativecommons.org/licenses/by-sa/3.0/us/); it grants the right for its contributions in Work Packages 1, 2 and 3 to be published (non-exclusively) as part of the Pelagios project output

* GAP will publish Google Books’ place reference metadata that it generates (not including Google’s source metadata) under a CC BY licence (http://creativecommons.org/licenses/by/1.0/)

* Arachne publishes its datasets under a CC BY-NC-ND license (http://creativecommons.org/licenses/by-nc-nd/3.0/de/)

* DME will publish sample COPR RDF under a CC BY-NC-ND license (http://creativecommons.org/licenses/by-nc-nd/3.0/de/) based on public domain sources of rasterized maps (e.g. the Library of Congress Collection)

* SPQR publishes its datasets under (various) Creative Commons licenses (see under http://tinyurl.com/LDClassics for some examples)

Process documentation will emphasise Open Source software packages where possible.

Pelagios Project Plan Part 3: Risk Analysis and Success Plan

2011-02-24T19:39:00.007Z

Risk Analysis

The main risks identified are shown below and will be reviewed every month:

Risk	Prob.	Impact	Action to Mitigate
Overly-complex or simplistic ontology inhibits uptake	Low	Med	The domain and technical expertise of LUCERO, ACRG and Pleiades, plus concrete use-cases from each partner, ensures a robust ontology. The use of modular extensions means that problems specific to one document type will not affect others, permitting multiple interest groups.
Lack of community interest	Low	Med	Each project partner already comes to the table with an established community of users, among whom the Pelagios outputs will be rolled out. Other interest groups such as Google, Ordnance Survey, GeoNames, EDINA and the European Commission will be involved through participating at the workshop.
Project stream unable to fund mapping and publication of data	Med	Low	The global economic crisis threatens all academic funding, but the highly international nature of the consortium and low dependency across the Work Packages greatly spreads this risk.
Critical failure of Pleiades Project	Low	Med	Pleiades is a core element of the Institute for the Study of the Ancient World (ISAW)’s digital infrastructure with high level institutional support and long term funding. It will be possible to use URIs generated from the Princeton Encyclopaedia of Classical Sites as a fallback position if necessary.

Evaluation

The success of the core ontology for place references (COPR) and linked open geo-data (LOG) approach will be measured against each publication stream using SMART criteria:

Specific: The ability to map a given document type to i) persistent Pleiades URIs, and ii) COPR-compliant RDF (see project plan post 1)

Measurable: A comparison of the precision and recall of the linked open geo-data (LOG) against a benchmark manual mapping of a sample from the source material

Achievable: Each team will identify an appropriate corpus in terms of both complexity and volume to demonstrate the value of the ontology

Relevant: Publication streams will refer to ancient places centred on the Mediterranean (whence come the majority of ancient sources) and datasets likely to be of interest to a wide audience

Timely: Sample data will be available four months prior to the end of the project. Complete datasets will be available one month prior to the end of the project.

In addition, documenting the process of implementing the core ontology by each stream is a key output of WP2 (see project plan post 6) by which future requirements can be identified, while each partner group will trial and elicit feedback on the demonstration web services among their target user-groups.

Sustainability

The RDF ontology will be hosted by Pleiades, whose long-term strategy and funding ensures the stability of both the domain name and content. Instance data will be held by the relevant partners, each of whom have sustainability at the core of their funding and institutional commitments. All web services and tools will use Open Source technology and Open Standards so as to be freely available for adoption by third parties. Code will be hosted in a suitable repository such as SourceForge or GitHub. A demonstrator version of the software will be hosted on multiple websites maintained by the project partners.

Pelagios Project Plan Part 2: Wider Benefits of Pelagios to Sector & Achievements for Host Institution

2011-02-22T23:50:00.001Z

Pelagios benefits a number of institutions and the wider community through its extensive network of collaborations:

1. Pelagios brings together three projects within major international universities to thrash out a core ontology for all users working with place reference data. They are:

The Open University’s LUCERO (Linking University Content for Education and Research Online), a JISC-funded project that is all about making University wide resources available to everyone using linked open data (LOD)
The Archaeological Computing Research Group of the University of Southampton, which involves archaeologists and computer scientists working together to develop Semantic Web data integration.
Pleiades, a joint project of the Ancient World Mapping Center, the Stoa Consortium, and the Institute for the Study of the Ancient World. Supported also by the U.S. National Endowment for the Humanities, Pleiades is giving scholars, students, and enthusiasts worldwide the ability to use, create and share historical geographic information about the Greek and Roman World in digital form.

2. Pelagios takes this core ontology and investigates its adoption by five international projects, which are already finding ways of extracting and using placename information. Each representing a different kind of document type, they are:

Google Ancient Places has been sponsored by Google to discover and represent place references in the unstructured XML of the Google Books Corpus. GAP is a consortium based at the OU, Southampton, Edinburgh and Berkeley with considerable experience in ancient geospatial data drawn from HESTIA, Open Context and CHALICE.
The Perseus project is a world leader in providing digital resources of the ancient world, focused primarily on primary sources enriched with structural mark-up. It is backed by the US National Endowment for the Humanities, the National Science Foundation, the Institute for Museum and Library Services, the Fund for the Improvement for Postsecondary Education, the Department of Education, the Mellon Foundation, and the National Endowment for the Arts.
Arachne is the central object database of the German Archaeological Institute, hosted and developed in cooperation with the Cologne Digital Archaeology Laboratory at the University of Cologne. Arachne has over 5,000 registered users who can access its extensive OER materials (850,000 scanned images and documentation for c. 250,000 sites and objects) free of charge.
SPQR is a JISC-funded project (JISCMRD Programme) using LOD approaches to provide integrated views across diverse resources relating to fragmentary ancient documents.
The Digital Memory Engineering (DME) research group of the Austrian Institute of Technology (AIT) is exploring ways of enabling and integrating services for the Europeana cultural heritage Web portal (see the Annotation Prototype) with an expertise in map documents.

By having each project partner document the process by which they take up and use the ontology, Pelagios will provide a benchmark publication that offers guidance to the community for using linked open geo-data (a LOG paradigm). In addition, by bringing these existing international repositories of Ancient World resources together, Pelagios will encourage its partners to exchange data, practices and experience with each other, their large extant user-base, JISC, and users worldwide.

3. Finally, Pelagios will demonstrate the value of the ontology to non-technical users by experimenting with various accessible web services that could draw upon it.
Benefits (summary table)

Who?	What?	How?
Pelagios Partners	Partner projects are already investing considerable resources in geospatially annotating their holdings. Pelagios will enable them to do this in a common framework, thereby increasing reusability of their data.	ontology development; data annotation; process documentation; tool development; tool reviewing; workshop attendance.
Workshop attendees / Data publishers	Data publishers will benefit from both a field guide to LOG publication for multiple document types and a clear ontology against which their data can be validated.	constructive feedback through consultation; workshop attendance where possible.
End users (teachers, researchers, learners)	Easy-to-use web visualization tools will provide immediate access for researchers, students and members of the public. A REST-based Web service will give Digital Humanists the power to perform large scale queries and complex analyses.	interest in ancient geodata; adoption of tools and services.
JISC	Pelagios will provide JISC with a variety of infrastructure assets (ontology, documentation, tools) that enable it to offer strategic leadership in the field of Linked Open Geodata	funding; involvement in project meetings and dissemination; synthesis project; programme activities.

Pelagios Project Plan Part 1: Aims, Objectives and Final Output(s) of the project

2011-02-21T16:51:00.001Z

Overall aim

To trial a method of linking open data (LOD) that enables scholars and enthusiasts alike to discover and make use of references to ancient places in maps, texts, images and tables.

Objectives

1. Define a Core Ontology for Place References (COPR). In discussion with external groups, the project partners will develop a base-line ontology to help users answer two kinds of query:

i) Within this document (text, map, database), give me a list/map of all the ancient places in it.

ii) Given this place, give me a list of documents (texts, maps, databases) that reference it.

i.e. we’re looking for the simplest method for enabling users to say with confidence that the document they’re looking at refers to place x (or vice versa), and then to bring up additional sources of information about it.

2. Trial this ontology on different document types (text, map, database) related to ancient world research, where each partner:

i) Aligns place references in their own document types to Uniform Resource Identifiers (URIs) in the Pleiades gazetteer of ancient places

ii) Generates Resource Description Framework (RDF) based on the ontology

iii) Documents that process so that it can be reproduced by others.

3. Create prototype tools and services, which are easily consumable by learners, educators, researchers and the public, to demonstrate the power and effectiveness of this approach.

i.e. answer the ‘so what?” question by demonstrating some of the things that users will be able to do with this resource.

Outputs

1. A publicly available, lightweight core ontology which can then by modified or extended by different users: i.e. the ontology will permit modular extensions for different kinds of document so that details specific to each type will not add unnecessary complexity for users wishing to publish data in conformance with the core ontology. The COPR ontology will be immediately accessible as RDF/XML on the Pleiades website.

2. Documentation of the processes by which each partner identifies place references and aligns those references to Pleiades. Drawing on the consortium’s breadth of experience, we will detail these processes as a guide for others looking to adopt a linked open geodata (LOG) approach: i.e. although we’re using URIs based on Pleiades, the ontology should be able to work with other gazetteers (including those based on modern placenames). Project partners will host instance RDF describing their holdings on their own websites or in established repositories such as the TALIS Connected Commons.

3. Development of open source web services and neo-geographic web tools. These technologies will optimize machine-access to the raw RDF and make both the discovery and visualization (by map, list or ordered ‘timeline’) of the integrated geodata simple for learners, teachers, researchers and the general public. All software Code will be made publicly available through an open repository (e.g. GitHub).

Welcome to PELAGIOS

2011-02-06T09:30:00.015Z

PELAGIOS stands for 'Pelagios: Enable Linked Ancient Geodata In Open Systems'. The idea behind the project is simple, even if the actions to fulfill it - and the acronym - are not. On-line resources that reference ancient places are multiplying rapidly, bringing huge potential for the researcher provided that they can be found; but, even then, the user currently has no way of bringing the data together. PELAGIOS has teamed up with an international consortium of leading research groups to trial a method of linking open data (LOD) that will enable scholars and enthusiast alike to discover all kinds of stuff related to ancient places and then to visualize it in accessible and meaningful ways.

The consortium of projects and research groups that make up PELAGIOS are as follows:

Google Ancient Places (Open University, University of Southampton)
LUCERO (The Open University)
Pleiades (Institute for the Study of the Ancient World, NYU)
Perseus Digital Library (Tufts University)
Arachne (University of Cologne)
SPQR (King's College, London)
Digital Memory Engineering (Austrian Institute of Technology)
Open Context (UC Berkeley)

We'll be aiming to post the project's many turns pretty regularly (say, every other week or so), since we believe that the process as much as any outcome itself may be of interest to the community. Above all, since a project of this size and nature will only succeed if it has the input from those who are going to use it as a resource (i.e. you guys), we welcome your feedback. So join us in going places, ancient style.

Pelagios is funded by JISC as part of their #jiscGEO programme.