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 <crm-sig-boun...@ics.forth.gr> on behalf of George
Bruseker via Crm-sig <crm-sig@ics.forth.gr>
*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
<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/
_______________________________________________
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
