Re: [Crm-sig] ISSUE 588 Implementing the .1 Properties of Base and Extensions in RDF

Tue, 09 May 2023 12:32:26 -0700 

Dear Martin, Pavlos, All,
I think these are definitely important questions that deserve more thorough discussion and consideration in future. 


Apart from the "technical" reification issue, I agree with you, Martin, 
that the "ontological or epistemic (reification!) of n-ary relations" is 
central, and that PC classes are partly an attempt to cope with n-ary 
situations (of different substance and relevance), and partly a way to 
provide a specialisation of properties, as you write in point b), with a 
solution based on vocabularies of types.



The issue raised last year by Mark Fichtner and, on a more fundamental 
level, by myself in this regard, is that of the unclear distinction we 
now could have in some cases between the 'technical' and ontological 
levels, between the PC declared only in the RDF serialisation (but quite 
relevant as we saw in the appellation/language issue) and the classes 
precisely conceptualised in the reference conceptual model (the true 
ontology).



This issue appears more in general if we observe what happens in the 
semantic web context, were we meet, as we know, property driven, 
statement driven and event driven approaches.



The first one is implemented in DBPedia, where, besides a new approach 
in the DBPedia ontology to add temporal entity classes, all the 
information is expressed with RDF properties, without the possibility of 
adding temporal or other qualifications to them. There's a 
dbo:birthPlace and dbo:birthDate property with no explicit link to a 
birth event.



To overcome this problem and limitation, Wikidata has developed a 
different approach based on statements instead of properties: you can 
add to each statement not only sources and alternatives, but also rich 
elements such as dates, roles and types. Take, for example, the case of 
the "position held" property 
(https://www.wikidata.org/wiki/Property:P39): for the position of a 
bishop as a target, you can add to the statement the diocese and the 
time period, cf. https://www.wikidata.org/wiki/Q948226.



This example raises the questions mentioned in Martin's mail and in our 
discussions over the last few years on these issues: what is the 
substance of this n-ary relation "position held"? and of its temporality 
as real phenomenon? is it only epistemic or substantial? etc. etc.



The CRM, with its "temporal entity centered" approach, provides a more 
robust solution to the n-arity and temporality issues, where you can 
make explicit the complexity of the information and the ontological 
analysis that underpins the ontology.



The problem remains for cases where information is available that goes 
beyond simple properties or assertions, such as the participation of a 
person in an event with a certain role, for example in a private 
capacity or as a minister. One might be tempted to follow the Wikidata 
statement approach and add official or unofficial P .1 to the 'P11 had 
participant' property, to express roles, dates, types of participation, 
and so on.



For the sake of interoperability and reusability of data, and the 
general methodology we are following, I would definitely advocate 
considering adding, e.g., a well thought out 'Participation' class, in 
CRMbase or an appropriate extension, instead of using 'technical' PC 
classes or RDF reification for this or similar cases. The same applies 
to properties like P14, P107 and possibly (in private project 
extensions) P49, P51, P53 etc.



So I'd definitely be in favour of having an issue on this more general 
and fundamental question.


All the best

Francesco





Le 04.05.23 à 17:30, Martin Doerr via Crm-sig a écrit :

Dear Francesco, All,


I support this new issue. The discussion about the .1 properties had 
been very long, but the reasoning is, as for many solutions the CRM 
offers, widely lost. New methods arise, as the reification construct.



I just want to remind, that the issue splits into a set of 
considerations that need to be answered:



a) the ontological or epistemic (reification!) of n-ary relations, 
which may differ widely between the one or the other PC class. This is 
intellectually very interesting.



b) the question of dynamic  vocabularies for specializing CRM concepts 
without class-property bindings: I.e., The equivalent of "p2 has type" 
for properties, which could also be solved (but hardly taken up by 
users) by local subproperty declarations.



c) The performance in real large scale implementations. Current graph 
databases and quad stores still pay a high penalty for intermediate 
nodes. This needs real bench marking, not just opinions. If deductions 
over PC classes need, in practice, to be materialized, there is no 
advantage over local subproperties, which are performant.



