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
<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 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: 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 |
--------------------------------------------------------------
