*This is the second in a series of posts from Dr Michael Piotrowski, one the recipients of the DM2E Open Humanities Awards – Open track.*

Europäische Friedensverträge der Vormoderne online (“Early Modern European Peace Treaties Online”) is a comprehensive collection of about 1,800 bilateral and multilateral European peace treaties from the period of 1450 to 1789, published as an open access resource by the Leibniz Institute of European History (IEG). The goal of the project funded by the DM2E-funded Open Humanities Award is to publish the treaties metadata as Linked Open Data, and to evaluate the use of nanopublications as a representation format for humanities data.

We’ve now converted the the structured metadata from the legacy database into RDF. In my last post I talked a bit about the structure and content of the legacy database; as we expected, the conversion required a fair bit of interpretation and cleanup work, but all in all, it worked quite well.

As the basis for our data model we have, not surprisingly, used the DM2E model. Currently we have three main classes of entities, namely the treaties, the treaty partners (or signatories–but we prefer the term partner to avoid confusion with the negotiators, i.e., the persons who actually signed the treaties), and finally, the locations where the treaties were signed. We usedm2e:Manuscript as class for the treaties, edm:Agent as class for the partners, and edm:Place as class for the locations. Furthermore we use the following properties:

• dc:title for the treaty titles,
• dc:date for the treaty date,
• edm:happenedAt for linking to the location,
• rdfs:label for the names of partners and locations, and
• skos:narrower and skos:broader for modeling the hierarchy of partners.

The last point may need some explanation. Partners may be in a hierarchical relationship to each other to model that a power may be part of a larger entity. For example, Austria was a part of the Holy Roman Empire, whereas Milan, Mantova, and Sardinia were (at various points in time) parts of Austria. However, historical realities tend to be quite messy, so these relations are not necessarily “part-of” relations in the strict sense; for example, Austria also had territories outside the Empire. The hierarchy also contains “fictitious partners” as a help for searching; for example, introducing Switzerland or Parts of the Empire as “fictitious partners” makes it easier to search for treaties concerning certain regions of Europe. This pragmatic approach was taken over from the legacy database, as we think it makes sense, at least for the time being.

To link the treaties to the treaty partners we’re currently using the dc:contributor property. We’re not yet completely happy with this solution; it seems to stretch the meaning of “contributor” a bit. Coming up with a better solution (or for arguments in favor of keeping dc:contributor!) is on our todo list.

So, if we take a specific treaty, such as the Provisional convention of subsidy between Great Britain, the States General, and Austria, we have the following data:

Property	Value
Type	Manuscript
Title (dc:title)	Provisorischer Subsidienvertrag (de)
Date (dc:date)	1746-08-31
Contributor (dc:contributor)	ieg-local:partner/12 = Austria ieg-local:partner/42 = Great Britain ieg-local:partner/49 = States General
Happened at (edm:happenedAt)	ieg-local:place/13 = The Hague

This display is somewhat simplified for illustration but should give you an idea. We have loaded the data into Fuseki and set up Pubby (a Linked Data frontend for SPARQL endpoints) on an internal server. For reference, Figure 1 shows the last page of the treaty; the last sentence before the seals and signatures gives the place and the date: Fait à La Haye le trente un du Mois d’Aout de l’année mille Sept cent quarante Six.

What are the next steps? Now that the data can be easily browsed through Pubby, of course you spot various smaller errors here and there, which we’re fixing as we go. More importantly, we are currently working on linking the locations and partners to suitable authority files, most notably the GND, which will make the data not just open but also linked. The locations should be relatively straightforward, but the partners may pose some problems; we take the obvious approach to first handle the easy cases and then deal with the rest.