d) Relevance: what are the research needs for querying large knowledge 
bases in which better ontological representation of PC classes will 
make the difference justifying the intellectual effort.



I suggest as a first step to solve a), without taking decisions about 
new constructs. I assume that a /certain part /of the .1 properties 
are of "reification" nature, whereas /another part/ is of hidden 
processes, and /another part/ is vocabularies of roles, such as 
"carried out by".



I assume replacing PC classes by reification would not work for 
deducing the base property, if this is relevant.



Another aspect is, that computer science and has so far failed to 
provide an effective mechanism to specialize models by replacing links 
by paths, comparable to the IsA.


All the best,

Martin

On 5/3/2023 12:05 AM, Pavlos Fafalios via Crm-sig wrote:

Dear Francesco,


You have raised some interesting points which, I think, need 
discussion (but after closing this issue 😃), including:

- what was the motivation of introducing property classes
- how can we tackle ambiguity of PCs (classes vs properties, etc etc)

- why not directly using the standard RDF reification vocabulary 
<https://www.w3.org/TR/rdf-schema/#ch_reificationvocab>, where 
properties can be attached to statements/triples.
I will include your comments in the working document of Issue 588, 
with a suggestion to open a new issue for discussing and working on 
them.


Best regards,
Pavlos



On Tue, Dec 6, 2022 at 8:39 PM Francesco Beretta via Crm-sig 
<[email protected]> wrote:


    Dear Pavlos, all

    reconsidering this question of the properties of properties and
    the proposed solution of the properties-classes remain some
    doubts and interrogations to me, in particular in relation with
    the best practices in the field of serialization of conceptual
    models in RDF.

    Metadata about properties as instances, i.e. statement, can be
    expressed with the standard RDF reification or the new RDF*
    standard.

    What is the best practice in the RDF community to express this
    kind of properties of properties (and also dates, etc. added to
    properties in conceptual models) ?


    And furthermore: are the CRM properties of properties just
    'metadata' or do they carry some additional ontological substance ?

    The technical solution of 'PC' does not remove all ambiguity: are
    they in the end properties or classes? and when we talk about
    adding, as now, labels and scope notes to the PCs they do becomes
    classes, don't they? what is then their substance? just to be
    reified properties?

    One could come to think that in fact there is more substance but
    not totally and adequately expressed, and that should be more
    carefully analyzed like in the case of P14.1 in the role of: E55
    Type or P107.1 kind of member: E55 Type.

    Take the example of  P3.1 has type: E55 Type — "This property
    allows differentiation of specific notes, e.g., “construction”,
    “decoration” etc." (thank you Pavlos for the work you've done).

    If P3 is not just taken as a CRM replacement of /rdfs:comment/,
    shouldn't the so called associated 'note' be modelled as an
    information object of type 'damage description' (chipped at edge
    of handle) related to the corresponding human-made object by P129
    is about. Or 'chipped at edge of handle' would be a E3 Condition
    or State and the 'note' its description?

    But because P3 has E62 String as a range, which "is not further
    elaborated upon within the model", it becomes —P3 I mean— quite
    relevant as it captures the characterization of the item itself,
    its internal structures, appearance etc.

    So, again, are there any best practices in other communities of
    RDF experts that apply to these types of situations that should
    be analyzed before further specifying a notion of PC that doesn't
    seem totally justified, or raising ontological analisis issues,
    instead of using simple RDF reification?

    Best

    Francesco

    Le 01.12.22 à 17:35, Pavlos Fafalios via Crm-sig a écrit :

    Dear all,

    Please find my revised homework for issue 588
    
<https://cidoc-crm.org/Issue/ID-588-common-policy-method-for-implementing-the-.1-properties-of-base-and-extensions-in-rdf>
    below:
    
