Dear Conal,
Got it! Yes, subproperties of P01/P02 create an additional constraint,
which obviously must hold. The reasoning that the PC class expands the
equivalent property can only be modeled by an OWL rule.
For practical data entry, this should be hidden to the user by a tool,
which understands exactly the PC semantics. Otherwise the user will be
drowned under a hundred properties that only enforce obvious
constraints. This is why we hesitated to publish it in such an expanded
form.
I meant another issue: If the ".1" property declares a more specific
type, the relationship between free typing of the base property versus
creating subproperties of it should be better determined. Other
properties of properties do not create such problem.
Imagine a fully developed hierarchy of role terms for the P14, with
broader and narrower terms, such as "as designer" and "as architectural
sketcher", and then someone declaring a subproperty of P14 called
"designed by", but not "as architectural sketcher". Then, the
equivalence of "designed by" and "as designer" could be declared by
additional OWL rules, as well as that "as architectural sketcher",
because of being narrower term of "as designer", also implies "designed by".
But, even without and not so badly, at least when declaring for PC14 "as
designer", and when using "designed by", both declarations will result
in a P14 link. So, P14 provides the common recall, but not the precision.
You may understand, why for many years I suggested people to create and
share local subproperty vocabularies for the .1's, which saves a whole
reasoning engine in the background, but, admittedly, is not as flexible.
But, the problem is analogous to the P2 has type.
All the best,
Martin
On 3/15/2018 1:51 PM, Conal Tuohy wrote:
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
<mailto: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
<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
<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
<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
<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 <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 |
--------------------------------------------------------------
_______________________________________________
Crm-sig mailing list
Crm-sig@ics.forth.gr <mailto:Crm-sig@ics.forth.gr>
http://lists.ics.forth.gr/mailman/listinfo/crm-sig
<http://lists.ics.forth.gr/mailman/listinfo/crm-sig>
--
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 |
--------------------------------------------------------------
