Pelagios WP3 at a glance - Pt.1 widgets and user testing

WP3 tackles end-user engagement: i.e. subject specialists who lack the technical coding expertise to use the data underlying what is seen on the screen. The visualization service has been exploring 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. There have been three strands to our work in WP3 namely: (1) evaluation of users needs and requirements; (2) development of widgets; and (3) evaluation of the widgets.  We have been working on these strands through an iterative process, with initial requirements leading to the development of an alpha version of the widgets, which, after being evaluated, in turn led to a refined set of requirements for the final beta version of the widgets.

1. Evaluation of User Needs (a.k.a. deliverable D3.1 in project speak)

In an earlier post we identified three distinct types of users that would have distinct requirements and needs with respect to visualisation widgets:

•       "Super users" - e.g. developers, digital humanities specialists typified by the Pelagios2 project partners. This group includes folk who own and/or manage data that the widgets will display;

•       "End users" - people with an interest in Pelagios data, but without the technical skills necessary to exploit it. e.g. ancient history students, teachers and researchers, or else the general public with an interest in the ancient world;

•       "Web site admins" - people who own and/or administer sites that could embed Pelagios widgets. These could be museum or history related sites, and it's their technical requirements and restrictions that are the initial concern.

Past experience told us that asking end users a general question, like "What could or should visualisation widgets do for you?", are not particularly helpful: far better is to ask specific questions in order to get an idea about the kinds of tasks that end users currently perform, with which widgets may be able to assist. Because super users know the data that is to be visualised, we began by asking super users what they thought visualisation widgets might be good for, and for whom. We also asked them to identify any technical or legal issues they could think of that might restrict or prevent the widgets being used in the way that the person answering the question had imagined. These findings from the super user group were used to develop  a series of questions  for end users to find out what they thought visualisation widgets could be useful for. These responses from 12 end users were then  analysed and, coupled with the knowledge gained from the super users, were used to  inform the development of an alpha version of a Pelagios place widget, i.e a widget for showing the relationships between places and data in ancient history collections (e.g. digitised books, data about ancient artefacts, etc.).

2. Widget Suite, Alpha version (a.k.a. D3.2)

The alpha version of the place widget was evaluated by four end users. Three of the participants tried out the widget in a face-to-face session with the evaluator, while one tried it remotely. In the face-to-face sessions the users were shown a re-versioned Openlearn page, entitled ‘The broader context: Other athletic festivals in Ancient Greece’, and asked to think aloud as they intearcted with the page and the embedded widgets.  A version of the page they interacted with is available, but this version includes the final version of the widgets (i.e. not the alpha version the participants saw). This evaluation led to series of recommendations group into two sets: (i) on improving existing functionality, and (ii) on extending the functionality. These are described below.

 (i) On existing usability, functionality and accessibility

Overall, the interface seems well designed and is clear and easy to use. Here are some comments about specific aspects of the usability, functionality and accessibility of the widget, along with some recommendations...

•       When the user hovers their mouse over the widget icon embedded in a page, the mouse cursor style remains as the default cursor.
 Recommendation:  The mouse cursor should change to pointer style when over the widget icon embedded in a page. In addition, there ought to be some alt text for the widget icon, and there should be some ‘tool tip’ information which appears when the user hovers over the widget icon to indicate what will happen if the user clicks on it. There could also be alt text for each of the images used in the widget pop-up.

•       On the widget pop-up, the information sources titles (e.g. GAP, Perseus, etc.) and the arrow icon to the right of the title are clickable, but the mouse cursor does not change to pointer style.
 Recommendation:  The mouse cursor ought to change to pointer style when over the source titles and the arrow icon.

•       The information provided by GAP about each group of hits, and about each individual hit, is relatively helpful to users without specialist digital ancient history and place knowledge. In contrast, for both Perseus and Arachne the information about each group of hits, and about each individual hit, is not terribly helpful. It provides no way of distinguishing between the hits before the user clicks on them.
Recommendation:  For Arachne, each hit is currently shown as e.g. ‘Item 5’ i.e. the text ‘Item’ along with a number. This should probably be replaced with a title that allows the user to distinguish between the hits displayed before they select a hit to click on. For Perseus, the hits are grouped, as in e.g.:
“Perseus Greco-Roman:1999.02.0076:Book 3 1 hit
Perseus Greco-Roman:1999.02.0132 2 hits”
but these group titles are not intelligible to the participants.  The lists of hits follow the same pattern as those for Arachne i.e. ‘Item 5’ etc., and have the same problem. 
Recommendation:  As for Arachne, the title of individual hits could be best changed from ‘Item 5’ or similar to something meaningful that allows the user to distinguish between the hits. The grouping of Perseus hits should be explained to users in some way, such as through a tip that appears when the user hovers over a group title, or through a help page that is linked to from the widget.

