How Ancient History Encyclopedia linked up with Pelagios

We're back for some information on how we linked Ancient History Encyclopedia to Pelagios. I hope that this can be of help for future websites that join this excellent project.

First of all, we need to explain how AHE works. The website is entirely based on tags / keywords. Each tag has one (and only one) definition associated to it, and many possible articles, illustrations, or timeline events. It is possible --and indeed necessary for the website to work properly-- that articles, illustrations, and timeline events are linked to many tags. An article on "Trade in Ancient Greece" would be tagged with "Greece", "Economy", "Trade", "Colonization", and it would subsequently be listed under all those tags' pages.

Now the initial idea was easy: Let's link up every geographical tag of ours (cities, countries, regions) to its equivalent location in Pleiades. We've got 2,400 tags, and we expect to have many more in the future, so we didn't want to do this all by hand. Instead, we wanted something future-proof, that would notify us automatically of possible matches between tags and Pleiades locations.

Every day, we automatically import the Pleiades database of names, their respective location IDs and their locations and mirror it in our database using a cron job. We wrote a nifty little PHP function that converts the Pleiades data to a PHP array -- feel free to use it.

In our editorial team's interface we have a page that automatically tries to find possible matches between Pleiades place names and tags on AHE. For links, we only look at those tags which have a definition -- after all we only want to link up content that is of use to potential readers, not empty tags. Editors can then review the link suggestions and either approve or reject them. That way, we already found most of the links between our datasets.

Suggestion from the automatic linking script

Then there is the problem of links that aren't found by our automatic matching script. For example, on AHE the tag is called "Greece" whereas on Pleiades it's known as "Hellas". Another example would be "Mediterranean" on AHE is known as "Internum Mare" at Pleiades. No script can figure that out!

For those cases, we added another functionality to our tag editor form: Our editorial team can simply search the Pleiades DB mirrored on our server for links, for each tag. An editor could for example see the tag "Greece", notice that it's not linked to Pleiades, open the linking form for the tag Greece and manually search for "Hellas".

Tag listing for editors (2nd last column is the Pleiades link)

The search will give exactly the same type of results as the automatic linking does above, with a map to help the decision-making.

When a tag is linked, we write the Pleiades ID into a newly-created field in that tag's entry in our database (hoping that Pleiades will never change tag IDs).

Now it's time to deliver all this data in a format that Pelagios can understand. We have another script that goes through all the linked tags and fetches their respective definitions, as well as all articles and illustration that are linked to them in our database. Then we output each tag definition as Turtle/RDF in the Pelagios format, linked to a specific Pleiades ID. All articles and images associated with that tag are also output for that Pleiades ID. The final result looks like this. Notice that while each definition only occurs once (one definition per tag), articles and images can appear multiple times, linked to multiple tags (as one article or image is linked to many tags).

Personally, I find that Turtle/RDF is somewhat mindboggling and not exactly easy to understand (I'm not a professional programmer), but with the excellent help of Simon Rainer, Elton Barker, and Leif Isaksen we managed to make it work and validate. Thanks a lot guys... we couldn't have been able to do it without you!

We then submit the generated file to Pelagios (in the next version of Pelagios it'll be imported automatically on a regular basis).

I hope that this was helpful or at the very least interesting to anyone who is looking to link up with Pelagios. If your site is similar to ours, do feel free to drop us a line on {editor AT ancient.eu.com}! We're always happy to help!

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

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.