People are inherently social creatures. This means any project about people almost always has to deal with the relationships between people. In this, SNAP:DRGN is no exception. Since this is not a new problem there are a number of different models that already exist and are in use in other projects. Ideally we would reuse an existing, standard ontology to describe the relationships—this would allow us to be easily compatible with other similar projects that had (one hopes) gone through a similar thought process and came to the same conclusion.

As with most projects there are a number of specific requirements that we need to keep in mind when deciding what models to use:

• The project is primarily concerned with the classical world (although careful selection at this stage may make things easier in the longer term should future projects want to move beyond that geo-temporal constraint). For the most part this means that we can just ignore relationships related to which social media platform a person belongs to; however it means we must also ensure that the types of relationships that existed in the ancient world—most modern ontologies, for example, don’t account for slaves, freed(wo)men or demi-gods.

• SNAP:DRGN takes a deliberately restricted view of the core relationships that it seeks to encode. The ontology is not aimed at defining a person with all that entails—that is left to a given project to decide on how they which to define, model and encode a person (or person-like entity). SNAP:DRGN is focusing on encoding the information that is directly part of the identifying moniker of the person (or person-like entity).

Modelling Relationships

Before we can even get onto the question of what relationships we need to model, we have to decide how we are going to model them. The simplest way, as seen in the Relationship Ontology (an extension of FOAF), is to define as many properties as needed. Since it is possible to have sub-properties in OWL, these properties may be arranged hierarchically to allow for different levels of specificity, but all necessary properties must be defined individually.

X <property> Y

Another common method is employed in CIDOC CRM which has a small number of direct properties but in the majority of cases defines the relationship of one person to another through the event which created that relationship. For example the event of a birth results in the parent-child relationships.

X <property> [Event] <property> Y

This is a powerful way of modelling these relationships and can allow much further-reaching querying and inferencing than the straightforward property model. However the gains in power must be weighed against the gains in complexity. Much like the more general ‘top-down’ ontology vs ‘bottom-up’ folksonomy debate, the relative merits of simplicity and ease of use must be balanced against the grater range of linkage and processing options.

A third method can be seen in the OntoMedia Traits ontology module. Falling between the above options, OM:T uses a generic ‘trait’ relationship to link between the Person entity and an entity which encodes the relationship type. The chain is then completed with a second property determined by the relationship type.

X <has-trait> [Relationship Type Class(es)] <property> Y

The advantage of the relationship type being defined by a class rather than a property is that it opens up the possibility of dual classing the relationship to add additional detail and, as with the previously mentioned event method, to attach supplemental information directly to the relationship.

The axiom to keep it simple draws us towards the first option even as our academic desire to add in just one more detail pulls us away. Looking at other successful projects we can see that simplicity, even as the cost of completeness, is often key. And the one thing we can be sure about—whatever we do it will just get more complex from here.