Dear Martin I'm not sure what you meant by "partially declared subproperties" there (the ambiguity of the term "subproperty" in this discussion doesn't help). I think I understood the rest of what you were saying, though.
To be clear, all I was saying was that I would prefer not to publish RDF that directly uses those generic RDF predicates P01_has_domain and P02_has_range, but instead to use a set of more specific predicates (which could be defined to be (RDFS) subproperties of those two predicates). So each distinct type of CRM property which had been reified as an RDFS class (e.g. PC14_carried_out_by) would have its own pair of RDF properties for linking to instances of its domain and range. My rationale for that preference is that it would be more meaningful to users to make use of an RDF predicate called Pxxx_has_actor (with a domain of PC14_carried_out_by and a range of E39_Actor) and Pxxx_has_activity (with domain PC14_carried_out_by and range E7_Activity), rather than using generic predicates P01_has_domain and P02_has_range. Plus it would give us more type-safety. It would be a trivial extension to that existing RDFS to add those extra RDFS subproperties (about 60 of them, including the inverses). Regards Conal On 15 March 2018 at 20:37, Martin Doerr <mar...@ics.forth.gr> wrote: > Dear Conal, > > There is no conflict with adding subproperties. Once we have defined in > FOL the logic of properties of properties, each PC class implies its base > property. Hence, logically, the subproperty and any added ".1" will hold > for the instances declared and imply the same base property. If, at any > time we wish to connect term hierarchies of roles for the .1 properties > with partially declared subproperties, we need a straight-forward extension > of the CRM. Any subproperty, e.g., may refine domain and range. > > All the best, > > Martin > > > On 3/15/2018 6:28 AM, Conal Tuohy wrote: > > 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 <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 | > -------------------------------------------------------------- > > > _______________________________________________ > Crm-sig mailing list > Crm-sig@ics.forth.gr > http://lists.ics.forth.gr/mailman/listinfo/crm-sig > > -- Conal Tuohy http://conaltuohy.com/ @conal_tuohy +61-466-324297
