Issue 322: Reification of E13, S4 and I1

Posted by Christian Emil on 27/3/2017

Issue 322: Can we connect with FOL or Second Order Logic the reification construct of E13 Attribute Assignment and S4 Observation with the named graph construction of I1 Argumentation? (posted by Martin on 2/12/2016 ) and assigned to CEO.

The problem seems to boil down to the lack of a generic way to identify sets of CRM statements on the logical level.  In this rather long text I have tried to clarify the issue for myself (at least). I have not reached a satisfying solution. I may have tried to solve another question than the issue which is somewaht looseluy specified.  It would be nice with a discussion about this issue. ​

**********************

Conclusion

In CRM we can make statements about instances of classes identified with unique identifiers (see 2  CRM in First Order Logic (FOL)) in this text. However, we cannot make statements about statements, that is, pair of instances connected by a property. This is also true for FOL interpretations of CRM.

The CRM statements in an instance of a E13 reification (E39, E13, P140, P140 , etc)  can be modeled as an instance of I4 Proposition Set. Similar for S4 Observation.  In an FOL-KB interpretation of CRM(Sci/Inf) the instance of I4 will be identified with a unique identifier, say n. In an RDF(S) implementation this identifier, n, can be used to name the corresponding graph. Therefore we can use the belief construct to assign a truth value to this instance of I4 identified with the name n of the graph for the reification construct.

The self-reference used Kurt Gödel in his famous theorem involved an encoding trick, that is, a systematic way to enumerate terms, predicates, propositions etc. Then it was possible to construct a self-referencing proposition.

We can interpret CRM statements as named (RDF) graphs and use the name of a graph as the identifier for the corresponding instance of I4. This is a similar trick to that of Gödel (mutatis muntandis) enabling higher order statements. But it corresponds to writing down the CRM statements on a paper, give the paper a unique identification number and then use this number as an identifier for the instance of I4 representing the information carried by the paper.

A better solution would of course  be to create an enumeration function for creating unique identifiers for all finite sets of CRM statements. 

 

Then it may be possible to identify an E13 construct as a given instance of I4.

**********************

My notes

1  The class  E13 Attribute assignment

‘E13 Attribute assignment’ was introduced quite early in the development of CRM as an alternative to the basic reification of property instances found in RDF. It is a very general construct consisting of a class E13 Attribute assignment (subclass of E7 Activity) and two properties:

P140 assigned attribute to (was attributed by): E1 CRM Entity

P141 assigned (was assigned by): E1 CRM Entity

 

The construct can be used to reify instances of all properties in CRM and declare connection of some type between instances of all pairs of class in CRM.

In CRM E13 Attribute Assignment is specialized into four subclasses representing

·        E14 Condition Assessment

·        E15 Identifier Assignment

·        E16 Measurement

·        E17 Type Assignment

The four subclasses represent declarative events we usually do not think of as reification. Perhaps all declarative events in CRM should be subclasses of E13 Attribute Assignment, (for example E8 Acquisition, but this is irrelevant here).

An instance of E13 Attribute Assignment fixes in time when a given relation was declared. This construct does in general not give any information about extent in time the relation is valid. The only exception is the E14 Condition Assessment where an instance of E3 Condition State (subclass of E2 Temporal Entity) is assigned to an instance of E18 Physical Thing. The corresponding instance of Ε3 Condition State must occur in time before the instance of E14 Condition Assessment since we cannot foresee the future. This is the opposite of the I1 Argumentation construct found in CRMInf, see below.

**********************

2  CRM in First Order Logic (FOL)

Roughly, the FOL representation of CRM consists of axioms constructed from the definition of CRM. The axioms will have universally quantified variables. The concrete instances of the classes in CRM are represented as names. The facts are the axioms where the (universally quantified/free) variables are replaced by the names.  In a KB (Knowledge Base) K the set of axioms is called the TBOX of K and the set of facts the ABOX of K.  The names denote real world objects.  In different interpretations (models of the theory) the names can denote different real world objects (physical, abstract, temporal entities).

**********************

3 Implementation

Information organized compliant with CRM can be implemented in RDF(S). An RDF(S) based CRM Knowledge Base is one among many possible implementations (models) for a FOL description of CRM.  By implementation (model) is meant that there is a mapping from the valid terms in the CRM-FOL KB into the content of the triplestore/graph database preserving the validity of axioms and terms resulting from the use of deduction rules. The names representing instances of classes will be names/URIs and literals and the terms will be graphs.

In RDF it is possible to give names to (sub) graphs.  Through its name a graph can be used as subject or object in an RDF-triple.  The named graph mechanism is extremely powerful. Seen from a CRM-FOL point of view, the named graph mechanism is on the implementation level and does not have a counterpart in the CRM-FOL description.  In FOL it is not possible to quantify over predicates or terms, that is, a variable can never be instantiated by a predicate.

One should remember that this is a (important) detail on the implementation level and not a mechanism expressed at the logical (FOL) level. From the logical/formal ontological level, named graphs may or may not make implementations easier.

**********************

4 Names and identifiers in CRM

In CRM all class instances can be given zero or many appellations (instances of E41 Appellation) or identifiers (instances of E42 Identifier) through the property P1 Identifies. These names and identifiers are on the real world descriptive level. That is, an instance of E42 Identifier will typically be a shelf mark, an inventory number, ISBN, or a URL:

