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
