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 <http://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 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