•       Opening the widget pop-up causes the browser window to scroll to the top of the page. The participants did not mention this as it was explained to them that it was an alpha version and it would be fixed.

•       All participants liked the Flickr section (e.g. “it gave me a sense of the place as it is now”).
 Recommendation: The experimental Flickr section should be kept. There could, however, be an indication as to how the images displayed are sourced so that users can find out that it is not a search of the whole Flickr database but a constrained search e.g. through a link to some help text.

•       Sometimes a section will indicate that data is being retrieved by showing the text ‘Loading’.  This is helpful, but the ‘Loading’ text remains static and the user can think something has gone wrong if nothing happens for several (tens of) seconds.
 Recommendation:  Show that something is happening: e.g. display ‘Loading item x  of 2112’, where the x changes as the individual items are loaded.

•       The widget pop-up obscures the page and cannot be moved to reveal the page. 
Recommendation:  Make the widget pop-up moveable and resizable so that the user can move it to see the information displayed by the widget pop-up alongside the page context from which the user triggered the pop-up.

•       The Pelagios icon and text at the top of the widget pop-up occupy a lot of screen space.
 Recommendation: Make the logo at the top of the pop-up occupy less space!

(ii) On extending the functionality

•       To be able to save items via bookmarking, and to share  via social bookmarking, tweeting etc.

•       To be able to filter large hit sets: e.g. for some of the places the different services produced more than 100 hits (occasionally more than 1000). It could be useful to filter these hits before examining them.

•       To be able to see relationships between places on the map. In the case presented to the participants, for each different example a single place was shown on the map. It would be useful to be able to see where different examples are on the same map.

•       To be able to search for other places so as to find the datasets for the user’s place of interest.

3. Widget Suite, Beta version (deliverable D3.4)

Findings from the alpha testing resulted in the decision to implement a search widget in addition to the place widget. The final (beta) version of the two visualization widgets was announced in mid-July. 

OCRE Joins Pelagios

Last week, the American Numismatic Society and the Institute for the Study of the Ancient World at New York University released Online Coins of the Roman Empire (OCRE).  OCRE aims to represent every Roman imperial coin type from Augustus to Anastasius (31 B.C. to A.D. 518), based on the enumeration system and metadata contained in Roman Imperial Coinage (RIC).  The first phase of the project contains those coin types from Augustus through the reign of Hadrian (A.D. 138)--roughly 8,300 distinct typologies. Many of these records link to physical specimens owned by the American Numismatic Society, and we hope that other collections will contribute their own data to the project in the future.

Each of these records is described with the Numismatic Description Standard (NUDS), an XML schema influenced by other common metadata standards, such as TEI and EAD, and by the tenants of linked open data.  Like other standards common to the library and archival communities, NUDS uses the W3C XLink attributes for semantic linking.  The record for Augustus 1a as defined in RIC contains the obverse and reverse type descriptions, legends, and other typological attributes--material, method of manufacture, place of minting, etc.  These attributes are intellectual concepts represented by web resources on nomisma.org.  The denomination, quinarius, is represented by the URI http://nomisma.org/id/quinarius.  The coin was minted in Emerita, represented by http://nomisma.org/id/emerita.  The nomisma.org RDF model for Emerita indicates that the Pleiades place http://pleiades.stoa.org/places/256155 is a related resource, and thus the Pleiades URI is stored in OCRE's Solr index for querying.  As a result, the contents of OCRE are available in the form RDF, which is, in turn, ingested into Pelagios.  More than 7,600 of the records in OCRE are associated with Pleiades places and accessible through Pelagios.  Moreover, OCRE supports an Atom feed driven by Lucene queries.  This Atom feed links to the HTML representations of each record, as well as RDF, KML, and source NUDS/XML.  It is therefore possible to programmatically page through the Atom feed to harvest all of the data in OCRE.

Work on OCRE is ongoing.  We expect the coins of Antoninus Pius to be published in the near future.  It may take several years to fully publish the coin types through Anastasius, but the current phase of the project is an important first step in bringing the study and publication of Roman imperial coins into the twenty-first century.

Pelagios WP1 at a Glance - Pt.2: Backstage

