Thanks Martin, for the link to http://www.cidoc-crm.org/sites/default/files/CRMpc_v1.1_0.rdfs
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!) http://www.cidoc-crm.org/Issue/ID-266-reified-association-vs-sub-event is 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 RDFS: http://www.cidoc-crm.org/sites/default/files/20160802PropertiesOfProperties.pptx 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. Conal On 15 March 2018 at 04:25, Martin Doerr <mar...@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 > references). > > Best, > > martin > > > On 3/14/2018 12:49 PM, Conal Tuohy wrote: > > > > On 8 March 2018 at 18:02, Richard Light <rich...@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 <0466%20324%20297> > > > -- > -------------------------------------------------------------- > Dr. Martin Doerr | Vox:+30(2810)391625 | > Research Director | Fax:+30(2810)391638 | > | Email: mar...@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 | > -------------------------------------------------------------- > > -- Conal Tuohy http://conaltuohy.com/ @conal_tuohy +61-466-324297
