Layout of CIDOC CRM official version

In the 43rd joint meeting of the CIDOC CRM SIG and ISO/TC46/SC4/WG9; 36th FRBR - CIDOC CRM Harmonization meeting, the sig reviewed the layout of CIDOC CRM official version and decided the following:

(1) The CRM definition file will consist of two volumes. Each volume should bear a number and what it is about:
    a.    Volume A: Definition of the CIDOC Conceptual Reference Model
    b.    Volume B: Amendments of the CIDOC Conceptual reference Model

(2) The listing of the [sub-/super-]classes and [sub-/super-]properties in the definitions will be in increasing numerical order. The same applies to listing the inferences drawn among classes in the FOL representation of the CRM

(3) It is decided to delete the axiom E59(x) from the definition of E59 Primitive Value. The notation E59(x) appears in the FOL representation of inferences from subclasses of E59 to E59, without problems 
(f.i. E62(x)  E59(x))

(4) subproperties of P1 is identified by (identifies) Í <E1 CRM Entity x E41 Appellation> are to be deprecated. Also the following properties should be deprecated:

• • • P78 is identified by (identifies)  Í <E52 TimeSpan x E41 Appellation>,
    • P87 is identified by (identifies)  Í <E53 Place x E41 Appellation>,
    • P131 is identified by (identifies) Í <E39 Actor x E41 Appellation>

