Re: [Crm-sig] PC0_Typed_CRM_Property in CRMpc

[Martin Doerr via Crm-sig]

Got it!

So, the specific problem is to enable E13 to point to .1 properties.  
That appears to be a problem of E13, and possibly of 3M, isn't it? Could 
be solved by a more specific construct.


Best,

Martin

On 5/8/2023 9:14 PM, George Bruseker wrote:

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


Perhaps for 

Re: [Crm-sig] PC0_Typed_CRM_Property in CRMpc

[George Bruseker via Crm-sig]

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 

Re: [Crm-sig] PC0_Typed_CRM_Property in CRMpc

[Martin Doerr via Crm-sig]

Dear Christian-Emil,

On 5/8/2023 6:36 PM, Christian-Emil Smith Ore via Crm-sig wrote:


Hi all,

The E13 Attribute assignment construct does not create any formal 
connection between an instance of E13 and the  instance of the 
property  it documents. We have the property


P177 assigned property of type (is type of property assigned): E55 
Type.  It is no formal connection between this type and the property 
in question, however.



As far as I can se (which may be not very far) the FOL interpretation 
of CRM is, well, first order and we cannot quantify over predicates. 
In a second order logic this will be possible. Such a logic is 
undecidable, but may be part of it  it can be implemented by some 
constructs.


Yes, and the formalization of Named Graphs is still missing, because 
theoreticians try to solve simultaneously Named Graphs for models 
particulars and for models of universals. I wonder if even SOL has the 
epistemic semantics of "who says that. In the meanwhile, Quad stores 
practically implement the necessary semantics of Named Graphs for 
particulars.


I would like to repeat that SOL is in general undecidable, but there 
exist quite well-defined decidable subsets. Nevertheless, the idea that 
SOL is always underdecidable has been used as killer statement for a lot 
of important developments in ontology engineering. To my understanding, 
we have no need for undecidable parts of SOL. Nicola Guarino uses SOL in 
his papers.



Also: RDF(S) is an implementation technology. We can assume that there 
exists a implmentation function from the CRM-FOL to RDF(S), but this 
may not be a 1-1 function. Strange constructs like the PC0(?) may not 
have counterparts in CRM-FOL.  Changing the ontology on the bases of 
special tricks used in the implementation may not always be a good 
idea, but may inspire us to make well thought out and consistent 
changes in the ontology.







See (at least some of you) soon,

Christian-Emil




*From:* Crm-sig  on behalf of George 
Bruseker via Crm-sig 

*Sent:* 08 May 2023 16:34
*To:* Robert Sanderson
*Cc:* crm-sig@ics.forth.gr
*Subject:* Re: [Crm-sig] PC0_Typed_CRM_Property in CRMpc
Hi Rob and Martin,

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


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.


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.


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.


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.


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

Re: [Crm-sig] PC0_Typed_CRM_Property in CRMpc

[Martin Doerr via Crm-sig]

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

Re: [Crm-sig] PC0_Typed_CRM_Property in CRMpc

[Christian-Emil Smith Ore via Crm-sig]

Hi all,

The E13 Attribute assignment construct does not create any  formal connection 
between an instance of E13 and the  instance of the property  it documents. We 
have the property

P177 
assigned property of type (is type of property assigned): 
E55 Type. 
 It is no formal connection between this type and the property in question, 
however.


As far as I can se (which may be not very far) the FOL interpretation of CRM 
is, well, first order and we cannot quantify over predicates. In a second order 
logic this will be possible. Such a logic is undecidable, but may be part of it 
 it can be implemented by some constructs.


Also: RDF(S) is an implementation technology. We can assume that there exists a 
implmentation function from the CRM-FOL to RDF(S), but this may not be a 1-1 
function. Strange constructs like the PC0(?) may not have counterparts in 
CRM-FOL.  Changing the ontology on the bases of special tricks used in the 
implementation may not always be a good idea, but may inspire us to make well 
thought out and consistent changes in the ontology.


See (at least some of you) soon,

Christian-Emil



From: Crm-sig  on behalf of George Bruseker via 
Crm-sig 
Sent: 08 May 2023 16:34
To: Robert Sanderson
Cc: crm-sig@ics.forth.gr
Subject: Re: [Crm-sig] PC0_Typed_CRM_Property in CRMpc

Hi Rob and Martin,

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

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.

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.

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.

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.

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

Re: [Crm-sig] PC0_Typed_CRM_Property in CRMpc

[George Bruseker via Crm-sig]

Hi Rob and Martin,

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

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.

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.

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.

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.

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 

Re: [Crm-sig] PC0_Typed_CRM_Property in CRMpc

[Robert Sanderson via Crm-sig]

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

Re: [Crm-sig] PC0_Typed_CRM_Property in CRMpc

[Martin Doerr via Crm-sig]

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

Re: [Crm-sig] Homework for Issue 628: redo learning diagrams

[Athanasios Velios via Crm-sig]

Dear George, all,

