Hi George,

On 5/8/2023 5:34 PM, George Bruseker wrote:
Hi Rob and Martin,

But the point is not to make assertions about the property class itself but the instance of the property class.
of course😁

The instance of PC14 says Bob was the creator, Bob was a faker... it is a regular abox assertion. And it has an identifier, necessarily.

The instances of PC classes are all already abox statements. They have just been modelled in an odd way where we don't account for their ontological substance. Being in a role is an ontological substance to define.
Yes, we have discussed that in the past and in the OntoWeb project. There are 3 kinds of roles. This is the "incidental role". There was a classical paper about that. I'll search for it. Another role is the life-long role. A third one is the "persona" or "office" role.

The point I made is the difference between ontological substance of individuals versus that of relations, and the epistemic substance of arguing about the world from a bird's perspective. I did not question the substance of roles, but their nature as "entities" or "individuals" in the narrower sense.

For me it is a big problem if there are statements in the CRM that can be made (Bob was the builder) but can't be discussed. The abox statement Bob was the builder is definitely in the domain of discourse and for that reason should necessarily as a matter of principle be referenceable.
I do not get the point. All statements, property instances, are referenceable, by reification, Named Graphs, A13. Bob being in the role of builder for that Activity can be formalized as specialication of the P14 carried out by. What problem do you try to solve?

Otherwise, CRMbase cannot state the provenance for a piece of knowledge like Da Vinci had the role of painter of Mona Lisa. It becomes impossible. The abox information is in the PC14 instance.
Why not? Provenance of knowledge is an epistemic layer on top of any KB. We have written in the introduction detailed explanations about that. Reification

Yes we can use the partitioning pattern which is fine, but it remains a question of technically what to do about PC classes and it seems only half baked if they aren't instances of E1. They fit the definition of instances of E1, "This class comprises all things in the universe of discourse of the CIDOC Conceptual Reference Model." Being in the role of the painter of Mona Lisa is, for me, a thing in the universe of discourse of the CIDOC Conceptual Reference Model.
Well, then we have to refine the term "thing". Clearly, E1 is used exclusively for individual entities. We did not model so far a "CRM relation", in order to avoid that people instantiate an unqualified relation.

Logically, I do not get the point why making PC classes instances of E1 does solve a problem, which reification, Named Graphs and E13 already do?  I mean, should we make an example? Could you be more specific why the latter 3 mechanisms do not work for any CRM property and .1 property?😁

Best,

Martin

The main thing is this is a technical extension to a technical extension to make things work and isn't a real ontological question to my mind.

If we wanted to do the ontological discussions we would have to open up the modelling box of worms, which is definitely another issue. I, for example, would like to be able to talk about the timespan of the property of something being part of something... but that's a broader issue :)

G

