[Crm-sig] Properties of properties in RDF
conal.tuohy at gmail.com
Thu Mar 15 06:28:24 EET 2018
Thanks Martin, for the link to
This is actually very close to (and compatible with) the approach I
suggested in my earlier email, and I'm embarrassed to say I wasn't aware of
it at all.
I've managed to find some background material (though I had to use Google
to find it!)
an archive of a relevant discussion.
http://www.cidoc-crm.org/sites/default/files/Roles.pdf presents a few
slides showing options for modelling properties of properties, including
the "Property Class" approach.
These slides include a nice illustration of the approach defined in the
I think I'd be very happy with this "Property Class" approach, although
rather than using the generic properties P01_has_domain, P02_has_range, and
their inverses,I would still want to define specific subproperties, e.g.
for the case of actors playing a specific role in the performance of an
activity, I would prefer to link the performance (i.e. the instance of PC14
carried out by) to the actor and the activity using domain-specific
properties such as has_actor and has_activity.
On 15 March 2018 at 04:25, Martin Doerr <martin at ics.forth.gr> wrote:
> Dear All,
> Please see:http://www.cidoc-crm.org/sites/default/files/CRMpc_v1.1_0.rdfs
> on page http://www.cidoc-crm.org/versions-of-the-cidoc-crm, plus the
> issues discussing the solution for version 6.2 (I'll look for all
> On 3/14/2018 12:49 PM, Conal Tuohy wrote:
> 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
> +61-466-324297 <0466%20324%20297>
> Dr. Martin Doerr | Vox:+30(2810)391625 |
> Research Director | Fax:+30(2810)391638 |
> | Email: martin at ics.forth.gr |
> Center for Cultural Informatics |
> Information Systems Laboratory |
> Institute of Computer Science |
> Foundation for Research and Technology - Hellas (FORTH) |
> N.Plastira 100, Vassilika Vouton, |
> GR70013 Heraklion,Crete,Greece |
> Web-site: http://www.ics.forth.gr/isl |
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Crm-sig