This post continues my report on the results of Work Package 1. (Read the first part of the series here.) In this second part, we'll take a look behind the scenes of the Pelagios API.

API Administration Area

The API admininstration area allows us to easily add new datasets or update existing ones manually. Furthermore, it has a "statistics dashboard". In project management terms, the statistics dashboard corresponds to Deliverable 1.3; and it tells us how our API is being used.

Using a few lists and charts, we can see what terms users are searching for, which places and datasets are most popular, and what response formats (HTML, JSON, RDF) are most frequently used.

API Statistics Dashboard

Pelagios Monitor

The second essential component backstage is the Pelagios Monitor. The Monitor is separate from the API; and project-organization-wise, it represents the main part of Deliverable 1.1. The Monitor's (declaredly boring) task is to periodically crawl our partners' data to check for changes.

Needless to say, all software components we produced in WP 1 are open source (licensed under the GPL v3) and available on Github!

The API project is located at http://github.com/pelagios/pelagios-api-v2

The Monitor project is located at http://github.com/pelagios/pelagios-monitor

Rainer Simon
Austrian Institute of Technology

How does CLAROS make its annotations for Pelagios?

The CLAROS data aggregation setup (http://clarosnet.org/) has been through several iterations since we first got involved with Pelagios in 2010, and work on OAC annotations has proceeded fitfully. However, we are now generating triples in the proper form as part of our regular data build, which makes it an appropriate time to report on what we have achieved.

CLAROS currently aggregates data from 12 partners, most of whose material relates to the ancient world. The input is RDF XML against the CIDOC CRM, largely describing objects:

arachne	Arachne	185119 objects
ashmol	Jameel Collection, Ashmolean	2316 objects
beazley	Beazley Archive	130960 objects
bsa	British School at Athens	(pending)
bsr	British School at Rome, photographs and plans	16043 objects
creswell	Creswell Photographic Archive, Ashmolean	6521 objects
cycladic	Cycladic Museum, Athens	348 objects
lgpn	Lexicon of Greek Personal Names	251821 people
limc	LIMC Paris	4724 objects
limcbasel	LIMC Basel	55852 objects
metamorphoses	Gazetteer	9396 places (6325 geolocated)
waa	World of Ancient Art	406 places

For the purposes of Pelagios, the more interesting figures relate to our coverage of places:

• c.9300 places known
• c.6200 places geolocated
• c.1500 places linked to Pleiades
• c.4330 places linked to geonames.org

Overall, we can access in CLAROS c.125000 objects via their geolocated find spot (out of c.400000 in total, and access c.161000 people via a "birth" place (out of c.250000). This means that we have a considerable amount of work to do in mapping place names together, and relating named places to geolocation - although bear in mind that many places will never (?) be in Pleiades (eg those in Japan and China), so the daunting-looking discrepancy of 1500 Pleiades vs 4300 geonames is not as bad as at first appears.

The majority of the data hitting CLAROS uses a simple place name, so the main work of our ingest procedure is to attempt to map that to known place (and thence to Pleiades). The procedure may be of interest:

1. Does the <E53_Place> in the RDF already have a geolocation? OK
2. Normalize place name. Translate space to -, lower-case, etc
3. Does the name match an entry in our mapping table?

     from="academy" to="athens-academy"
     from="aegypten" to="egypt"
     from="agios-ioannis" to="athens-agios-ioannis"
     from="agli" to="aglie"
     from="agrigento" to="sicily-agrigento"
     from="aidinjik" to="edincik"
   

   if so, use the canonical form
4. Does name of place match a known place? link to that place
5. Does name of place partially match a place? create an <E53_Place> which has a <P89_falls_within> linking to the half-match. Example "athens-kerameikos"
6. Does <E53_Place> have a geonames link? get lat/long from www.geonames.org

Flaky though this can sound, it largely works. More or less all places which have a hundred or more objects attested from them are safely identified. The CIDOC CRM RDF which identifies a place can look something like this:

   <E53_Place rdf:about="http://id.clarosnet.org/places/metamorphoses/place/astypalaia">
      <rdfs:label>[GR] Astypalaia</rdfs:label>
      <P87_is_identified_by>
         <E48_Place_Name rdf:about="http://id.clarosnet.org/places/metamorphoses/placename/astypalaia">
            <rdf:value>Astypalaia</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/astypalaia/coordinates">
            <claros:has_geoObject>
               <geo:Point xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#">
                  <geo:lat>36.58116008943272</geo:lat>
                  <geo:long>26.39066203259252</geo:long>
               </geo:Point>
            </claros:has_geoObject>
         </E47_Place_Spatial_Coordinates>
      </P87_is_identified_by>
      <skos:closeMatch rdf:resource="http://sws.geonames.org/264408/"/>
      <skos:closeMatch rdf:resource="http://pleiades.stoa.org/places/599536#this"/>
      <P89_falls_within rdf:resource="http://id.clarosnet.org/places/metamorphoses/country/GR"/>
   </E53_Place>

Once we have the hundreds of thousands of objects and people duly linked to a place, it is easy to associate them with Pleiades, via the <skos:closeMatch> shown in the example. The data is loaded into a RDF triple store (Jena), and then we can run the following SPARQL query to generate a new set of triples containing the needed OAC annotations:

CONSTRUCT {
  ?anno a oac:Annotation ;
    dcterms:conformsTo <http://id.clarosnet.org/annotation-class/find-location> ;
    oac:hasTarget ?object ;
    oac:hasBody ?pleiades .
    ?object a oac:Target, crm:E22_Man-Made_Object ;
    rdfs:label ?label .
} WHERE {
  ?object crm:P16i_was_used_for [
    crm:P2_has_type <http://id.clarosnet.org/vocab/Event_FindObject> ;
    crm:P7_took_place_at ?place
  ] ;
    rdfs:label ?label .
  ?place skos:closeMatch* ?pleiades .
  FILTER (regex(str(?pleiades), "pleiades")) .
  BIND (uri(concat("http://id.clarosnet.org/annotation/find-location/", sha1(str(?object)))) as ?anno) .
}

The resulting triples are loaded into a new graph called "pelagios" in the triple store, and finally we are able to point the Pelagios folk at http://data.clarosnet.org/graph/pelagios, and the corresponding VoID at http://data.clarosnet.org/graph/void, and results start to appear in Pelagios clients.

So far, so good. But there remain two problems, one practical and one theoretical.

Firstly, the CLAROS collection includes 180000 objects from Arachne; but Arachne is a Pelagios
contributor in its own right. This means that the existence of a gold ring from Athens will be reported twice in Pelagios. To solve this, we need to adjust the SPARQL inference above to run separately against each of the partner data collections, and generate discrete sets of OAC triples. This will allow Pelagios to avoid harvesting Arachne from CLAROS, assuming it is better to come from the source.

Secondly, some of the relationships in CLAROS start to strain the notion of an annotation.  When a person called Alexandros comes from a place called Athens, is it really sensible to say that the person "annotates" the place? It could equally be argued that the place annotates the person. In some ways, this does not matter so long as all the data contributors follow the same conventions, but eventually consumers will find our data sets in isolation, and find them quite confusing. Other similar projects using the same technology may make quite different choices.

The Pelagios idea of using OAC as its structure was a good one, and has let the project proceed fast and efficiently. Whether it can, or should be, maintained as the ancient world semantic web builds up, is debatable.

Pelagios WP1 at a Glance - Pt.1: The API

As the Pelagios 2 project is coming to a close, I'd like to wrap up our infrastructure work package (WP 1) with a series of posts on the software and tools we've been producing. In this first post I want to showcase the main tangible result from WP 1: the Pelagios API (or Deliverable 1.2, in project management terms).

The Pelagios API enables you to search and browse the data we are aggregating from our partners. It has a basic HTML interface, so you can click your way through the Pelagios network of places, datasets and place references. Your starting point can be either a particular place or a particular dataset. You can search for those by name, or - in case of the datasets - browse the list.

Places in the API

Olympia in the API

The API user interface provides views on the different objects in Pelagios: Places are shown with some basic metadata from their original Pleiades source entry, including labels, a description, their feature type, and so on. A table underneath the place description lists the references the Pelagios network has for that place, sorted by partner dataset; and clicking an entry will take you to the list of references for that place, in that particular dataset.

Below the list, you will find the neighbourhood cloud. This little gadget looks like one of the tag clouds often seen on blogs or social bookmarking sites, where they usually visualize the frequency of often-used words or tags in the system. This way, users can get a quick overall grasp of what the content on a particular site might be about.

The Pelagios neighbourhood cloud has a slightly different purpose: it shows neighbour places - not in a geographical sense, but in terms of how they are connected in the graph. Larger tags mean that the neighbour is "stronger" connected to the place than others.

We are still fiddling with the ranking metrics, but in a nutshell, a "strong" connection (as regards our current visualization) is one that runs through datasets that are primarily concerned with those two places. For example: see how the cloud for Thermopylae will render a neighbourhood to Lacedaemonia, Sparta and (to a slightly lesser extent) Salamis; or how the Island of Sardinia sits nicely between places in Italy and North Africa.

Datasets in the API

Datasets have similar overview pages. As for places, these show some basic metadata for the dataset (title, description, license terms, etc.) and list the subsets contained in this dataset. The view also shows a small bar graph listing the five most frequently referenced places.

Machine-Access

But the main purpose of the API is, as the name implies, not the user interface - it is to serve out machine-actionable representations of our data. To this end, the API provides responses in RDF (currently in XML and Turtle serialization), as well as JSON (with support for Content Negotiation). Cross domain requests to the API (essential for supporting client-side mashups) are supported through JSONP and CORS.

In terms of functionality, the API offers everything that's in the user interface, plus a few additional features which are not (yet) found there, including

• geographical search
• "geo-footprints" for datasets, i.e. the geographical area covered by all places referenced in a dataset
• configurable pagination for everything that comes in long lists (e.g. place references in a particular dataset)
• shortest path search between two places in the graph

The Pelagios API public beta is located at http://pelagios.dme.ait.ac.at/api

Technical documentation is part of our cookbook, available here.

Rainer Simon,
Austrian Institute of Technology

Continue with part 2 of this post.

MEKETRE - New Project Partner Introduction

The MEKETRE project seeks to systematically collect, research, and study the reliefs and paintings of Middle Kingdom tombs of Ancient Egypt. One of its main aims is to map and elaborate the development of the scenes and their content in comparison to the Old Kingdom. The project is funded by the Austrian Science Fund (FWF) and has a duration of three years (late 2009 until late 2012). The project's technical part features an online repository (the MEKETREpository) for easy exploration of the collected data.

Collected Data

The data in the MEKETREpository is, at the highest level, structured into tombs and fragments that contain themes, i.e. specific types of scenes that are part of the tomb decoration programme. Additional information can be attached to these themes in the form of annotations. To each tomb, theme and fragment multiple annotations can be attached that, e.g., highlight specific regions of interest. Furthermore, they connect these regions to descriptions which can be provided as free-text but also as classification terms or keywords from a controlled vocabulary. Annotations are an intuitive means to structure and organize information, for both data consumers and producers.

So far, the egyptological staff of the project has gathered an extensive amount of data, e.g.:

• >240 Objects: ~114 Tombs, ~120 Themes, ~8 Fragments
• >570 Images (3.5 GB)
• ~1900 Annotations
• ~500 Basic Terms, ~500 Classification Terms
• >1700 References to >200 Publications

As mentioned above, the project also develops a controlled multilingual vocabulary with the main purpose to unify the terminology used for the descriptions of icons attested in the two-dimensional art. It is also published online as Linked Data and available for download in various serialization formats.

Linked Data Utilization

Every item in the repository can be viewed by using a webbrowser (cf. this item). Additionally, there is also the option to download an RDF representation of the item by clicking at triple icon on the top left of the page.

The controlled vocabularies used for annotating the repository items are created by using the third-party web application PoolParty. The tool supports scholors from the Egyptology domain in collaboratively building an online thesaurus following the SKOS de-facto standard for controlled vocabularies on the web. Our thesaurus is linked directly from the project's homepage or can be accessed directly from the PoolParty server.

In our implementation we use a MySQL database together with Triplify to generate the RDF representation of our content. It aims to adopt and reuse as many existing vocabularies as possible (e.g., Dublin Core, FOAF) but also makes use of our own core vocabulary.

Future Work

As a next step we intend to extend our repository by a separate web application that supports easy contribution (e.g., image uploading, creation of annotations, suggestion of new vocabulary terms) for interested users without scientific background. The goal is to collect even more material on Middle Kingdom artwork that can then be reviewed and amended by scholars. If the quality has reaches the necessary level, the material will be integrated into the MEKETREpository.

Announcing the Pelagios widgets

The Pelagios widgets are small applications that you can put on your website to allow users of your site to see data from Pelagios partners.There are two widgets, one to display information about places you mention on your site, the other allows people to search for information related to places.

Pelagios Place Widget 

The first widget is the Pelagios Place Widget. This is an icon with the Pelagios logo that you can add to your website. When you add it you specify a particular place in the Pleiades gazetteer and the widget will then provide information about that place.

Here is a screenshot of the icon which you can see after the link to Delphi.

When the user clicks on the icon, they then get information about Delphi from the Pelagios partners as well as relevant photos from Flickr.:

You can see a live demonstration of the widget for Corinth here by clicking on this icon:  (opens in a new tab or window). There is also  a live demonstration of the widget as an overlay for Corinth here along with demonstrations for a selection of other places.

There are various options when you embed the widget. For example, you can choose the whole widget to display immediately rather than via an icon which is clicked open, or you can choose for the map to not be displayed.

Pelagios Search Widget 

This consists of a search box. If you search for a place then it will show you all the matches for that place as a list and on a map. You can then click on each one to obtain data from Pelagios partners about each place.

Live demonstration of the search widget

How to embed the widgets 

You can add the Pelagios widgets to your site by adding a small snippet of HTML to your page. There are full instructions for embedding the widgets here.

Some sites, in particular most blogging and content management systems, have restrictions on the HTML you can add, and in particular will not allow you to add Javascript. For these, you can add the Pelagios Place Widget via an image and link, although the widget will open in a new tab or window. Hopefully at some point in the future we will be able to turn the widgets into Wordpress plug-ins, Google gadgets and other formats that may be able to help with this. .

Feedback 

We would warmly welcome and feedback on the widgets and suggestions for future work on them - please send any comments to me at j.culver@open.ac.uk. Please do also feel free to try embedding them on your sites and let us know if you have any problems or if the documentation could be improved.

More about the widgets 

There is much more information about the widgets on the Pelagios Widget pages and the source code is available on Github released under Gnu Public Licence v3. They were developed here at the Institute of Educational Technology at The Open University.

Geographical information retrieval of historical regions

In the last few weeks I have been developing some API and an interface over the PELAGIOS API in order to be able to retrieve historical places, and their relative annotations, by using some geographical context. The issue of superimposing a geographical representation over some data collection is not novel. In modern data collections, for example the data produced by public administrations nowadays, organisations use geographical nomenclatures such as the administrative subdivisions, or the NUTS if the data is statistical observations. 

For historical data collections this is not always feasible, since the administrations of past kingdoms not always provided a sharp definition of their boundaries (sharp meant in a modern sense, with precise coordinates for regions' shapes) nor a deep subdivision which can help our information retrieval task.

Fortunately for PELAGIOS' users, some of the boundaries for the provinces of the past roman empire have been made available as shape files, and this can help us in browsing the wealth of data annotations provided as geolocalized linked data. The shape files in question were digitised from Barrington Atlas rasters (georegistered and supplied by AWMC) by Pedar Foss at Depauw University in 2007 within the context of the MAGIS project, and have been provided by Tom Elliott from the Institute for the Study of the Ancient World, New York University. The regions represented can be seen in the figure below.

Roman provinces up to AD 117 visualised in CartoDB

The present post is not about a single API or a single interface that can be implemented on top of PELAGIOS data and services, but instead it aims to provide some insights on how to implement geographical browsing by using open source tools. 

In order to visualize places and annotations from PELAGIOS API we exploited the geographical search by bounding box. By retrieving places in the PELAGIOS network contained by a bounding box we are half way to filter them via any polygon. In fact, by adopting a GIS we could directly querying data by polygons. Unfortunately that would require to have all the annotation data and the regions' polygons stored in the same database which is against the principle of distributeness of the linked data paradigm and it is not feasible in general scnarios. In fact that solution would require to provide a version of the PELAGIOS data to any interested user that would be forced to install GIS software and host their particular polygons. 

Instead, in here, what we did is to decouple the management of the annotation data with the geographical retrieval features, trying to minimize the amount of software to install and reusing as much as possible the data and services already provided. For this reason we uploaded the polygons we were interested on in a web enabled version of postgis, called CartoDB. CartoDB allows a limited and free use of the web platform, but users can download the open source version and install it on a server if and when needed. CartoDB allows to run SQL queries over HTTP requests that allow developers to integrate the system easily.

As said earlier, once we have the capability to query by bounding box we are half way to being able to query by polygons. In fact, by querying the CartoDB we can retrieve the shape of a region by using its name (e.g. Aquitania in the figures below). If we want to retrieve all the PELAGIOS places contained in the Aquitania region we can query the PELAGIOS API for the places contained in the bounding box of the polygon first, and then filter those places based on the topological containment applied to the retrieved shape. 

Selection of PELAGIOS places by using
region's bounding box

Filtering of those resources by using the
polygon topological containment 

The activities involved to extract places by using polygons can be represented by the diagram below and involve three actors: the service implemented by the ECS dept. in Southampton (named ECS), the PELAGIOS API, and the CartoDB instance used for this scenario.