(5) The decision of the discussion to add E41 Appellation in the list of Superclasses of E94 Space Primitive is pending since  the compatiblity of this issue  with the  CRMgeo should be examined first (CEO's HW)

(6) add the inverse superproperty of P9 consists of (forms part of) –namely P10i contains (falls within) –in the definition of P9 (P9 isA P10i), and  add the FOL representation of the inference among P10 falls within (contains) and P132 spatiotemporally overlaps with –namely P10 (x,y) isA P132 (x,y).

(7) It was decided to delete E50 Date from the scope notes of P11 & P12  (deprecated class). The sig assigned MD to redraft the scope notes, seeing as they mistakenly associate actors (P11) and things (P12) with the Place of the event, rather than the event itself. 

(8)  it was decided that the spatiotemporal topological relations between E9 Move and P7 took place at (witnessed), P26 moved to (was destination of), P27 moved from (was origin of) and P161 has spatial projection (is spatial projection of)  be defined (unassigned)

(9) the scope note of P31 was updated

(10) It was decided to delete E51 Contact Point from the scope note definition of P92 & P93.

(11)   FOL representations were added for the superproperties of P114 

(12) the FOL representation of the superproperty of P164 was changed to represent that P164 isA P160

(13) the example of P128 was updated

(14) It was assigned to MD to review the  FOL notation by CEO for properties P169 through P190

(15) The sig reviewed the introductory text of CIDOC CRM (version 6.2.5) and did some rearranging in the order of the material plus additions and deletions in order to produce a text that will form the basis of the text to be submitted to ISO. Editorial work is still pending.  

The whole discussion maybe found here

Heraklion, March 2019

Posted by Martin on 8/4/2019

Dear All,
Here my attempt to reduce the confusion about STVs
 

Comments welcome!

Posted by Martin on 29/4/2019

Dear All,
Here my rewriting of the scope notes of P11 and P12. It is a part of the most fundamental reasoning in the CRM, which may be formulated in FOL. Likelihoods of course not. Comments most welcome!

OLD:
P11 had participant (participated in)

Domain:              E5 Event

Range:                E39 Actor

Subproperty of:   E5 Event. P12 occurred in the presence of (was present at): E77 Persistent Item

Superproperty of: E7 Activity. P14 carried out by (performed): E39 Actor

                           E67 Birth. P96 by mother (gave birth): E21 Person

                           E68 Dissolution. P99 dissolved (was dissolved by): E74 Group

E85 Joining.P143 joined (was joined by): E39 Actor

E85 Joining.P144 joined with (gained member by): E74 Group

E86 Leaving.P145 separated (left by):E39 Actor

E86 Leaving.P146 separated from (lost member by):E74 Group

P151 was formed from: E74 Group

Quantification:   many to many (0,n:0,n)
 

Scope note:         This property describes the active or passive participation of instances of E39 Actors in an E5 Event.

It connects the life-line of the related E39 Actor with the E53 Place and E50 Date of the event. The property implies that the Actor was involved in the event but does not imply any causal relationship. The subject of a portrait can be said to have participated in the creation of the portrait.

Examples:          

§  Napoleon (E21) participated in The Battle of Waterloo (E7)

§  Maria (E21) participated in Photographing of Maria (E7)

In First Order Logic:

                           P11(x,y) ³ E5(x)

                           P11(x,y) ³ E39(y)

                           P11(x,y) ³ P12(x,y)

NEW:

Scope note:         This property describes the active or passive participation of instances of E39 Actors in an E5 Event.

The known events in which an instance of E39 Actor has participated can be seen as stations of his course of life, his history. The E53 Place and E52 Time-Span where and when these events happened provide us with constraints about the presence of the related E39 Actor in the past. Collective actors, i.e., instances of E74 Group, may physically participate in events via their representing E21 Persons only. The participation of multiple actors in an event is most likely an indication of their acquaintance and interaction.

The property implies that the Actor was involved in the event but does not imply any causal relationship. For instance, someone having been portrayed can be said to have participated in the creation of the portrait.

OLD:
P12 occurred in the presence of (was present at)

Domain:              E5 Event

Range:                E77 Persistent Item

Superproperty of: E5 Event. P11 had participant (participated in): E39 Actor

E7 Activity. P16 used specific object (was used for): E70 Thing

                           E9 Move. P25 moved (moved by): E19 Physical Object

                           E11 Modification. P31 has modified (was modified by): E18 Physical Thing

                           E63 Beginning of Existence. P92 brought into existence (was brought into existence by): E77 Persistent Item

E64 End of Existence. P93 took out of existence (was taken out of existence by): E77 Persistent Item

E79 Part Addition.P111 added (was added by): E18 Physical Thing

E80 Part Removal.P113 removed (was removed by): E18 Physical Thing

Quantification:    many to many, necessary (1,n:0,n)

Scope note:         This property describes the active or passive presence of an E77 Persistent Item in an E5 Event without implying any specific role.

 It connects the history of a thing with the E53 Place and E50 Date of an event. For example, an object may be the desk, now in a museum on which a treaty was signed. The presence of an immaterial thing implies the presence of at least one of its carriers.
Examples:          

§  Deckchair 42 (E19) was present at The sinking of the Titanic (E5)

In First Order Logic:

                           P12(x,y) ³ E5(x)

                           P12(x,y) ³ E77(y)

NEW

Scope note:   This property describes the active or passive presence of an E77 Persistent Item in an E5 Event without implying any specific role.

The known events in which an instance of E77 Persistent Item was present can be seen as stations of its course of existence, its history. For example, an object may be the desk, now in a museum on which a treaty was signed. The E53 Place and E52 Time-Span where and when these events happened provide us with constraints about the presence of the related E77 Persistent Item in the past. Instances of E90 Symbolic Object, in particular information objects, are physically present in events via at least one of the instances of E18 Physical Thing carrying them. Note, that the human mind can be such a carrier. A precondition for a transfer of information to a person or another new physical carrier is the presence of the respective information object and this person or physical thing in one event.

Posted by George Bruseker on 30/4/2019

Dear Martin,

It looks like a good rewrite. The scope note for p11 should probably adopt 'her' as a pronoun in the formulation. 

Posted by Melanie on 2/5/2019

Dear Martin,

I agree with George: the first sentence of the scope note for P11 should read
"The known events in which an instance of E39 Actor has participated can be seen as stations of his or her course of life, his or her history."

Posted by Florian Kräutli  on 2/5/2019

Dear all,

You can also use either the singular 'they/their'...

    "The known events in which an instance of E39 Actor has participated can be seen as stations of their course of life, their history."

or a plural...

    "The known events in which instances of E39 Actors have participated can be seen as stations of their course of life, their history."

if one wants to avoid binaries.

I would use the latter because you start the scope note with E39 in plural ("This property describes the active or passive participation of instances of E39 Actors in an E5 Event.")
 

Posted by Robert Sanderson on 2/5/2019

Dear Martin, all,

I agree about the gendered pronouns, as you might imagine.

One further very minor note – I think there should be a second comma after “now in a museum” – the treaty was signed on the desk, not on the museum ☺

The museum clause is dependent upon and descriptive of the desk.
 

Posted by Athina on 30/5/2019

I send you my homework about graphs

Posted by Thanasis Velios on 5/6/2019

Dear all,

Following a discussion with Martin I am attaching the introduction to
basic CRM concepts for the CRM document which is to be followed by the
graphical representations and examples. We anticipate changes when all
material is considered together.

------------------------------------------------------------

Introduction to basic concepts

The following paragraphs explain core CRM concepts.
The CRM can describe entities which remain relatively stable with the
passing of time (E77 Persistent Item) and have identity based on the
continuity or continued availability of their properties. These include,
among others, monuments (e.g. E22 Human-Made Object) and mental ideas
(e.g. E28 Conceptual Object). These entities are prone to change through
human activity, biological, geological or environmental processes, but
are regarded to exist as long as such changes do not alter their essence
(their identity). For example, the Great Sphinx of Giza may have lost
part of its nose, but there is no question that we are still referring
to the same monument as that before the damage occured, since it
continues to represent significant characteristics of an overall shaping
in the past which is of archaeological relevance.

The CRM also includes entities (E2 Temporal Entity) which are themselves
time-limited processes or evolutions within the passing of time. They
necessarily involve an affected material, social or mental environment,
in the form of E77 Persistent Items or continuous substance, such as the
atmosphere.  They include among others making things by humans (E12
Production) and geological events (E5 Event). Once these entities occur,
they can only be experienced through observation or recordings. Evidence
of such entities (E2 Temporal Entity) may be preserved on material
objects being permanently affected or recorded through oral history.

Therefore a basic distinction of records modelled through the CRM is
between instances of E77 Persistent Item (endurants) and instances of E2
Temporal Entity (perdurants). In most cases this distinction is adequate
to describe database records. In exceptional cases, where we need to
consider complex combinations of changes of spatial extent over time,
the concept of spacetime (E92 Spacetime Volume) also needs to be
considered. E92 Spacetime Volume describes the entities whose substance
has or is an identifiable, confined geometrical extent that may vary
over time, fuzzy boundaries notwithstanding. For example, the built
settlement structure of the city of Athens is confined both from the
point of view of time-span (from its founding until now) and from its
changing geographical extent over the centuries, which may become more
or less evident from current observation, documents and excavations.
Even though E92 Spacetime Volume is an important theoretical part of the
model, it can be ignored for most practical documentation and modeling
tasks.

We explain these concepts with the help of graphical representations in
the next sections.

In the 44th joint meeting of the CIDOC CRM SIG and ISO/TC46/SC4/WG9; 37th FRBR - CIDOC CRM Harmonization meeting, the sig reviewed: 

(A)  the scope notes for P11 had participant and P12 occurred in the presence of  (HW by MD), did some editing and accepted the changes proposed. The intent of the rewrite was to make sure that the instances of E39/E77 were associated with the event they participated in/were present at, respectively, rather than the place where the event unfolded. The scope notes for P11 and P12 can be found here.
(B)   the text of the introductory section of the CRM Introduction to the basic concepts (formerly known as An Overview of the Model) [HW by TV], did some editing and accepted it –minor editorial work still pending. The text can be found here. HW: GB is assigned with doing the editorial work. 
(C) the graphs by AK (i) event-basic structure and (ii) Spacetime volume. The Event-basic structure was accepted as such. The Spacetime Volume  is accepted in principle. However, the ultimate decision will depend on the outcome of the discussion regarding the effort to reconcile E92 Spacetime Volume with E2 Temporal Entity and Period. The quantification of properties must also be looked into more closely. 
(D) the diagram of the example provided by MD. The example was overall accepted. The issues raised are listed below. The “problematic” values are marked in red in the diagram: 

1. the fact that it represents aspects of the integration of data of different types should be made explicit by an accompanying text and also by encapsulating the data relevant for each type in a separate box. 
2. instead of declaring the temporal information on E52 Timespan, the relevant set of properties demarcating the beginning and the end of the said timespan should be used.
3. the type assigned to “Laokoon”, i.e. “Roman”, was not fully comprehended.  

Finally, the sig has not reached a decision regarding the compatibility statement. The sig asked CEO to clean the CRM file

Paris, June 2019

Sent  by Christian Emil on 28/8/2019

Dear fellow editors,

Some time ago, in fact in Cologne in January 2018, I volunteered  to read through the entire defintion of CIDOC-CRM and add instances of etc. If my memory is correct Stephen volunteered to proofread the corrections. This work has been delayed until now:

As agreed in Paris I got the current version CRM v 6.2.6 from Chryssoula in the end July this year. I have worked my way through the document. It was a larger work than I had anticipated. Currently the document has 1617 corrections (according to msword).  Athina, George, Despoina, Chrysoula and I have made corrections and comments.

We need to go through the entire documetn and check, accept or reject the corrections and also consider changes indicated in the comments.

Most of the corrections are minor and it should not be neccessary to involve the entire SIG. I am not sure how we should proceed. I will be in Iraklio from the evening of October 20th and can spend the Monday befor the meeting on this work. Other suggestions are welcomed.

I attach the document. I suggest that Chryssoula should be the coordinator here and should keep the master.

Sent by Martin on 7/10/2019

Dear All,

Great work by Christian-Emil!!

I attach my first review:

I have accepted all trivial changes:

man-made = human made

CRM= CIDOC CRM

"instance of" in all cases I found unambiguous. In some, the existence of a comment confused me, so I left it unchanged.

Added first order logic to be consistent with definition headers.

I spotted two non-sensical scope notes. The Temporal Primitives need more standardization : "..to be situated.." etc. We need to agree on a uniform formulation.

I have not touched the literature references. May be we accept them blindly?

I have not looked at deprecated classes.

Text in red and striked out needs review.

The depricated concepts "use...." need a standard phrase and format.

I propose someone (who?) to continue with my attached version. Chrysoula, please store.

We need a minimal set of non-trivial changes to go through as a team.

Posted by Chryssoula on 22/10/2019

Dear All

Following the decisions of the current working group meeting, we invite you to vote if you accept the text  about the compatiblity with CRM in the version 6.2.6. This text is the same with the one found in the iso version(rev 2014).

The text is the following:
==================================================

Compatibility with the CRM

Users intending to take advantage of the semantic interoberability offered by this International Standard should ensure conformance with the relevant data structures. Conformance pertains either to data to be made accessible in an integrated environment or intended for transport to other environments. Any enconding of data in a formal language that preserves the relations of the classes, properties, and inheritance rules defined by this definition of the CIDOC CRM(definition document), is regarded as conformant.
Conformance with this definition document does not require complete matching of all local documentation structures, nor that all concepts and structures present in this definition document be implemented. This definition document is intented to allow room both for extensions, needed to capture the full richness of cultural documentation, and for simplification, in the interests of economy. A system will be deemed partially conformant if it supports a subset of subclasses and subproperties defined by this definition document. Designers of the system should publish details of the constructs that are supported.
The focus of this definition document is the exchange and mediation of structured information. It does not require the interpretation of unstructured (free text) information into a structured, logical form. Unstructured information is supported, but falls outside the scope of conformance considerations.
Any documentation system will be deemed conformant with this definition document, regardless of the internal data structures it uses; if a deterministic logical algorithm can be constructed, that transforms data contained in the system into a directly compatible form without loss of meaning.
No assumptions are made as to the nature of this algorithm. "Without loss of meaning" signifies that designers and users of the system are satisfied that the data representation corresponds to the semantic definitions provided by this definition .
======================================================================

PLEASE VOTE :

YES for accepting,

NO for not accepting,

by Oct. 25 2019.

all the best
 

Posted by Robert Sanderson on 23/10/2019  about Compatibility with CRM

Some issues that could be fixed, but don’t lead me to conclude that it should be a straight No … however if it is about conformance (which I believe it is) then it is a potentially legal issue as to claims of systems and we should be careful with what we say.

Suggested edits:

    Typo:  “enconding” for “encoding” in the first paragraph.
    The title is about “compatibility” but the text is about “conformance”. These are very different things. I think the title should be Conformance with the CRM.
    The sentence starting “Conformance pertains” doesn’t make sense as currently structured. Skipping the first part of the or clause, it reads:  “Conformance pertains either to […] or intended for transport to other environments.”  I think it should be:  Conformance pertains to data which is either made accessible … or intended to be transported to other environments.
    The conformance rule is ambiguous. I can claim conformance by supporting one class, as “conformance does not require complete …”.  Given the introduction later of “partially conformant”, the first paragraph should define “fully conformant” as supporting all of the classes and properties defined in the document. The next paragraph talks about conformance again, with a very different rubric.  I can be fully conformant in a system that manages only Identifiers, but the previous paragraph would require this to be partially conformant.
    The documentation system paragraph talks about compatibility and conformance. It should only talk about conformance, or we would need the definition of “compatible”
    The “without loss of meaning” is based on the subjective opinion of an indeterminate audience, yet is a core part of the determination of conformance. My Identifier system is thus fully conformant, yet implements only one class and no properties because I, as the audience, judge it to be so.

Posted by Dariah Hookk  on 23/10/2019

YES

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

Posted by Christos Papatheodorou on 23/10/2019

YES

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

Posted by Richard Light on 23/10/2019

I think no.

In addition to Rob's comments below, and the need to change 'intented' to 'intended', I have reservations about the definition of partial conformance (and by extension of full conformance).  For a start, are we trying to characterize systems, or data?  The text starts off talking about data, then later on talks about systems. They are different things.

My view is that it is useful to define conformance for data, because that helps people decide what they can do with that data. Conformance of systems I think is a less useful concept.  In particular, I don't think that having a system support every single CRM class and property is something to push for.

As regards data instances, I see 'full conformance' as meaning that the data is already in a form, or can be programmatically converted into a form, where all the classes and properties expressed by the data are taken from the CRM and meet the CRM's cardinality constraints. (I don't think we need to mention inheritance: this is 'baked into' the CRM model.)

'partial conformance' is where, after a similar optional conversion, some of the classes and properties in the data are taken from the CRM.  However, that raises another question: what is the conformance level of data where some of the classes and properties are non-CRM, but an 'extension ontology' is provided which defines all of these classes and properties, and maps them all to 'parent' classes and properties in the CRM?  Surely this is to be encouraged, and should be seen as 'more' conformant than data in which some classes and properties are CRM, and the rest is 'any old stuff'?

I agree with Rob's reservations about letting users decide what counts as 'no loss of meaning'.  One suggestion is that we could ask them to implement round-tripping between the native form of the data and its CRM-compatible expression.