Posted by Martin on 4/3/2019
On the occasion of the deprecated classes and properties as well as of the other CRM family models we should discuss how the various conceptual units appeared in the official CRM text should be presented.
Posted by Christian Emil on 23/3/2019
I have read all the FOL expressions in the class and property definintion. I have added a comment for every correction/addition I have done in all 55. I have also done some other corrections. An important issue is the FOL describtion of E1 and E59. These classes don't have any superclasses and have a FOL description E1(x), E59(x). Since there is an implicit universal quantifier this implies that all instances of all classes are instances of E1 and E59.
Posted by Christian Emil on 24/3/2019
E1 CRM Entity and E59 Primitive Value are the only classes in CRM without a superclass. I assume we can imply from this that the two classes are disjoint.
In the CRMcore definintion the FOL descriptions are
E1 CRM Entity:
E1(x)
E59 Primitive Value:
E59(x)
The FOL descriptions in CRM are open expression with an implied universal quantifier. This is ok but not very informative for E1(x) = "all x. E1(x)" expresses the idea that everything we talk about are instanses of the universal class E1 CRM Entity.
The E59(x) = "all x.E59(x)" blurs the picture and indicate in a FOL description of CRM that everything is a primitive value. It is ok to have the E59(x) as a predicate, but "all x.E59(x)" cannot be an axiom. We can solve this by removing the FOL description of E59.
Opinions?
Posted by Martin on 24/3/2019
Dear Christian-Emil,
Indeed it appears now that the Primitive Values are not as separate as initially conceived. Please check against the interpretations we give in the RDF implementation guidelines. On the other side, E59 instances do not have identifiers of their own as E1 instances have. But wrt the FOL description, Carlo should have an opinion
Posted by Christian Emil on 24/3/2019
Dear Martin, all,
An RDF interpretation of CRM is an implementation like any other implementation, for example in a relational database formalism. My impression has been that the FOL description should be authoritative in the sense that there has to be what we may call a mapping/implementation function from the FOL description to an implementation of CRM preserving the validity. The FOL description should be carefully expressed. As it is now, iti s a valid statement in the FOL theory that every instance is a primitiv value.
Could you, please, give me a pointer to what is the current description of the implementation (interpretation) of CRM in RDF?
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:
- 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.
- 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.
- 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 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.
In the 45th joint meeting of the CIDOC CRM SIG and SO/TC46/SC4/WG9; 38th FRBR – CIDOC CRM Harmonization meeting, the sig defining the Layout of the CIDOC CRM official version discussed and took decisions about the following subjects:
1. The order of the examples. The Examples section should comprise three sub-sections, namely: one for basic constructs (space and time), one showing the spacetime volumes of things coming together, and then the particular example of Winkelmann seeing Laokoon. This example could be made into a demo using ResearchSpace /metaphacts. Instances of E53 Place and E21 Person are to be given as TGN and ULAN URLs and then connected to their appellations there. This doesn’t go to the CIDOC CRM official version –it should appear in the Tutorials section or FAQ on the CRM site.
HW: ML & NC are to produce the .rdf for the Laokoon example.
Further discussions regarding the diagram of “Winkelmann-sees-Laokoon” should be documented in a new issue.
2. to be examined the color -code of the entities participating in the example in a new issue. The sig decided to form a NEW ISSUE regarding the color-code used for representing CRM classes. HW: NC to make a demo of that using the color code of 3M.
3. Roman and Hellenistic are to be treated as instances of E4 Period - of the E12 Production of the Roman copy of Laokoon and the E12 Production of the original statue, respectively.
4. about compatibility statement: Reading out the text once more and voting on the spot was considered counterproductive and time consuming. The members of the sig mentioned they preferred to be sent the document and then comment and initiate an e-vote on its content. E-vote message was sent to the crm-sig members about compatibility. The sig reviewed the e-vote results about compatibility statement and decided that compatibility statement needs more work. HW: MD. New issue for this discussion has been initiated.
5. about FOL Shortcuts: The sig decided that the FOL representation of properties should also state full paths to shortcuts. These full paths should also include classes for intermediate nodes. Where an inverse property is used as an intermediate node in the full path, it should also appear in the FOL formulation. FOL representation of full paths will be listed under the “In First Order Logic” section in the definition of the property. No subsection specially designated for the representation of shortcuts in FOL is required.
6. The sig reviewed CEO’s HW which involved editing the classes and properties of CIDOC CRM according to decisions made in the context of other issues, checking for inconsistencies and editing them. In what follows, affected classes and properties will be listed in their old form and their new form (i.e. post-editing in version 6.2.7). Specifically:
E4 Period : The sig accepted the proposed changes on the definition of E4 Period as it appears on the definition of CIDOC CRM v 6.2.7.
E15 Identifier Assignment: The sig accepted the definition of E15 Identifier Assignment as it appears on the definition of CIDOC CRM v 6.2.7 –i.e. erasing of the identifiers for the classes linked to E15 Identifier Assignment through properties from the examples, as these were considered misleading. Thus the scope note and the examples changed
E32 Authority Document: The example “64. (Herber, 1994)” was deleted and the bibliographic reference for the Getty Art and Architecture Thesaurus needs be fixed. The examples changed
E34 Inscription: Minor proposed editorial changes approved.
E39 Actor: The sig agreed to delete the **second paragraph** of the scope note.
E53 Place: The sig accepted the changes to the definition of E53 Place.
E60 Number – Issue 435: The sig reviewed MD’s rework of the scope note for E60 Number, which aimed at redefining the class without recourse to deprecated classes of the CRM (E50, E47). The new scope note was accepted. This resolves issue 435 as well
E67 Birth: The sig accepted the editorial work by MD and CEO.
E69 Death:Minor editorial changes proposed by CEO accepted.
E70 Thing: The sig accepted the editorial changes on the examples section by MD and his proposal to cite the source of the example in the list of bibliographic references used in the CIDOC-CRM.
E74 Group: The sig reviewed the changes proposed by MD & CEO and accepted them
E77 Persistent Item –issue 433: The sig discussed with the proposal by MD to revise the scope note of E77 Persistent Item and about what is the identity criteria of E77? The issue is pending.
E81 Transformation: The sig revised the scope note of E81 Transformation taking into account MD’s comments. The scope note changed
E83 Type Creation: minor typos accepted
E92 Spacetime Volume: The scope note was edited according to the CEO’s note.
E93 Presence: The sig accepted the editorial changes proposed by CEO. The scope note changed.
E94 Space Primitive: The sig made changes during the meeting and it is decided to be put up for an email vote the acceptance of these changes.
P2 has type (is type of): The scope note was edited according to the proposal by MD & CEO –i.e. to substitute the sentence on refining CIDOC CRM concepts by E55 Type by a reference to the introductory section on Types. The new scope note is to be put up for an email vote.
P4 has time-span (is time-span of): The sig reworked the scope note for P4 has time-span (is time-span of) on the basis that it expressed epistemological notions rather than defining what a time-span is. In a similar vein, it was decided that a new issue should start to explain that shared time-spans can only be declarative ones –not phenomenal.
P9 consists of (forms part of): The sig accepted MD’s proposal to erase P132 spatiotemporally overlaps with [D:E92 Spacetime Volume, R: E92 Spacetime Volume] from the list of superproperties of P9 consists of (forms part of).
The subproperty and FOL sections of P9 consists of (forms part of) changed
P11 had participant (participated in): The sig did some editorial work on the scope note of. The scope note changed
P13 destroyed (was destroyed by): The sig did some editorial work on the scope note of P13 destroyed (was destroyed by). The scope note changed
P31 has modified (was modified by): The sig accepted CEO’s proposal to delete the final clause of the scope note. The scope note changed
P46 is composed of (forms part of): The sig did some editing on the scope note and to open a new issue to discuss about MD’s proposal to add the clause “The spatial extent of the part is included in the whole” in the scope note of P46 is composed of (forms part of)
P53 has former or current location (is former or current location of): The sig accepted the re formulation of CEO, in the first paragraph.
P54 has current permanent location (is current permanent location of): It was proposed that the property be deprecated due to lack of use and to open a new issue is to be formed to discuss the fate of P54.
P57 has number of parts:The sig accepted the re formulation of CEO, in the first paragraph.
P76 has contact point (provides access to): Following the deprecation of E51 Contact Point in the CRM in favor of E41 Appellation, affected properties need be edited as well.
P79 beginning is qualified by: The current scope note was accepted as a working definition by the 43rd CRM sig meeting. It still needs to undergo editing. SS was given the task of proofreading. HW: SS is to proofread and edit the scope note for P79 beginning is qualified by.
P80 end is qualified by: The scope note needs editing. SS is to proofread it.
P81 ongoing throughout: Following MD’s proposal, the sig decided that the scope note for P81 needs revising due to epistemological implications. The quantification the quantification is wrong (I,n= the right one). Needs formulation. Aside that, the sig did some editorial changes but the scope note is not complete. More editing is needed. The sig assigned to MD & CEO to reformulate it.
P82 at some time within: Following MD’s proposal, the sig decided that the scope note needs be revised. The sig assigned to MD & CEO to reformulate it.
P92 brought into existence (was brought into existence by): The minor editorial changes proposed by MD were accepted by the sig. The scope note of P92 changed
The sig agreed to deprecate the following classes and move it to CRMarcheo instead. These are P114 is equal in time to, P115 finishes (is finished by), P116 starts (is started by), P117 occurs during (includes), P118 overlaps in time with (is overlapped in time by), P119 meets in time with (is met in time with), P120 occurs before (occurs after)
P121 overlaps with: the sig edited the scope notes in line with the proposals made by CEO.
P122 borders with: the sig edited the scope notes in line with the proposals made by CEO.
P127 has broader term (has narrower term): The scope note of the property was editing.
P156 occupies (is occupied by): The scope note underwent extensive editing in line with CEO’s observation –namely, that since P156 occupies isA P157i provides reference space for, this relation should also reflect on the scope note. The resulting version is not finalized; it needs more proofreading. The FOL representation is correct. The scope note changed
P177 assigned property type: The sig decided that the scope note should comprise a reference to the section “About Types” in the introductory chapter of the CRM definition, on a par with the scope note of P2 has type. The scope note changed
P189 approximates (is approximated by):The sig accepted minor proposed editorial changes. The scope note changed
References should be consistent across the document; i.e. observing one citing style. SS proposed that all citations are in Harvard Style (Author. Year. Title. City. Publisher. Pages). Which means that in-text citations should not be relegated to footnotes; rather, these should conform to the in-text references in Harvard Style, i.e. (Author, Year, Pages).
During the discussion bout the layout of version 7.0, sig revised and took decisions on the following issues
Issue 437: Scope note and examples of E41 Appellation (part II): The sig reviewed the scope note for E41 Appellation (proofread by SS) and accepted it. The new scope note is presented in the issue 437 in this document. The issue closed.
Issue 241: this decision repeats the decision taken for issue 241 above and the decision made in the 43rd CRM sig meeting –i.e. merging the sections “Monotonicity”, “Minimality”, “Extensions”, “Coverage” and “Conservative Extension of the Scope of CIDOC CRM by Model Extensions” . The decision was these sections (modelling principles) to be included in the new version. HW assigned to Steve to put them in an order, to PR and CEO to merge the text and MD to review the final text. The discussion on modelling principle will be continue to a new issue
Issue 281: Erlagen OWL / CRM: The sig decided that there is no issue regarding the license of CRM. The issue closed.
Issue 314: The introductory text of CIDOC CRM: The sig ratified the outcome of the e-vote on the introductory text for the “Use and Learn” section of the CRM site. Issue closed.
Issue 432: Adding islands to E27 Site: The sig accepted MD’s proposal to add islands as examples of E27 Site.
Issue 294: E55 Type relations:The sig decided the E55 Type relations will move to CRM Archaeo.
Finally the sig decided to close this issue and any remaining discussions should be continued in new issues as already have been proposed.
The detailed discussion about this issue can be found here.
Heraklion October 2019