[Crm-sig] New Issue: Common Policy / Method for Implementing the .1 Properties of Base and Extensions in RDF

Martin Doerr martin at ics.forth.gr
Thu Apr 7 20:20:12 EEST 2022


Dear Philippe, all,

I agree with Pavlos' explanations.

The PC classes are not an ontological construct. They are not CRM 
Entities, and therefore P2_has_type does not apply. I do not think Scope 
Notes in the sense we use in the CRM are required for 
PC0_Typed_CRM_Property", "P01_has_domain", and "P02_has_range". We need 
just logical definitions, and use guidelines. We use "scope notes" to 
make the connection between logical ontological constructs and the 
users' cognitive anticipation of reality. I'd prefer to add a textual 
"*Definition*". They are exclusively implementation constructs for 
simulating ternary relations in RDF. Some other KR languages can 
represent them properly. Therefore, any individual definition should be 
a "mechanical" product of the overall definition of the PC class 
construct and the scope note part of the .1 property in the CRM.

I'd agree that scope note parts for .1 properties may be better, more 
clearly marked in the CRM Definition.

The question of .1 property inheritance is interesting. I think it is 
just a question of the reasoning rules with the PC classes to define the 
inheritance.  In general, I maintain a kind of equivalence of 
subproperties with .1 properties describing a type, as we do for classes 
and P2 has type, and I think this is clearly explained in the 
Introduction Section "About Types". If this needs more or better 
wording, this is a particular issue to be discussed.

I agree that this equivalence and inheritance need to be examined formally.

All the best,

Martin

On 4/7/2022 5:59 PM, Pavlos Fafalios wrote:
> 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 at 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 at 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 at 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 at 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: fafalios at ics.forth.gr
>>         Tel: +30-2810-391619
>>         Web: http://users.ics.forth.gr/~fafalios/
>>
>>
>>         _______________________________________________
>>         Crm-sig mailing list
>>         Crm-sig at 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:martin at ics.forth.gr   
>           Web-site:http://www.ics.forth.gr/isl
>
>         _______________________________________________
>         Crm-sig mailing list
>         Crm-sig at 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.Michon at canada.ca
>
>     illipmich at 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.Michon at canada.ca
>
>     illipmich at gmail.com
>     Tél. : 613-998-3721 poste 225 ou 1-800-520-2446
>
>     _______________________________________________
>     Crm-sig mailing list
>     Crm-sig at 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: fafalios at ics.forth.gr
> Tel: +30-2810-391619
> Web: http://users.ics.forth.gr/~fafalios/
>


-- 
------------------------------------
  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:martin at ics.forth.gr   
  Web-site:http://www.ics.forth.gr/isl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ics.forth.gr/pipermail/crm-sig/attachments/20220407/9a6f8a54/attachment-0001.html>


More information about the Crm-sig mailing list