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

Pavlos Fafalios fafalios at ics.forth.gr
Thu Apr 7 17:59:37 EEST 2022


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 listCrm-sig at ics.forth.grhttp://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)
>
>
> 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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ics.forth.gr/pipermail/crm-sig/attachments/20220407/f2f6ffc5/attachment-0001.html>


More information about the Crm-sig mailing list