https://drive.google.com/drive/folders/1b0wW70xo2wjxNlWHYDRl7nr-fzYXTchN?usp=share_link

    Feel free to add your comments or send your feedback!

    Best regards,
    Pavlos

    On Tue, Sep 13, 2022 at 11:23 AM Pavlos Fafalios
    <[email protected]> wrote:

        Dear Mark, all,

        I agree, we need to make clear which constructs of the RDF
        are not part of CIDOC-CRM (especially since they make use of
        the same namespace).
        One way is to add a note in the beginning of the file.
        Another way would be to provide them through a different
        namespace (not sure if this is a good solution--needs some
        thinking).

        This is also a good reason for having them in a different
        RDF file:  all classes and properties in this file, except
        the .1 properties, are not part of CIDOC-CRM, while the .1
        properties have a 'domain' class that is also not part of
        CIDOC-CRM.

        Best,
        Pavlos

        On Mon, Sep 12, 2022 at 5:53 PM Mark Fichtner
        <[email protected]> wrote:

            Dear all,

            nice work, thanks! I think for RDF this is a valid
            representation, although I am not very happy to add
            properties that are not in the cidoc crm directly and
            that are not part of the language itself (like in this
            case crm:P03_reifies). As a user/reader of the rdf it is
            simply hard to understand what is part of the cidoc crm
            itself and what comes due to "workarounds". Even in as a
            new ontology/file/addon it mixes cidoc crm and non-cidoc
            crm things.

            Also we have a reification concept (E13 Attribute
            Assignment), I am not sure if we need even more of these.

            I'm looking forward to the discussion!

            Best,

            Mark Fichtner

            Germanisches Nationalmuseum

            Am Mo., 12. Sept. 2022 um 14:22 Uhr schrieb Pavlos
            Fafalios via Crm-sig <[email protected]>:

                Dear all,

                Please find my homework for issue 588
                
<https://cidoc-crm.org/Issue/ID-588-common-policy-method-for-implementing-the-.1-properties-of-base-and-extensions-in-rdf>
                in the below link (as well as in the issues' folder):

                
https://docs.google.com/document/d/1oQRkmMUgyOeDsn3ZbPuQ__VtbigS9DVsHjmOtvx16uo/edit?usp=sharing

                Apologies for the delay! Feel free to add your
                comments or send your feedback!

                Best regards,
                Pavlos



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

                Visiting Lecturer
                Department of Management Science & Technology
                Hellenic Mediterranean University

                Web: http://users.ics.forth.gr/~fafalios/
                Email: [email protected]
                Address: N. Plastira 100, Vassilika Vouton, 70013
                Heraklion, Greece
                Tel: +30-2810-391619

                _______________________________________________
                Crm-sig mailing list
                [email protected]
                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

        Visiting Lecturer
        Department of Management Science & Technology
        Hellenic Mediterranean University

        Web: http://users.ics.forth.gr/~fafalios/
        Email: [email protected]
        Address: N. Plastira 100, Vassilika Vouton, 70013 Heraklion,
        Greece
        Tel: +30-2810-391619




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

    Visiting Lecturer
    Department of Management Science & Technology
    Hellenic Mediterranean University

    Web: http://users.ics.forth.gr/~fafalios/
    Email: [email protected]
    Address: N. Plastira 100, Vassilika Vouton, 70013 Heraklion, Greece
    Tel: +30-2810-391619


    _______________________________________________
    Crm-sig mailing list
    [email protected]
    http://lists.ics.forth.gr/mailman/listinfo/crm-sig


    _______________________________________________
    Crm-sig mailing list
    [email protected]
    http://lists.ics.forth.gr/mailman/listinfo/crm-sig



--
Pavlos Fafalios

Postdoctoral researcher
Centre for Cultural Informatics & Information Systems Laboratory
Institute of Computer Science - FORTH

Visiting Lecturer
Department of Management Science & Technology
Hellenic Mediterranean University

Web: http://users.ics.forth.gr/~fafalios/
Email: [email protected]
Address: N. Plastira 100, Vassilika Vouton, 70013 Heraklion, Greece
Tel: +30-2810-391619


_______________________________________________
Crm-sig mailing list
[email protected]
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:[email protected]   
  Web-site:http://www.ics.forth.gr/isl


_______________________________________________
Crm-sig mailing list
[email protected]
http://lists.ics.forth.gr/mailman/listinfo/crm-sig

_______________________________________________
Crm-sig mailing list
[email protected]
http://lists.ics.forth.gr/mailman/listinfo/crm-sig






















					Reply via email to