“This class comprises strings or codes assigned to instances of E1 CRM Entity in order to identify them uniquely and permanently within the context of one or more organisations. Such codes are often known as inventory numbers, registration codes, etc. and are typically composed of alphanumeric sequences. The class E42 Identifier is not normally used for machine-generated identifiers used for automated processing unless these are also used by human agents.”

From “the Formalization of CRM – first attempt 2015 by Carlo Meghini Martin Doerr:

“ The individuals in the domain of the CRM are 1) CRM-entities which includes appellations and 2) primitive values.
The CRM models these individuals as objects, identified by object identifiers. We note tht the CRM identifiers have the following features: 1) at any time, each identifier denotes only one object 2) at any time, no two identifiers denote the same object 3) each identifier denotes the same object throughout the whole KB lifetime”

In an instance of a CRM KB the object identifiers are on a meta level and not necessarily instances of E42 Identifier identifying the object through P2.

5 The CRMInf class I1 Argumentation

Instances of I1 Argumentation is used to express that an actor believes/declares/concludes that a given set of propositions (an instance of I4 Proposition Set) is true, false, probable, etc. (an instance of E6 Belief value) for a certain amount of time given by an instance of I2 Belief, a subclass of E2 Temporal Entity. The classes and properties involved are

I1 Argumentation
    J2 concluded that (was concluded by) I2 Belief

I2 Belief (subclass of E2 Temporal Entity)
    J4 that (is subject of) I4 Proposition Set
    J5 holds to be I6 Belief Value
    I4 Proposition Set (subclass of E73 Information Object)

The construct (I1 Argumentation, I2 Belief, I6 Belief Value, and I4 Proposition Set) is different from E13 Attribute assignment.  It states that someone at a given point in time (timespan) conclude that from this point (directly after the timespan ends) and onwards (for a given time) the actor in question believes that a given set of propositions has a given truth value.

The class I4 Proposition Set is identified as

“This class comprises the sets of formal, binary propositions that an I2 Belief is held about. It could be implemented as a named graph, a spreadsheet or any other structured data-set. Regardless of the specific syntax employed, the effective propositions it contains should be made up of unambiguous identifiers, concepts of a formal ontology and constructs of logic”

The example from the CRMInf definition of I4:

“Type 29 bowls are from the 1st Century AD (expressed as CRM statements)”

can be modeled as instances of I4 Proposition Set.  So can the statements in representing an E13 Attribute assignment, e.g. the examples from the definition of  P140, P141 in CRM 6.2.2):

“01 June 1997 Identifier Assignment of the silver cup donated by Martin Doerr (E15) assigned attribute to silver cup 232 (E19)
01 June 1997 Identifier Assignment of the silver cup donated by Martin Doerr (E15) assigned object identifier 232”

6 The CRMSci class S4 Observation

The class S4 is a subclass of E13 Attribute assignment and the properties O8   observed and O8   observed value are subproperties of P140 assigned attribute to and P141 assigned respectively:

S4 Observation

Subclass of: E13 Attribute Assignment

(Subclass of I4 Argumentation when CRMInf is included)

O8   observed (was observed by): S15 Observable Entity (subproperty of P140)

O9   observed property type (property type was observed by): S9 Property Type

O16 observed value (value was observed by): E1 CRM Entity (subproperty of P141)

 

7 The Issue 322

The issue is formulated as “Can we connect with FOL or Second Order Logic the reification construct of E13 Attribute Assignment and S4 Observation with the named graph construction of I1 Argumentation?”

In CRM we can make statements about instances of classes identified with unique identifiers (see 2  CRM in First Order Logic (FOL)) in this text. However, we cannot make statements about statements, that is, pair of instances connected by a property. This is also true for FOL interpretations of CRM.

The CRM statements in an instance of a E13 reification (E39, E13, P140, P140 , etc)  can be modeled as an instance of I4 Proposition Set. Similar for S4 Observation.  In an FOL-KB interpretation of CRM(Sci/Inf) the instance of I4 will be identified with a unique identifier, say n. In an RDF(S) implementation this identifier, n, can be used to name the corresponding graph. Therefore we can use the belief construct to assign a truth value to this instance of I4 identified with the name n of the graph for the reification construct..

The self-reference used Kurt Gödel in his famous theorem involved an encoding trick, that is, a systematic way to enumerate terms, predicates, propositions etc. Then it was possible to construct a self-referencing proposition.

We can interpret CRM statements as named (RDF) graphs and use the name of a graph as the identifier for the corresponding instance of I4. This is a similar trick to that of Gödel (mutatis muntandis) enabling higher order statements. It corresponds to write down the CRM statements on a paper, give the paper a unique identification number and then use this number as an identifier for the instance of I4 representing the information carried by the paper. A better solution would be to create an enumeration function for creating unique identifiers for all finite sets of CRM statements.

 

In the 40th joined meeting of the CIDOC CRM SIG and ISO/TC46/SC4/WG9 and the 33nd FRBR - CIDOC CRM Harmonization meeting, the crm-sig discussed about the old HW assignment of Carlo and CEO for logical representation of named graphs at instance level.

In the flow of this discussion a comment was posed about “how to describe what can be observed”. It is accepted that what we observe is actually a ‘situation’ a bundle of properties. So class ‘observable entity’ is wrong. It is needed a logical construct that certain kinds of things can be result of an observation

HW assigned to CEO to communicate with Carlo in order to follow up the proposed by Carlo First Order Theory for the representation of named graphs at instance level.   Achilles’ reading example in CRMtex (TX5 Reading)  is good starting point.

Cologne, January 2018