By Mike Jackson.

A couple of years ago I was involved in a project for which we needed an ontology. I was very uneasy as prior experience, over the years, had taught me that ontology meant meetings that overran and the same discussions, with no outcomes, over and over, a conceptual Groundhog Day. But my worst fears were, thankfully, not realised…

The project I was involved in, SPQR, was concerned with epigraphy, information about inscriptions – such as grave markers, tablets, signs or graffiti – from the ancient world. Epigraphic data is often fuzzy and incomplete due to uncertainty over where and when inscriptions originate and to who they refer. SPQR’s goal was to see whether using linked data to represent epigraphic data and join multiple data sets together offered a means by which the combined data could be more readily explored and browsed than relational or XML representations traditionally used.

Each data set came from a different research group, each with their own data representation, and we used a common set of relations by which to link the data. These common attributes were dates, places and people e.g. where an inscription was found, where it originated from, when it dates from, when it was found, and who or what places are mentioned in the inscription. To express our relations we needed an ontology. However, agreeing on a representation for relations, and their attributes, can be non-trivial and involve significant effort. In our project, we captured this with a project risk, “ontology is not available in a timely way”.

We could not identify an existing ontology that covered epigraphy, so realised we’d have to create our own. We tried to reuse elements of the Europeana Data Model (EDM), a model  for cultural heritage data. We also looked at generic ontologies such as Dublin-Core, for describing physical and web resources, or OAI-ORE, for describing aggregations of web resources. After much discussion and early explorations, we decided to evolve our own ontology from scratch with the option of mapping to the EDM and others at a later date. This was not Not-Invented-Here syndrome, but purely for pragmatic reasons. We were a six-month project, and our goal was to assess linked data as a means to explore and browse data, not to produce an ontology. An ontology was a required – to provide a means link the data sets – but it was a means to an end. If we’d adopted an idealistic, as opposed to pragmatic approach, we may have produced an ontology for epigraphy but would have found ourselves no closer to our project’s goal and with little time left to do anything. As General Patton might have said, had he chosen a different profession, "a good ontology today was better than a perfect ontology tomorrow".

More generally, publishing data conforming to a custom ontology and linking that to existing ontologies, at a later date, can offer a lower barrier to publication than insisting that data providers must conform to existing ontologies prior to publication. However, a pragmatic approach is not a one-size-fits-all solution. If our goal had been to deploy our data sets in a production environment and continue to join these with other data sets, then we might have found ourselves isolated. Our sets would have been linked by a custom ontology with no buy-in from the rest of the epigraphic community – we’d then have had to either argue strongly for uptake of our ontology or to adopt another, incurring the overhead of transforming all our data sets.

The moral of this short tale is, if dealing with an ontology then consider what you need it for, how important it is to you and how it relates to your project’s goals. Tricky beasts those ontologies, handle with care!