Dear Philippe,
Thank you for the interesting discussion.
Here is my understanding: (note: I was not involved when the PCs were
first introduced)
On Tue, Apr 5, 2022 at 9:52 PM Philippe Michon via Crm-sig
<crm-sig@ics.forth.gr> wrote:
Dear all,
I strongly second this proposal. In my opinion, there is a serious
lack of guidance as to how we are supposed to use .1 properties.
In my opinion, the management of PCs should not only be considered
in order to overcome a technological limit. I believe there is
some interesting semantics within PCs that would be worth
describing more formally.
If I'm not mistaken, .1s are only very briefly described in the
CRMbase specification. I quickly found only five snippets (I
didn't include the new proposals about .1 properties in 7.2.1):
1.
In the "Terminology" section under "property": " Properties
may themselves have properties that relate to other classes
(This feature is used in this model only in order to describe
dynamic subtyping of properties)."
2.
in the "About the logical expressions used in the CIDOC CRM":
"properties of properties, “ .1 properties” are named by
ternary predicate symbols; conventionally, we use P14.1 as the
ternary predicate symbol corresponding to property P14.1 in
the role of. "
3.
in the "Extensions of CIDOC CRM": "Existing properties can be
extended, either structurally as subproperties, or in some
cases, dynamically, using properties of properties which allow
subtyping (see section About Types below)."
4.
in "Specific Modelling Constructs" under "About Types":
"Analogous to the function of the P2 has type (is type of)
property, some properties in the CIDOC CRM are associated with
an additional property. These are numbered in the CIDOC CRM
documentation with a ‘.1’ extension. The range of these
properties of properties always falls under E55 Type. The
purpose of a property of a property is to provide an
alternative mechanism to specialize its domain property
through the use of property subtypes declared as instances of
E55 Type. They do not appear in the property hierarchy list
but are included as part of the property declarations and
referred to in the class declarations. For example, P62.1 mode
of depiction: E55 Type is associated with E24 Physical
Man-made Thing. P62 depicts (is depicted by): E1 CRM Entity"
5.
and in "CIDOC CRM Class Declarations": "Properties of
properties are provided indented and in parentheses beneath
their respective domain property."
My questions and comments:
1.
I believe it would be particularly important to clarify if it
is possible to use the .1 property of a superproperty with one
of its subproperties. For example, is it allowed to use
P3.1_has_note with P190_has_symbolic_content? According to my
understanding this is not possible, but I do not believe it is
explained anywhere. And if it is indeed possible, the PC
extension does not allow this semantics.
2.
Another issue is the fact that "PC0_Typed_CRM_Property" is not
part of the CRMbase class hierarchy. I can understand the
reasons behind this choice, but again these would need to be
defined. In the context of our work at CHIN, we would
sometimes have appreciated using a "P2_has_type" on a PC class
in order to type it more formally. Is this something the SIG
would encourage?
CIDOC-CRM is an ontology which can be implemented in different ways,
one of these being RDF (the main one). However, RDF does not support a
direct way to express properties of properties (one important
limitation), so the PCs just provide a way to enable their
representation and querying. So, as I see it, PC0_Typed_CRM_Property
must not be part of the official documentation since it has to do with
the implementation of the model in a particular language / data model
(and is also out of the universe of crm's discourse).
Using 'P2 has type' for a PC seems strange (but interesting) to me,
because the .1 properties are actually used for providing such a type
to a property. Could you please give a particular example?
1.
There is also an issue with P67_refers_to and P138_represents.
The last is a subproperty of the first and both have a .1
property. In the PC extension, this hierarchy is completely
lost, which limits the possibilities of inference. I don't
know how to manage this according to CRMpc, but this problem
should at least be documented if there is no concrete
solution. I don't believe identifying PC138_represents as a
subclass of PC67_refers_to would completely resolve this
issue. Moreover, this representation would again raise the
question concerning the inheritance of .1 properties by
subproperties.
As I see it, we cannot have the PC class of a property in a dataset
without also having the actual property (since we want to assign a
triple to that property). So, inference can be done using the actual
properties and their subproperty relation, not the PCs which are just
used for enabling the representation and querying of a property of
property.
Do you have in mind a particular reasoning scenario which requires
clear semantics between the PC classes and not the properties?
1.
In the same vein, the question of the relationship that exists
between the structure of PCs and their corresponding CRMbase
properties is not explicit. If a user wants to implement
P67_refers_to and PC67_refers_to in their knowledge graph, how
should they implement the whole thing? Should the ontology
support this kind of inference (in the RDF), or should it be
handled at the query level?
Not sure I understand the question correctly. To my understanding, PCs
just provide syntactic sugar for representing properties of
properties. They are used in parallel with the corresponding
properties when we want to express a property of property. So, it
seems to be a problem/task of data generation or/and data querying.
E.g., an example of a dataset:
:visual_item1 crm:P67_refers_to :e1
:PC67_inst1 a crm:PC67_refers_to ;
crm:P01_has_domain :visual_item1 ;
crm:P02_has_range :e1 ;
crm:P67.1_has_type <my type> .
and an example of a query for getting the references of visual items
and their type:
SELECT ?visual_item ?reference ?type WHERE {
?visual_item crm:P67_refers_to :reference .
?x crm:P01_has_domain ?visual_item ;
crm:P02_has_range ?reference ;
crm:P67.1_has_type ?type }
Do you have in mind a particular inference scenario that requires
clear semantics between :P67_refers_to and instances of
crm:PC67_refers_to? (I think one will have to implement their own
reasoner even if clear semantics are added).
1.
I also believe that it would be important to standardize the
names of the PC entities. For example, why are the first
letters of "PC0_Typed_CRM_Property" capitalized while other
classes are not (eg. PC3_has_note)?
A possible explanation: The first letters of the property classes are
not capitalized because the first letters of the corresponding CRM
properties are not capitalized (contrary to the CRM classes whose
words are capitalized).
1.
Now that we formalize the .1 properties, I think it would be
more than necessary to have an official scope note for each of
them. The vast majority are only very poorly documented in the
scope note of their respective property. It is also important
to mention that "PC0_Typed_CRM_Property", "P01_has_domain",
and "P02_has_range" don't have a scope note at all.
I agree. Descriptions are needed within the RDF file, as well as a
clear example on how one can use them when creating or querying a
dataset.
Best regards,
Pavlos
1.
It is also difficult to easily find all the information about
.1 properties. Would it be useful to have a dedicated section
for them in the introduction?
Best,
Philippe
Le jeu. 24 mars 2022 à 08:51, Martin Doerr via Crm-sig
<crm-sig@ics.forth.gr> a écrit :
I think this is a good idea!
Martin
On 3/24/2022 1:23 PM, Pavlos Fafalios via Crm-sig wrote:
Dear George, all,
The new version of PC classes file (for CRMbase version
7.1.1) has been already produced (as discussed in the last
meeting) and will be soon available through the crm website
(see issue 567
<https://cidoc-crm.org/Issue/ID-567-module-for-pc-properties>).
Thinking of it again:
Since the namespace for the PC classes is the same with that
of the base classes/properties, why not including them
directly within the base RDFS? (i.e. providing at the end a
single rdfs file that also includes the PCs).
Properties of properties are part of the official
documentation (of the base model, or of an extension), so why
not including the corresponding PC classes in the same RDFS
file instead of providing and maintaining a second file?
(this applies for both the base model and the extensions)
This is just a suggestion without knowing any discussions, or
decisions made, when implementing the PC classes for the
first time several years ago (there might be a good reason
for having a second file...).
Best regards,
Pavlos
On Thu, Mar 24, 2022 at 11:41 AM George Bruseker via Crm-sig
<crm-sig@ics.forth.gr> wrote:
Dear all,
Subsequent to another thread I started here I am
proposing that there be a conversation about having a
standard policy and method for creating, documenting and
making available the .1 properties for base and its
extensions in the RDF serialization. At present to my
knowledge the PC classes are only available for CRMBase
and relative to version 6.2.1. Other extensions however
also use .1 constructions and, moreover, CRMbase moves
forward and its PC classes should hypothetically move
with it. Therefore, I propose we discuss, create and
implement a common policy for creating this rdf
derivative to support rdf implementations that adopt the
.1 constructions.
Best,
George
_______________________________________________
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig
--
Pavlos Fafalios
Postdoctoral researcher (Marie Curie IF - Project ReKnow
<https://reknow.ics.forth.gr/>)
Centre for Cultural Informatics & Information Systems Laboratory
Institute of Computer Science - FORTH
and
Visiting Lecturer
Department of Management Science & Technology
Hellenic Mediterranean University
Address: N. Plastira 100, Vassilika Vouton, 70013 Heraklion,
Greece
Email: fafal...@ics.forth.gr
Tel: +30-2810-391619
Web: http://users.ics.forth.gr/~fafalios/
_______________________________________________
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig
--
------------------------------------
Dr. Martin Doerr
Honorary Head of the
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
Vox:+30(2810)391625
Email:mar...@ics.forth.gr
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
--
*Philippe Michon*
(he/il – https://name.pn/philippe-michon
<https://name.pn/philippe-michon>)**
Semantic Web Analyst
Canadian Heritage Information Network (CHIN)
Department of Canadian Heritage, Government of Canada
1030 Innes Road, Ottawa (Ontario) K1B 4S7
philippe.mic...@canada.ca
illipm...@gmail.com
Tel: 613-998-3721 ext. 225 or 1-800-520-2446
Analyste en web sémantique
Réseau canadien d'information sur le patrimoine (RCIP)
Ministère du Patrimoine canadien, Gouvernement du Canada
1030 chemin Innes, Ottawa (Ontario), K1B 4S7
philippe.mic...@canada.ca
illipm...@gmail.com
Tél. : 613-998-3721 poste 225 ou 1-800-520-2446
_______________________________________________
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig
--
Pavlos Fafalios
Postdoctoral researcher (Marie Curie IF - Project ReKnow
<https://reknow.ics.forth.gr/>)
Centre for Cultural Informatics & Information Systems Laboratory
Institute of Computer Science - FORTH
and
Visiting Lecturer
Department of Management Science & Technology
Hellenic Mediterranean University
Address: N. Plastira 100, Vassilika Vouton, 70013 Heraklion, Greece
Email: fafal...@ics.forth.gr
Tel: +30-2810-391619
Web: http://users.ics.forth.gr/~fafalios/
