Hi Martin, The problem to solve is, how do you find who said that .1 anything?
This is often where the true scholarly interest is. It is a matter for aliens and economists to count how many people were involved in carrying out actions in a knowledge graph (the pure empirical picture). Actually, we want to do who did what in what capacity. We want to know what referenced what in what capacity. So the information represented in the .1 isn't a fun additional node, it is the vital piece of information that makes the graph interesting in the first place. > 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? > The point is that they are not. Load up 3M and try to do an E13 reification on a PC property class. You cannot. Because E13 points to an instance of E1 and PCs are not (by accident I suspect, this has never been formally discussed to my knowledge) not declared as a subclass of E1. So when the scholarly questions are, what role did X play in Y, what manner did Z reference P, and who said that, then the thing that is of interest to be questioned / contested / understood is the property on the property which cannot be referenced. So the problem is to make CRM useful for scholarly documentation and argumentation! > > 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 > It cannot be used on a PC class because of the issue that is the issue that I raised in this issue (it is not a subclass of E1). > > 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. > We already model properties also as classes not only in PC but quite explicitly in P177 where we expected instances of E55 to be properties... > > > 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?😁 > I did give an example! I drew a picture to help out. Here it is in draw.io: https://drive.google.com/file/d/1Qat9TCxEBxCzylEdKkwjdnpHF3HCiiM-/view?usp=sharing It is on two tabs. Tab one shows how we can say things about the relation of an actor to an event as being responsible. Tab two shows how we can say things about the role of an actor in an event. You cannot do a reference to the PC class, hence you cannot talk about it. (or put down the reference that grounds it or do any other scholarly activity related to it... although the language otherwise lets use sort of make a statement regarding role). Cheers, George > > 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 >>> listCrm-sig@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: 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 >
_______________________________________________ Crm-sig mailing list Crm-sig@ics.forth.gr http://lists.ics.forth.gr/mailman/listinfo/crm-sig
