This post is about how to name properties and relations in RDF schemas. Or rather, about how different ontology developers use different conventions and how this can sometimes be confusing.
Part of the work that I’ve been doing over the last few months at TSO has been for OPSI, who want to provide information about UK legislation for reuse through an API as well as eventually through a new end-user service. The Single Legislation Service API is now available, in beta, if you want to take a look.
One way in which we’re providing information about legislation is using RDF/XML. An example is the Criminal Justice Act 1993 Section 67, for which RDF is available at http://legislation.data.gov.uk/ukpga/1993/36/section/67/data.rdf. For now, we’ve made the decision to not attempt to create any of our own ontologies for the RDF, but to reuse ones that are already out there.
We’re making an explicit distinction within the service between the idea of an item or section of legislation (such as the Criminal Justice Act 1993 Section 67), versions of that legislation (such as the Criminal Justice Act 1993 Section 67 as it was in force on 1st December 2001) and that version formatted in XML, HTML or some other format (such as the XML version of the Criminal Justice Act 1993 Section 67 as it was in force on 1st December 2001).
These three ways of thinking about legislation correspond to the FRBR Work, Expression and Manifestation. So to talk about them in RDF, we use the FRBR vocabulary created by Ian Davis and Richard Newman, in which these classes are called
One of the other ontologies that we’re using is the Metalex ontology which is specifically designed for legislation. It also builds on FRBR, and calls the relevant classes
So we have two vocabularies that represent the same concepts with equivalent classes, and obviously they have equivalent properties linking them. And this is what I find interesting. In the FRBR vocabulary, the relationships are:
frbr:Work -- frbr:realization --> frbr:Expression
frbr:Expression -- frbr:realizationOf --> frbr:Work
frbr:Expression -- frbr:embodiment --> frbr:Manifestation
frbr:Manifestation -- frbr:embodimentOf --> frbr:Expression
The FRBR vocabulary uses nouns to name the relations. It’s the same pattern that’s often used to name properties (ie predicates that take literals as values):
Using nouns leads you to read statements in the pattern “subject’s predicate is object”:
The trouble is that this pattern really doesn’t work for the inverse relationships:
They really want to support a sentence structure like “subject is a predicate object”:
But if you then map that back to the original relation, you run into trouble, because there’s a temptation to add a preposition into the sentence to make it make sense, and inserting that preposition inverts the meaning of the statement:
You don’t run into this problem when you use nouns to name properties because there’s never an inverse relationship from a literal to a resource that you need to name. You also won’t run into it for relations that have easily named inverses, such as parent/child or owner/possession although there is a similar confusion with the use of comparatives for relation names, as in SKOS, where the relation
skos:broader could mean:
In the Metalex ontology, on the other hand, the relationships are:
metalex:BibliographicWork -- metalex:realizedBy --> metalex:BibliographicExpression
metalex:BibliographicExpression -- metalex:realizes --> metalex:BibliographicWork
metalex:BibliographicExpression -- metalex:embodiedBy --> metalex:BibliographicManifestation
metalex:BibliographicManifestation -- metalex:embodies --> metalex:BibliographicExpression
Here, the relationships are verbs, leading you to read sentences in the form “subject [is] predicate object”:
The only weirdness here is having to add “is” before some predicates but not others.
The tradition in AI is to use verbs everywhere. Instead of
dc:title, you would have
dc:hasTitle. Doing this for properties with literal values seems unnecessarily verbose, but for relations I think it’s a good rule of thumb in order to disambiguate the direction of the relation.