This is a lot of work, so thank you. Looking forward to discussing this, 
I am sending a list of things to check as I browse through them:


* Some labels have underscores, others do not - I prefer without given 
that we never use underscores in the main document
* I am not sure we need dashed line for classes, not sure what they 
signify, given that the indirectness is expressed by the dashed property 
line, no?
* Some labels spill out of the class box boundary (font consistency in 
general to be checked)

* Some cardinality labels do not align properly
* I think the legend can be included only once
* It is unclear why polka dot style is used sometimes (e.g. under 
material and technique, the Modification box and Type box - mostly seems 
to be connected to .1 properties)


Do we need to check the validity for each drawing? For example the one 
on Attribute Assignment shows property arrows pointing the wrong direction.


Do we need to keep about old versions of drawings on the website? I.e. 
are they there for reference as well as used as didactic material?


All the best,

Thanasis



On 04/05/2023 14:58, George Bruseker via Crm-sig wrote:

Dear all,

An open homework relates to updating the diagrams in the Use and Learn 
section to accord with CRM 7.1.1.


On the road to that goal, we have had a first pass at re-representing 
the extant diagrams in an updated style using draw.io  .


You can find the link to this work here:

https://drive.google.com/file/d/1uZAVZ7x42ImKNZt60qZxmQ6nFQhRFkBW/view?usp=share_link 


n.b.: to see the diagrams you must click the button 'open with 
diagrams.net ' then you must accept many terms, 
then please be aware that there are some 37 tabs full of diagrams, you 
can browse them at the bottom of the draw.io  interface.


We put forward this draft remake of the existing diagrams to get 
feedback from the community on readability / functionality of this new 
representation. The content should be the same as it was, if there is a 
deviation it is likely by error.


We redid the old diagrams as it seemed like the appropriate first step 
before embarking on altering them to reflect the new CIDOC CRM 7.1.1 
realities. As we created these diagrams we noted where the diagram would 
change in the new version.


The proposal here is to solicit feedback on the representation provided 
here and then hopefully to plan the step forward to create the up to 
date diagrams based on this discussion.


Best,

George on behalf of Takin.solutions


___
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

Re: [Crm-sig] PC0_Typed_CRM_Property in CRMpc

[George Bruseker via Crm-sig]

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

Re: [Crm-sig] PC0_Typed_CRM_Property in CRMpc

[Pavlos Fafalios via Crm-sig]

Dear Martin,

I see your point, thank you for the explanation. Maybe, this was also the
motivation for introducing the property classes? (instead of using standard
rdf reification): an instance of a property class intends to represent a
specific relation in the real world, not a triple/statement in a knowledge
base (as in the case of rdf:Statement
: *"An RDF statement
is the statement made by a token of an RDF triple"*). If this is the case,
I suggest including an explanation in the RDFS of the PCs.

Best,
Pavlos

On Sat, May 6, 2023 at 9:57 PM Martin Doerr via Crm-sig <
crm-sig@ics.forth.gr> wrote:

> Dear Pavlos,
>
> I don't think this is a good solution. Every statement in a knowledge base
> is an information object. That does not say however, what it refers to in
> the universe of discourse (or real world). The identity of the information
> object is the RDF file. The identity of Michelangelo, as stated in the
> file, means Michelangelo the person and not the URI as a string in that
> file. Isn't it?
>
> This is still an issue to resolve: In CRMinf, a Proposition Set is
> regarded as Information Object, but this is not what we actually mean, we
> mean the "meaning" of that Information Object, i.e., its truth or not. As
> such, CRMinf is inconsistent. This is, I think, Issue 614.
>
> Best,
>
> Martin
>
> On 5/6/2023 12:43 AM, Pavlos Fafalios via Crm-sig wrote:
>
> Dear George,
>
> An instance of a property class represents a statement / formal
> proposition. Could we thus say that it is also an  E73 Information Object?
> Would multiple instantiation provide a solution to the problem you
> describe? E.g.:
>
> :painting_sistine_chapel
>  crm:P14_carried_out_by :Michelangelo .
> *:statement1*
>a crm:PC14_carried_out_by,  *crm:E73_Information_Object* ;
>crm:P01_has_domain :painting_sistine_chapel ;
>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 *:statement1*
>... ... ...
>
> Thoughts?
>
> Have a good weekend!
>
> Best,
> Pavlos
>
> On Wed, Mar 29, 2023 at 4:36 PM George Bruseker via Crm-sig <
> crm-sig@ics.forth.gr> 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
>>
>
>
> --
> 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: fafal...@ics.forth.gr
> Address: N. Plastira 100, Vassilika Vouton, 70013 Heraklion, Greece
> Tel: +30-2810-391619
>
>
> ___
> 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
>


-- 
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: fafal...@ics.forth.gr
Address: N. Plastira 100, Vassilika Vouton, 70013 Heraklion, 

Re: [Crm-sig] PC0_Typed_CRM_Property in CRMpc

[athinak via Crm-sig]

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