[Crm-sig] Properties of properties in RDF

Conal Tuohy conal.tuohy at gmail.com
Wed Mar 14 12:49:53 EET 2018

On 8 March 2018 at 18:02, Richard Light <richard at light.demon.co.uk> wrote:

> I was thinking last night that maybe we should focus our RDF efforts on
> exactly this issue: the representation of the CRM primitive classes E60,
> E61 and E62 in RDF.  The current RDF document is becoming quite
> wide-ranging in its scope, and (for example) you have questioned whether
> certain sections belong in it.  If we concentrate on this single aspect of
> the broader RDF issue, I think we can produce something which is of
> practical value relatively quickly.  In particular, I would like to devote
> time to this during the Lyon meeting.
I applaud the idea of focusing narrowly on something so as to produce some
of practical value quickly!

But I do hope that the other issues raised in that document will not be set
aside too long, or lost.

In particular, it seems to me that the mapping from the CRM's "properties
of properties" to RDF is actually a more serious gap.

In the CRM, there are a number of properties which are themselves the
domain of properties. In RDF, however, a property does not have properties
of its own. Incidentally, I remember years ago being able to model this
directly in ISO Topic Maps, but practical considerations of
interoperability and community dictate that RDF, despite its simpler model,
is the technology of choice today.

One example of the issue is how to model the role that individuals play in
events. If a concert performance X was P14 carried out by person Y, then
this maps naturally to an RDF triple in which the predicate is
crm:P14_carried_out_by. However, if the person carried out that activity in
a particular role (e.g. as a saxophonist) then things are more difficult.
In the CRM, the P14_carried_out_by itself has the property
P14.1_in_the_role_of, whose value could be an instance of E55_Type:
Saxophonist. This is pleasingly consistent with how the CRM handles
taxonomies in other parts of the model, but it is not workable in RDF
because the P14_carried_out_by property cannot itself have a property.

There are a number of "work-arounds" to this issue, such as simplying
ignoring the problem and "dumbing down" the data, or moving the locus of
classification from the property to the property value (e.g. in this case
that would mean classifying the person rather than their role; that doesn't
work very well because people may have many distinct roles, but it works
better for other cases).

The existing guidance would suggest defining a new "saxophone-played-by"
property to be a rdfs:subpropertyof P14_carried_out_by. This can certainly
work, but it's actually a poor expression of the CRM's model. It negates
the practical benefits of having external taxonomies for this kind of
classification. This guidance, in my opinion, makes too much of the
apparent similarity between the CRM's properties and RDF properties. They
are not in fact the same kind of thing, and a property which itself bears
properties is more closely approximated in RDF not as a property but
reified as a subject resource in its own right. A more faithful mapping of
the CRM's abstract model to RDF would introduce a new RDFS class
corresponding to the performance of the activity. We could then say that
concert performance X was P14a_performed_in Performance Z; that Performance
Z was P14b_carried_out_by person Y, and that Performance Z was
P14.1_in_the_role_of Saxophonist.

That's just one example of the general problem; there are a number of
others, which are listed here in the context of the Linked Art project:
https://github.com/linked-art/linked.art/issues/55 along with a variety of
options for dealing with the issue.

In my opinion the current situation with respect to properties of
properties (in RDF) is really quite unsatisfactory and could be
substantially improved by a more consistent treatment across the entire

Conal Tuohy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ics.forth.gr/pipermail/crm-sig/attachments/20180314/e62282c4/attachment-0001.html>

More information about the Crm-sig mailing list