On Mon, May 8, 2023 at 5:21 PM Robert Sanderson via Crm-sig <crm-sig@ics.forth.gr> wrote:


    Perhaps for the first time, I agree with Martin and not George!

    The PC classes are part of the ontological layer -- we don't say
    that classes or properties are descendants of E1. Or PC classes
    are T box (terminology) and not A box (assertions using that
    terminology).
    (See - https://en.wikipedia.org/wiki/Abox)

    I can see, however, that it would be useful to be able to refer to
    assertions in CRMInf and perhaps in Activity templates ... but
    then those assertions _are_ A box - the are the subject of the
    discourse, not the language in which the discourse is taking
    place.  We have Attribute Assignment to talk about important
    activities that assert relationships or properties. And if we
    don't want to go to that layer of A box layer reification, then we
    have the partitioning pattern -- to assert a role of a particular
    individual in an activity, we can identify the part of that
    activity that the person carried out and assert a role
    classification on it via P2_has_type.

    Rob


    On Mon, May 8, 2023 at 9:44 AM Martin Doerr via Crm-sig
    <crm-sig@ics.forth.gr> wrote:

        Dear All,

        I don't think it is correct to make the PC classes entities.
        Even though formally an RDF class could be regarded as an
        entity, ontologically we distinguish entities and
        relationships. The E-R paradigm makes this distinction also
        formally clear. We model the properties with .1 properties in
        FOL as n-ary relationships, and not as individuals.

        Making the PC classes CRM Entities is inconsistent with the
        FOL definition, which is the proper formalization.
        In other words, we would make a workaround for a missing
        feature in RDFS an ontological argument. We are again in the
        discussion to take RDFS as the definition of the CRM, and not
        as an implementation.

        As a first step, we could introduce an "E0 CRM Relation",
        which would have as instances all properties and the PC
        classes. The ontological distinction between relations and
        entities is fundamental to the methodology of ontological
        analysis.

        As a second step, we can start to investigate to which degree
        PC classes qualify as ontological individuals in their own
        right. If we start declaring a priori all PC classes as
        entities, we have later to justify and remove all those that
        are relations in the true sense.  For instance, I cannot
        imagine the "being part of" a Physical Object for some time to
        become an entity, because it needs a timespan.

        Best,

        Martin

        On 5/8/2023 12:54 PM, George Bruseker via Crm-sig wrote:
        Hi all,

        I would argue that the safest thing to do is to make the PCs
        a subclass of E1 and then see where we go from there. I agree
        with Martin that it can't be an information object (because
        everything would be then) but I imagine we would have a
        debate about what each .1 actually ontologically is. What is
        certain is that by virtue of the fact of being something said
        in the universe of CIDOC CRM it is something sayable /
        mentionable. This is what E1 gives us, the most vague point
        of an object that can be pointed to and named, possibly
        classified. The problem is right now that we have something
        that is sayable in CIDOC CRM (PCxxx) but it is not
        referenceable. But this is a logical contradiction.
        Everything that can be said can be referenced and PCxxx can
        definitely be said.

        For example, if I say that Bob was involved in the Production
        of Mona Lisa as Creator then this is something said / stated
        that is important, that has a real world referent, which has
        a definite meaning which is true or false etc. Ergo, it
        requires provenance. The basic mechanism for provenance in
        CRMbase is E13 and indicates that there was an agency behind
        something being asserted of something else.

        Here the thing we want to talk about is the role and the role
        IS an instance of PC14. It's already an instance of a class
        so it should be referenceable. (Also one might like to put a
        bibliography for people who thought that Bob was Creator of
        Mona Lisa etc.)

        So I would go exactly for Paulos' modelling but with this change:

        :painting_sistine_chapel
        crm:P01i_is_domain_of
        :role_of_michaelangeo_in_sistene_chapel_project

        :role_of_michaelangeo_in_sistene_chapel_project
           a crm:PC14_carried_out_by ;
           crm:P02_has_range :Michelangelo  ;
           crm:P14.1_in_the_role_of  :master_craftsman .
        :attrAssign1
           a crm:E13_Attribute_Assignment ;
           crm:P140_assigned_attribute_to
        :role_of_michaelangeo_in_sistene_chapel_project
           ... ... ...


        On Mon, May 8, 2023 at 10:42 AM athinak
        <athi...@ics.forth.gr> wrote:

            Dear George, all,

              I am not sure that the class PC0_Typed_CRM_Property
            should be a
            subclass of E1. In my understanding, this class implies a
            situation
            concluded in an epistemological context. I am also not
            sure if the
            provenance we are looking for in this set of statements
            is a kind of
            E13. I am just wondering.

            BRs,
            Athina


              On 2023-03-29 16:36, George Bruseker via Crm-sig wrote:
            > Dear all,
            >
            > When using the PC classes modelling structure we end up
            with a class
            > node for a property which we can then modify with
            things like 'kinds'
            > and 'modes' etc.
            >
            > Since such a statement has meaning and comes from
            somewhere [e.g.:
            > that someone did something in some capacity (PC14
            carried out by ...
            > P02 has range E39 + P14.1 in the role of E55)] one
            sometimes needs to
            > provenance this statement with an E13 attribute
            assignment. Ie we want
            > to ground who made this claim.
            >
            > In theory this would be done with E13 pointing to the
            node in the
            > typical fashion (p141, P140). However, the class
            > PC0_Typed_CRM_Property is not declared as a subtype of
            E1 CRM Entity
            > in the PC extension file. As a result we cannot do this.
            >
            > https://cidoc-crm.org/rdfs/7.1.1/CIDOC_CRM_v7.1.1_PC.rdfs
            >
            > I would argue PC0_Typed_CRM_Property should be declared
            a subclass of
            > E1_CRM_Entity.  Then it would be consistent with the
            rest of the
            > modelling.
            >
            > Opinions?
            >
            > Best,
            >
            > George
            > _______________________________________________
            > Crm-sig mailing list
            > Crm-sig@ics.forth.gr
            > http://lists.ics.forth.gr/mailman/listinfo/crm-sig


        _______________________________________________
        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



-- Rob Sanderson
    Senior Director for Digital Cultural Heritage
    Yale University
    _______________________________________________
    Crm-sig mailing list
    Crm-sig@ics.forth.gr
    http://lists.ics.forth.gr/mailman/listinfo/crm-sig



--
George Bruseker, PhD
Chief Executive Officer
Takin.solutions Ltd.
https://www.takin.solutions/


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

Reply via email to