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
<mailto:mar...@ics.forth.gr>> wrote:
Dear All,
Please
see:http://www.cidoc-crm.org/sites/default/files/CRMpc_v1.1_0.rdfs
<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
<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 <mailto: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
<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 <tel:0466%20324%20297>
--
--------------------------------------------------------------
Dr. Martin Doerr | Vox:+30(2810)391625 |
Research Director | Fax:+30(2810)391638 |
| Email:mar...@ics.forth.gr
<mailto: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
--
--------------------------------------------------------------
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 |
--------------------------------------------------------------
