[Crm-sig] Properties of properties in RDF

Martin Doerr martin at ics.forth.gr
Wed Mar 14 20:25:07 EET 2018


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 references).

Best,

martin

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 
> <mailto: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 schema.
>
>
>
>
> -- 
> Conal Tuohy
> http://conaltuohy.com/
> @conal_tuohy
> +61-466-324297


-- 
--------------------------------------------------------------
  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...
URL: <http://lists.ics.forth.gr/pipermail/crm-sig/attachments/20180314/17f10854/attachment.html>


More information about the Crm-sig mailing list