ID
Title
Working Group
Status
Closing Date
1 How to Model Collections....
1
done
2002-02-21
2 Make the scope note for Actor more explicit....
1
done
2002-02-21
3 How to model life stages of natural history specimens ....
1
done
2002-07-02
4 How to model extended topological operators....
1
done
2001-10-18
5 How to model sound and multi-media objects....
1
done
2001-10-18
6 How to model databases....
1
done
2002-02-22
7 How to model relation between physical carrier and conceptual objects....
1
done
2002-07-02
8 Do physical feature and its decomposition need to be more rigidly defined?....
1
done
2002-07-05
9 How to model certainty and belief (scope and method)....
1
done
2002-07-05
10 Revise position of E27 Site....
1
done
2002-02-21
11 How to document archaeological inference chains....
1
done
2002-07-05
12 How to model change of classifications (comprehension)....
1
done
2002-02-22
13 Is inception distinct from creation?....
1
done
2002-07-05
14 How to model 'subjects'....
1
done
2002-07-02
15 Is title different from appellation?....
1
done
2002-07-05
16 Which terminology should we use?....
3
done
2002-10-22
17 How to visually distinguish examples drawn from subclasses within scope notes of a superclas....
1
done
2001-10-18
18 Should there be a new name for the CRM?....
SIG
open
In Progress
19 How is the CRM going to be used ?....
2
open
In Progress
20 How to model legal items....
1
done
2002-07-05
21 How to model membership entity, with temporal properties....
1
done
2002-07-02
22 How to deal with implementation guidelines....
4
open
In Progress
23 Where does temporal validity fit in with short cuts and indirection?....
4
open
In Progress
24 Review of production/creation....
1
done
2002-07-05
25 How to model a physical documents class (e.g. books)....
1
done
2001-10-18
26 How to model handling of process phases....
1
done
2002-07-05
27 Definition of the minimum scope for standardisation....
1
done
2002-07-05
28 How to organize outreach: collaboration, teaching and training, transfer of know-how....
4
open
In Progress
29 How to model a person's birthplace....
1
done
2002-07-05
30 How to model a person's nationality....
1
done
2001-10-18
31 How to model an actor's "active place"....
1
done
2001-10-18
32 How to model the depiction of a group....
1
done
2001-10-18
33 How to model the depiction of a place....
1
done
2002-07-05
34 How to model sequences of events (temporal or spatial)....
1
done
2001-10-18
35 Guidance for museums etc. to distinguish between titles and other appellations....
1
done
2002-02-22
36 How to model sequences of physical and conceptual objects....
1
done
2002-07-03
37 Transforming activity terms into gerunds where possible....
1
done
2002-02-21
38 Delete Gender....
1
done
2002-02-22
39 Creation of test data set for validating CRM compliance....
2
open
In Progress
40 Physical features should have location....
1
done
2001-10-18
41 Missing motivation for Man-Made Object....
1
done
2001-10-18
42 Technique Application should be subproperty of "took into account"....
1
done
2001-10-18
43 Scope Notes for Properties....
3
done
2002-10-22
44 Modeling States....
4
open
In Progress
45 Causal relation between events....
1
done
2002-02-22
46 Explanation about referring to use of materials in events and procedures....
1
done
2002-07-05
47 Use of kinds of objects....
1
done
2002-02-22
48 Use of materials in events....
1
done
2002-02-22
49 How to describe the technique that connects parts....
1
done
2002-02-22
50 Use of the has type property....
3
done
2001-10-18
51 Mappings may depend on object type....
4
open
In Progress
52 Where does an instance of a multimedia object appear in the CRM....
1
done
2002-07-03
53 How to model digital surrogates....
1
done
2002-02-22
54 Create a list of FAQs ....
4
open
In Progress
55 Difference between museum and library information ....
4
open
In Progress
56 Objects which are typical for a class ....
1
done
2002-07-02
57 Effort to teach use of the CRM ....
4
open
In Progress
58 How to organize the translation of the model....
1
done
2002-07-03
59 How to name the standard ....
4
open
In Progress
60 Identify new communities for collaboration ....
4
open
In Progress
61 Do we need a property "is copy of" ? ....
1
done
2002-07-02
62 Do we need an Actor Appellation entity? ....
1
done
2002-07-03
63 Does the Appellation need a value property? ....
1
done
2002-02-21
64 The definition of Number is too narrow ....
1
done
2002-02-21
65 Implementation guidelines for compounds ....
4
open
In Progress
66 Define exclusivity between CIDOC CRM entities ....
1
done
2001-10-18
67 How to model birth of living beings in general ....
1
done
2002-07-02
68 How to model isA relations between types ....
1
done
2002-02-22
69 Spatiotemporal overlaps of periods ....
1
done
2002-07-03
70 Relationship between P15 took into account and P17 was motivation for ....
1
done
2002-07-03
71 Guidance to distinguish between titles and other appellations ....
1
done
2002-02-21
72 Scope note of Modification ....
1
done
2002-07-03
73 Scope and Name of Existence....
1
done
2002-02-21
74 Collections have no owner ....
1
done
2002-02-22
75 Rename E72 Stuff ....
1
done
2002-02-21
76 Contemporary Naming Procedure....
1
done
2002-07-02
77 Identification Procedure....
1
done
2002-07-02
78 P15 took into account to become a sub-property of P12 occurred in the presence of ....
1
done
2002-07-03
79 Change Property Name P17 was motivation for to was motivated by....
1
done
2002-07-03
80 Change range of P18 motivated the creation of ....
1
done
2002-07-03
81 Numbering of Properties....
1
done
2002-07-04
82 Review the range for P24 transferred title of ....
1
done
2002-07-03
83 P51 through to P55 should move from physical object to physical stuff....
1
done
2002-07-03
84 Consistency of P60 is member of and P107 had member ....
1
done
2002-07-02
85 Physical Carriers and Properties....
1
done
2002-07-02
86 P66 refers to concept is redundant....
1
done
2002-07-02
87 Ownership and Legal Rights....
1
done
2002-07-05
88 Rename Properties P81 at least covering and P82 at most within....
1
done
2002-07-03
89 P85 consists of is redundant....
1
done
2002-07-03
90 Scope Notes of E52....
1
done
2002-07-03
91 P72 has language is redundant....
1
done
2002-07-03
92 Declare all disjoint classes....
3
done
2002-10-22
93 Also Represented By....
1
done
2002-07-03
94 Position of E72 Legal Object....
1
done
2002-07-03
95 P12 occurred in the presence of....
1
done
2002-07-03
96 Use of S/W tools....
1
done
2002-07-03
97 Scope note for E17....
3
done
2002-10-23
98 Physical Object exhibits general features....
4
open
In Progress
99 Birth of non-humans....
4
open
In Progress
100 Scope note of E33 Linguistic Object....
3
done
2002-10-23
101 Scope Note for E73 to contain Multimedia Objects....
3
done
2002-10-23
102 Scope note for Exx Actor Appellation....
3
done
2002-10-23
103 Scope note for E42....
3
done
2002-10-24
104 P77 consists of is redundant....
1
done
In 2002-10-22
105 E67 Birth with multiple off springs....
3
done
2002-10-24
106 P105 right held by ....
1
done
2002-10-23
107 P33 subproperty of P12....
1
done
2002-10-23
108 Property needed for Actor Appellation....
1
done
2002-10-23
109 Declare "necessary" and "dependent" properties....
3
done
2002-10-22
110 P109 is curated by (curates)....
3
done
2002-10-24
111 Add the crm scope definition, intended scope, to the final document ....
3
done
2002-10-24
112 Consistency of presence and participation....
1
done
2002-10-23
115 Right & Legal Object....
3
done
2002-10-24
116 The new CIDOC CRM web site ....
4
open
In Progress
117 For P62, property P62.1 mode of depiction is missing....
1
done
2002-10-22
118 P30 transferred custody not to be a sub property of P12 occurred in the presence of....
1
done
2002-10-22
120 Naming rules for properties....
3
done
2002-10-22
121 E12 Production Event....
3
open
In Progress
122 Should the word "characteristically" be added to the scope note of all sub-classes of Appell....
3
open
In Progress
123 Reclassification needs to be considered ....
1
open
In Progress
124 Scope note for E84 Information Carrier needed....
3
done
2002-10-22
125 What notion of semantic interoperability should be contained within the CRM? ....
3
open
In Progress
126 Explanation of Allen Operations....
3
open
In Progress



Issue No:1
Title How to Model Collections
Background Collections seem to be an intellectual construct on top of physical items. On one side, this suggests an immaterial nature. On the other side, any aggregation of items can be seen as a collection in the wider sense. As the parts and wholes are no absolute terms, a set of chessmen may not have a substantially different nature, but would be treated typically as one museum object. Therefore the integrity of a "Physical Object" is not based on physical contiguity. In particular all states of broken objects would complicate classification unnecessarily, if they whole would change from material to immaterial.
Also important is the distinction of collection= act of collecting, collection=organization maintaining collected items, collection=" things collected, specif., as in a hobby !a collection of stamps" (Webster)".
Important for the modeling are the properties: can a collection be destroyed by fire? Etc. Particularly curious are collections of physical objects and electronic material, which poses questions to the materiality of electronic manifestations. Also important is the handling of begin and end of the existence of a collection.
Old Proposals
Current Proposals

In scope:
Model "Physical Collection" as subclass of  "E19 Physical Object ". The notion of a "collection of poems" is regarded as another concept. A property "Physical Collection. is maintained by (maintains) : Actor" is needed. The collection as an organization is normally a legal body or a person.

alternative property: is curated by (curates).

Alternatively, one could use "has current keeper" as the curator?
Do we regard "has current keeper" as implied by "curates" ?
Is the curation different in practice from ownership and physical
custody?

This poses two questions:

1) which is the related activity:
Curation , 
   subclass of: Activity
     curated : Collection

Then "curated by" is a shot cut of Curation, following standard patterns.

2) How do things come in and out of the
Collection?

I propose:

Part Addition
   subclass of: Activity
      added: Physical Object
      to:        Physical Object

Part Removal
  subclass of: Activity
       removed: Physical Object
       from:        Physical Object

This generalizes part movement, probably useful for archtecture and
archeology.

Outcome

The entity "Collection" is subclass of : E24 Physical Man-Made Stuff.

scope note:

This entity describes an aggregate of items, which is maintained by an Actor following a plan of cultural relevance over time. Things may be added or taken out of a collection in pursuit of this plan. A collection is designed for a certain public, and the conservation of the collected items is normally catered for. Collective objects in the general sense, like a tomb full of gifts, a folder with stamps, a set of chessmen fall naturally under Physical Object and not under Collection. They form wholes in the sense that they share a common lifecycle, either because they physically stick together, like the folder or the tomb, or because they are kept together for their functionality, like the chessmen.
Examples for Collection are: The John Clayton Herbarium.

Properties:

is curated by (curates) : E39 Actor

    scope note: This property links the Collection to the Actor in charge for maintaining the Collection.

Part Addition
   subclass of: E11 Modification

scope note:

This Entity describes the activities by which a unit of Physical Man-Made Stuff is increased by a part. This can be either an accessory or a component, which is more or less permanently attached to or integrated into a Physical Object. It can be an element which is added to an aggregate of items, like a collection of stamps or a heap of sherds. It can be an immobile object which is added to a special collection of immobile objects curated by some organisation, e.g. caves with prehistoric findings. The objects added form afterwards part of a whole clearly identifiable by independent criteria which justify a common lifecycle of all parts of that whole - be it because they are kept together for a certain function, like a set of chessman, be it because they stick physically together like a car, or be it because they are treated, conserved and restaurated together like a collection of caves. The object subject to the addition is Man-Made, at least due to the very activity of adding. This Entity is the basis for reasoning on the continuity of history of objects, which are integrated or removed without affecting their internal identity over time, like valuable antique items or bones of saints being repeatedly integrated into precious jewelry or containers, but also museum objects being transferred from collection to collection.


      added (was added by) :                  E18 Physical Stuff

This property links the activity of part addition to the unit of Physical Stuff becoming part of the
respective whole.

      added to(was augmented by):        E24 Physical Man-Made Stuff
         (subproperty of "has modified")

This property links the activity of part addition to the whole which is augmented by the new part. As
the former changes due to this act, this property is a subproperty of "has modified".


     Part Removal
  subclass of: E11 Modification

  scope note:

This Entity describes the activities by which a unit of Physical Stuff is decreased by a part, which may in the sequence be documented with an individual identity or has been documented individually already before. This can be either an accessory or a component, which is more or less permanently detached or removed from a Physical Object. It can be an element which is taken from an aggregate of items, like a collection of stamps or a heap of sherds. It can be an immobile object which is taken out of special collection of immobile objects curated by some organisation, e.g. caves with prehistoric findings. This Entity is the basis for reasoning on the continuity of history of objects, which are integrated or removed without affecting their internal identity over time, like valuable antique items or bones of saints being repeatedly integrated into precious jewelry or containers, but also museum objects being transferred from collection to collection. In case of cutting or breaking out pieces, which had no recognizable identity before the removal, the latter should be regarded as a combination of Part Removal and production. Cases of complete decomposition of a whole into pieces, such that the whole ceases to exist under the aspect it had been documented, should be modelled as transformation, i.e. a simultaneous destruction and production. Similarly, a dissolution of a collection is a simultaneous part removal and destruction. It does not imply loss of an identifiable part. This should be documented by the Destruction of the respective item.        

removed (was removed by):             E18 Physical Stuff

This property links the activity of part removal to the unit of Physical Stuff ceasing to be part of the
respective whole.

         removed from (was dimished by):    E18 Physical Stuff
                 (subproperty of "has modified")

This property links the activity of part removal to the whole which is diminished by the new part. As
the former changes due to this act, this property is a subproperty of "has modified".

Small edits to the scope note suggested by MD were incorporated and the new whole approved.

Monterey 21/2/2002.

Status done
Working Group 1
Starting Date 2001-07-05
Closing Date 2002-02-21



Issue No:2
Title Make the scope note for Actor more explicit
Background Is the treatment of intentionality and responsibility of actors adequate?
Old Proposals
Current Proposals In scope:
Make the scope note for Actor more explicit so as to communicate the idea of legal responsibility:

While looking at the existing scope notes for the Actor entity, I noticed
that the scope notes for the Actors Hierarchy would also need to be
revised (Tony Gill):


Actors Hierarchy

[** Current Scope Note **]
All entities in this hierarchy are instances of the metaclass "Actor
Type".

Until now, only one subclass is defined, the physical person. As this has
a physical nature as well, it is listed already under physical objects (In
a passive sense, as patient, mummy etc.). Here in the future, all kinds of
social organizations should be characterized.

[** Proposed replacement Scope Note **]
All entities in this hierarchy are instances of the metaclass "Actor
Type".

Actors are people, either individually or in groups, that can have the
potential to perform intentional actions of their own volition.

There are two subclasses of Actor, Person and Groups, used to distinguish
between individual human beings and identifiable groups of people. Person
is also a subclass of Biological Object. The Groups class has a further
subclass, Legal Body, used to identify groups that are identifiable as
entities in the legal sense.


E39 Actor

[** Current Scope Note **]
People, either individuals or a groups of persons, or organisations, under
the aspect of their role in activities. E.g. The ISO central committe, the
Benaki Museum in Athens, Greece, the Bauhaus in Weimar, Germany, Monet,
Me.

An informal group, such as a school of artists, may acquire an identity
and perform actions without ever becoming an officially established legal
entity. Such cases should be documented as instances of Actors, using an
appropriate sub type.

[** Proposed replacement Scope Note **]
Actors are people, either individually or in groups, that have the
potential to perform intentional actions for which they can be held
responsible. Examples include the ISO Central Committee, the Benaki
Museum, the Fauvists, and Pablo Picasso. The CRM does not attempt to model
the inadvertent acts of actors.

Individual people should be documented as instances of E21 Person, whereas
groups should be documented as instances of either E74 Group or its
subclass E40 Legal Body.

Outcome Proposal accepted, Monterey 21/2/2002.
Status done
Working Group 1
Starting Date 2001-07-05
Closing Date 2002-02-21



Issue No:3
Title How to model life stages of natural history specimens
Background
Old Proposals
Current Proposals

In scope:
It must be checked, if life stages of individual specimen appear in real data (FENSCORE etc.) only as types of objects (stage in which they died) or are dealt with analytically. Only in the latter case a specific model is needed.

In the Monterey Meeting Feb. 2002, in presence of Natural History experts, it was proposed that :

"Life stages are already covered by E55 Type"

Outcome

Proposal accepted, Copenhagen 2/7/2002.

Status done
Working Group 1
Starting Date 2001-07-05
Closing Date 2002-07-02



Issue No:4
Title How to model extended topological operators
Background How to model continuity, extended topological operators (in particular temporal and spatial).
Old Proposals
Current Proposals

In scope:
Check data structures, like OPEN GIS as a source to identify relevant relationships.

A specific proposal:

Here a proposal to model spatiotemporal relationships:

All temporal relationships between Temporal Entities are defined through the relationships of their associated time-spans via Allen operators:
"before", "after", "equal", "meets", "met_by", "overlaps", "overlapped_by", "during", "includes", "starts","started-by", "finishes", "finished-by".
Definitions see e.g. :
Bernhard Nebel, Hans-Juergen Buerckert, "Reasoning about Temporal Relations: A Maximal Tractable Subclass of Allen's Interval Algebra", in Proc.AAAI-94,p.356-361.Seattle,WA,August 1994.

"Implementing a Temporal Datatype"
., 

For spatial relationships:

Place - "borders with: Place", "overlaps with: Place".

For spatiotemporal relationships:

Period - "overlaps with: Period", "falls within : Period" (existing)

A scope note must distinguish between the part-of
relationship of Period (consists of) and the spatiotemporal "falls within"

Outcome

All temporal relationships between temporal entities are defined through a set of 7 properties that are equal to the Allen Operators:

E2  Temporal Entity:

before (after) :                               E2 Temporal Entity
     meets in time (met-by in time):    E2 Temporal Entity
     overlaps in time (overlapped-by in time):   E2 Temporal Entity
     during (includes in time):                          E2 Temporal Entity
     starts (started-by):                        E2 Temporal Entity
     finishes (finished-by):                   E2 Temporal Entity
     equal in time:                                E2 Temporal Entity

For spatial relationships:
     E53 Place - "borders with: E53 Place", "overlaps with: E53 Place".
 

Paris 18/10/2001.

For spatiotemporal relationships: issue left open (69)

Status done
Working Group 1
Starting Date 2001-07-05
Closing Date 2001-10-18



Issue No:5
Title How to model sound and multi-media objects
Background How to model sound and multi-media objects under conceptual object
Old Proposals
Current Proposals In scope, details of the inner structure of multimedia objects are regarded as out of scope.
Outcome

Details of the inner structure of multimedia objects are regarded as out of scope.
By decision October 2001, the issue is reformulated to “Where does an instance of a multimedia object appear in the CRM? (52).

Paris 18/10/2001.

Status done
Working Group 1
Starting Date 2001-07-05
Closing Date 2001-10-18



Issue No:6
Title How to model databases
Background The issue needs more clarification. Clearly, there is a difference between the physical carrier, the database as a logical container and the contents of a database. A question arises about the identity of a database over time, and its definition in contrast to documents, if there is any difference.
Old Proposals
Current Proposals

In scope. The proposal is to treat a database as an information object. There is a need to model databases (October 2001).

Following the proposal from Paris to treat databases as Information Objects, the question is, if it
has any characteristic properties that would justify an individual entity in the CRM. The only properties I can think of is:

"is composed of"
"documents".

I can hardly think of a database which does not document. Databases as art objects are still to be invented, or may not
be regarded as databases. Therefore I propose to include databases in the scope note of documents. MD, Janary 2002.

Outcome

Databases are regarded as a special case of E31 Document. This has to be included in the scope note. No changes to the model are required.

Monterey 22/2/2002.

Status done
Working Group 1
Starting Date 2001-07-05
Closing Date 2002-02-22



Issue No:7
Title How to model relation between physical carrier and conceptual objects
Background There are two solutions: Either an object is instantiated multiply as physical object and conceptual object, or a specific link is introduced. This implies how to model a physical documents class (e.g. books) (former issue 25).
Old Proposals
Current Proposals

In scope: Introduce a new entity: Information Carrier to replace Iconographic Object. The link for this would be "is carrier of (is materialized by)" which points to Information Object.

Monterey 22/2/2002.

Outcome Resolved by creating new entity: Information Carrier to replace Iconographic Object (E23) and to add a property "is carrier of (is materialised by)" from Information Carrier  to Information Object (E73). E23 to be deleted. E23 was not regarded a subclass of E73.

Proposal accepted, Copenhagen 2/7/2002.
Status done
Working Group 1
Starting Date 2001-07-05
Closing Date 2002-07-02



Issue No:8
Title Do physical feature and its decomposition need to be more rigidly defined?
Background Do physical feature and its decompositon need to be more rigidly defined?
Old Proposals
Current Proposals In scope, done.
Outcome In version 3.0, the property:
E19 Physical Object. is composed of (forms part of): Physical Object
has been redirected to:
    E18 Physical Stuff. is composed of (forms part of): Physical Stuff In order to include "E26 Physical Feature".

Barcelona 5/7/2001
Status done
Working Group 1
Starting Date 2001-07-05
Closing Date 2002-07-05



Issue No:9
Title How to model certainty and belief (scope and method)
Background In general, Toulmin's microarguments, the base of most CSCW system implementations, and RDF reification statements are a way to do it. Multiple instantiation of properties with beliefclasses is another way to do it.
Old Proposals
Current Proposals Out of practical scope.
Outcome No action.

Barcelona 5/7/2001
Status done
Working Group 1
Starting Date 2001-07-05
Closing Date 2002-07-05



Issue No:10
Title Revise position of E27 Site
Background The aspect of real estate objects as legal objects in a narrower sense suggests that sites are actually not only a feature of the surface of earth, but a solid portion of ground with legally defined depth etc. Therefore it may be rather an object than a feature.
Old Proposals
Current Proposals

In scope:
Issue is basically withdrawn. Change the scope note of Physical Feature to include so-called fiat objects (objects with non-natural boundaries like seas etc.).

Here my proposal to modify the scope note of E26 Physical Feature, following the action item
of the CIDOC CRM SIG meeting in Paris:

Proposed scope note:

 Features are logically or physically attached in an integral way to a particular physical object, and they share many of the attributes of physical objects. They have a non-zero one-, two- or three-dimensional geometric extent, but there are no natural borders that separate them completely in an objective way from the carrier object, as e.g. a door would be attached by hinges to a house. 
They can be features in a narrower sense, like scratches, holes, reliefs, surface colours, reflection zones in an opal crystal, a density change in a piece of wood. In the wider sense, they are portions of particular objects with partially imaginary borders, like the core of earth, a real estate on the surface of earth, a landscape, the head of a contiguous marble statue. They can be measured and dated, and we can sometimes say who was responsible for them. They cannot be separated from the carrier object, but a smaller segment of the carrier object may be identified (or sometimes removed) carrying the complete feature. Cf. Man-made features for the results of human intervention. 
  This definition implies the so-called "fiat objects" [B.Smith & A.Varzi], i.e. artificially defined objects, except for aggregates or
collections of objects. Physical Objects, in contrast, imply the so-called "bona fide objects", i.e. naturally defined objects, but also aggregates and collections of those.

Examples: The temple in Abu Simbel before its removal, my nose, Albrecht Duerer's signature on his painting of
Charles the Great, the destroyed part of the nose of the Great Sphinx in Gizeh, the door hole, but not the door being attachedby hinges.

(My examples may not all be correctly stated)

MD, January 11, 2002.

Outcome

Features are logically or physically attached in an integral way to a particular physical object, and they share many of the attributes of physical objects. They have a non-zero one-, two- or three-dimensional geometric extent, but there are no natural borders that separate them completely in an objective way from the carrier object. E.g. a door hole is a feature, but the door, being attached by hinges, is not.
They can be features in a narrower sense, like scratches, holes, reliefs, surface colours, reflection zones in an opal crystal, a density change in a piece of wood. In the wider sense, they are portions of particular objects with partially imaginary borders, like the core of earth, a real estate on the surface of earth, a landscape, the head of a contiguous marble statue. They can be measured and dated, and we can sometimes say who was responsible for them. They cannot be separated from the carrier object, but a smaller segment of the carrier object may be identified (or sometimes removed) carrying the complete feature. Cf. Man-made features for the results of human intervention. 
  This definition implies the so-called "fiat objects" [B.Smith & A.Varzi], i.e. artificially defined objects, except for aggregates or
collections of objects. Physical Objects, in contrast, imply the so-called "bona fide objects", i.e. naturally defined objects, but also aggregates and collections of those.

Examples: The temple in Abu Simbel before its removal, my nose, Albrecht Duerer's signature on his painting of
Charles the Great, the destroyed part of the nose of the Great Sphinx in Gizeh.

Monterey 21/2/2002.

Status done
Working Group 1
Starting Date 2001-07-05
Closing Date 2002-02-21



Issue No:11
Title How to document archaeological inference chains
Background How to document archaeological inference chains, including dead ends such as failed hypotheses (scope and methodology, modelling)
Old Proposals
Current Proposals In intended scope, but out of practical scope. Interesting to do outside of standardization efforts.
Outcome No action.

Barcelona 5/7/2001
Status done
Working Group 1
Starting Date 2001-07-05
Closing Date 2002-07-05



Issue No:12
Title How to model change of classifications (comprehension)
Background
Old Proposals
Current Proposals

The issue of change of classification has been dealt with: E17 Type Assignment.
This issue should be called "how to model, when things undergo a change of nature".
In scope:
A new entity:  Transformation, subclass of End of Existence and subclass of Begin of Existence, basically terminates one object and links it directly to its new nature. The thing itself splits into two distinct instances, only linked by the transformation event. 
Alternatively, the notion of "input" and "output" of ABC Harmony could be adopted.

In Paris, October 2001, the change of nature of objects and how to model it was discussed:

  • Things may grow or change slightlty. Detailed modelling of such processes is typically not of concern for cultural heritage documentation. Typically properties acquired over time are registered summarily (e.g. being a painter, even though not from the craddle).

  • Things may change radically. This is of concern, in particular functional changes.

  • Things may be consumed completely, the only continuity lies in part of the matter being preserved.

The crucial question is, when to start talking about a new object, and if, how to make clear the notion of continuity, i.e. preservation of important characteristics beyond the mere matter. Models dealing with real growth and slight changes are by far too copmplex for the purpose of integrated information access. Typical cases to model are:

  • The object changes but preserves its nature and identity, e.g. replacement the hard disc of a computer. This is modelled as E11 Modification. 

  • The object ceases to exist, becaused it has been destroyed or consumed completely. E.g. a building used as quarry. This is modelled by the property "used object". The object itself ends to exist.

  • The object preserves some recognizable identity. E.g. Tutankhamun becoming a mummy, a windmill becoming a house, a piece of money becoming a piece of jewelry.

The latter should be modelled by creating a new entity instance for the resulting object. The process of transformation implies a simultaneous destruction and production. This continuity should be modelled by:

E?? Transformation
            subclass of: E64 End of Existence, E63 Begin of Existence
            transformed (was transformed by): E77 Existence
            resulted in (was result of): E77 Existence

Outcome

Proposal accepted:

E?? Transformation
            subclass of: E64 End of Existence, E63 Begin of Existence
            transformed (was transformed by): E77 Existence
            resulted in (was result of): E77 Existence

Monterey 22/2/2002.

Status done
Working Group 1
Starting Date 2001-07-05
Closing Date 2002-02-22



Issue No:13
Title Is inception distinct from creation?
Background
Old Proposals
Current Proposals Out of practical scope. Interesting question though! The need to address sequences of events (temporal and spatial) will need to be added to the issues list. In other words, the decomposition of events in a specific order allows for the distinction of inception within creation, if needed.
Outcome No action

Barcelona 5/7/2001
Status done
Working Group 1
Starting Date 2001-07-05
Closing Date 2002-07-05



Issue No:14
Title How to model 'subjects'
Background This should also comprise how to model depiction of a group, former issue 32.
Old Proposals

In scope:
See : http://www.cs.vassar.edu/faculty/welty/papers/subjects/subject.html.
This paper describes 4 alternative models, which are compliant with the CRM methodology.

IFLA FRBR, Subject Relationships:

 The "has as subject" relationship indicates that any of the entities in  the model, including work itself, may be the subject of a work. Stated in  slightly different terms, the relationship indicates that a work may be  about a concept, an object, an event, or place; it may be about a person  or corporate body; it may be about an expression, a manifestation, or an  item; it may be about another work. The logical connection between a work  and a related subject entity serves as the basis both for identifying the  subject of an individual work and for ensuring that all works relevant to  a given subject are linked to that subject.

Patrick LeBoeuf distinguishes:

The analysis (and indexing) of fine arts museum objects might result into 2 kinds of relationships:
1) "ofness" relationships vs. "aboutness" relationships
2) Erwin Panofsky's categorizations: "pre-iconographic" indexing /
"iconographic" indexing / "iconologic" indexing.

As I tried to explain in my paper, librarians have constantly mistaken "object" relationships for "subject" relationships; as long as they only dealt with books, it was not very problematic, but from the moment they strove to catalog still pictures and objects the same way, the whole thing became an indescribable mess... I think librarians shouldn't pass on this mess to the CRM community!"

Proposal, Monterey Feb. 2002:

The CIDOC CRM should model only the aboutness relationship.

Should be covered by decision on P67 refers to, issue 86

Current Proposals

Create new link E 28 Conceptual Object: is about E1 CRM Entity, sub property of P67

MD 20/6/2002

Outcome

Proposal 1: The CIDOC CRM should model only the aboutness relationship. Should be covered by decision on P67 refers to (see Issue 86). Decision: Proposal rejected

Proposal 2: Create new link E73 Information Object: is about (is subject of) E1 CRM Entity, sub-property of P67.

Proposal accepted, Copenhagen 2/7/2002.

Status done
Working Group 1
Starting Date 2001-07-05
Closing Date 2002-07-02



Issue No:15
Title Is title different from appellation?
Background Is there any characteristic feature of the character string that represents title, which makes it different from appellations in general? The idea would be, that titles can be reasonably translated, but names in general not. Therefore they convey more meaning than just a reference. Is that true, and is that enough to justify the existence of a Title entity?
Old Proposals
Current Proposals It is enough. The library community has well-defined notions of what a title is.
Outcome Issue closed. There is a need to distinguish between these. A new issue needs to be added to draft guidance for museums etc. to distinguish between titles and other appellations. Working Group 4. Issue 71.

Barcelona 5/7/2001
Status done
Working Group 1
Starting Date 2001-07-05
Closing Date 2002-07-05



Issue No:16
Title Which terminology should we use?
Background There is a problem of consistency of the vocabulary used in the CRM definitions. Which standards or good practice should we adhered to? Is the intuitive understanding by layman important, should one of the many terminologies from Computer Science or that from W3C be used?
Old Proposals
Current Proposals

In scope. Working Group 3.

Check ISO 2382, if applicable.

Partial decision:

The CRM will not attempt to be compatible with ISO 2382. It is not consistently used within ISO and it does not represent the language commonly used within the community. Copenhagen 3/7/2002.

Other terminologies are still sought to adhere to.

Outcome

Use RDF-like terminology as in version 3.3.2. Use more verbose explanations as provided in revised Introductory for version 3.3.2. Words shown in bold, including "extension", "intention" "strict inheritance" and "multiple inheritance", further "instance",  "shortcuts", “perdurants”, “monotonic”, “open world”, “disjoint”, “primitive”, “complement” and “endurants”, "query containment", "symmetric", "interoperability" and "semantic interoperability" to be added to the list of defined terminology. Talk about "super-property" and "sub-property", not super-class and sub-class in case of properties. Rename “Cardinality Constraints” into “Property Quantifiers”. Add “property quantifiers” to the Terminology. This will help to avoid misunderstandings. Add those to the list of defined terminology.

Proposal accepted

Rethymnon 22/10/2002

Status done
Working Group 3
Starting Date 2001-07-05
Closing Date 2002-10-22



Issue No:17
Title How to visually distinguish examples drawn from subclasses within scope notes of a superclass
Background
Old Proposals
Current Proposals In scope. Working Group 3.
Outcome Examples included in the scope note of an entity should be annotated with the number of the appropriate subclass, of which it is also an instance of.
Status done
Working Group 1
Starting Date 2001-07-05
Closing Date 2001-10-18



Issue No:18
Title Should there be a new name for the CRM?
Background
Old Proposals
Current Proposals The Title is CIDOC CRM. CRM by itself is not distinctive enough. To check, if the name part CIDOC is acceptable to ISO.
The full title does not need to be translated literally into other languages (the example of translating film titles was given.). Issue to be formally decided by the SIG.
SIG members are called to propose titles in their local languages.
Outcome
Status open
Working Group SIG
Starting Date 2001-07-05
Closing Date In Progress



Issue No:19
Title How is the CRM going to be used ?
Background
Old Proposals

In scope:
In the discussion in Paris, October 2001, the following subjects were identified. The issue is regarded to be finished, if this has been formulated in a comprehensive article:

  • Data integration – Data warehouse applications
    • Data pump
  • Query mediation – integrated access
  • Data migration
  • Aids to good practice
    • Design – validation of data structures
    • Intellectual
    • Communication
  • Archiving and preservation in a stable format of long-term validity

Beyond search of equivalent items across museums, libraries and archives, as envisaged by Dublin Core, the CRM should enable the COMPLETION of information from disparate sources kept in these organisations. Besides others, this will help to find stories in our flat mass data.

In Monterey, February 2002, it was proposed to write an article about the experience of RLG and the Germanische Nationalmuseum Nuremberg using the CIDOC CRM.


Monterey 20/2/2002.

Current Proposals

Include discussion of use in Introductory Text (before section on Formalism), immediately after scope statement.

Rethymnon 22/10/2002

Outcome
Status open
Working Group 2
Starting Date 2001-07-05
Closing Date In Progress



Issue No:20
Title How to model legal items
Background How to model legal items such as rights, their validity, creation and type, application and enforcement?
Old Proposals
Current Proposals Out of practical scope.
Outcome No Action

Barcelona 5/7/2001
Status done
Working Group 1
Starting Date 2001-07-05
Closing Date 2002-07-05



Issue No:21
Title How to model membership entity, with temporal properties
Background How to model acquisition of citizenships and other memberships.
Old Proposals
Current Proposals In scope. Decision to depend on if such data structures are used at English Heritage. Else see issue 23.
Outcome Dealt with by solution to issue 23.

Proposal accepted, Copenhagen 2/7/2002.
Status done
Working Group 1
Starting Date 2001-07-05
Closing Date 2002-07-02



Issue No:22
Title How to deal with implementation guidelines
Background Implementation guidelines may be handled as a sort of a manual. This would imply a relatively clearly defined scope and methods. It could be handled as a collection of examples. It could further be handled as a news group, and a sort of a portal to respective sites, literature, experiences. Implementation guidelines are closely connected to compatibility predication.
Old Proposals
Current Proposals

In scope. Working Group 4.

Define the method and scope of implementation guidelines.

In Monterey, Feb. 2002 it was proposed to separate:

1. Contents questions such as "How to deal with person names"
2. Using the CRM as schema
  for RDFS, RDBMS, O-O DBMS, XML DTD, XML Schema
3. Compatibility notion.

For point 1, such questions should be systematically gathered.

Monterey 20/2/2002.

Outcome
Status open
Working Group 4
Starting Date 2001-07-05
Closing Date In Progress



Issue No:23
Title Where does temporal validity fit in with short cuts and indirection?
Background This is a knowledge representation question.Where does temporal validity fit in with short cuts and indirection? Examples are the properties "current location", "former/current location" etc., where the temporal properties in the short cut entity are lost. Another question is, how a general indirection mechanism should be devised in order to add temporal validity to any property.
Old Proposals
Current Proposals

In scope. Working Group 4.

A guideline should be created describing a general extension mechanism compatible with the CRM, which provides temporal validity to any attribute. The attribute becomes short cut of the temporal entity describing the range of validity.

This should cover in general the issue 21.

Outcome  Proposal accepted, issue open until guideline is available. (group 4).
Status open
Working Group 4
Starting Date 2001-07-05
Closing Date In Progress



Issue No:24
Title Review of production/creation
Background
Old Proposals
Current Proposals Out of practical scope. See issues 34, 36.
Outcome No action.

Barcelona 5/7/2001
Status done
Working Group 1
Starting Date 2001-07-05
Closing Date 2002-07-05



Issue No:25
Title How to model a physical documents class (e.g. books)
Background
Old Proposals
Current Proposals In scope.
Outcome This is part of issue 7.

Paris 18/10/2001.
Status done
Working Group 1
Starting Date 2001-07-05
Closing Date 2001-10-18



Issue No:26
Title How to model handling of process phases
Background
Old Proposals
Current Proposals Out of practical scope. Issue 34.
Outcome No action.

Barcelona 5/7/2001
Status done
Working Group 1
Starting Date 2001-07-05
Closing Date 2002-07-05



Issue No:27
Title Definition of the minimum scope for standardisation
Background In the meeting of the Documentation Standards Group in Ottawa it was suggested, that the scope of the CRM is better defined against a series of existing standards, de facto standards or other relevant formats. In that sense, we are looking here for proposals about which standard to include in the scope. Nevertheless, also theoretical contributions are welcome.
Old Proposals
Current Proposals A specific document identifies the scope.
Outcome Document has been completed. Will be voted on at plenary session in Paris.

Barcelona 5/7/2001
Status done
Working Group 1
Starting Date 2001-07-05
Closing Date 2002-07-05



Issue No:28
Title How to organize outreach: collaboration, teaching and training, transfer of know-how
Background Discussion thread needed for outreach issues: collaboration, teaching and training, transfer of know-how. Proposals for methods are looked for here.
Old Proposals
Current Proposals

In scope. Working Group 4.

Adopt CHIOS Dissemination Plan. Develop training plan. 

Outcome
Status open
Working Group 4
Starting Date 2001-07-05
Closing Date In Progress



Issue No:29
Title How to model a person's birthplace
Background
Old Proposals
Current Proposals Through the birth event.
Outcome E21Person. (P98) was born - E67 Birth. (P7) took place at: E53 Place

Barcelona 5/7/2001
Status done
Working Group 1
Starting Date 2001-07-05
Closing Date 2002-07-05



Issue No:30
Title How to model a person's nationality
Background Three notions must be distinguished: Nationality as by birth/ provenance, nationality that can be acquired like citizenships, nationality as social characteristic
Old Proposals
Current Proposals In practical scope.

1) by birth:
E21Person. (P98) was born - E67 Birth. (P7) took place at: E53 Place, connects to place hierarchies.
E21Person. (P98) was born - E67 Birth. (P10) falls within: E4 Period, connects to political systems as periods.

2) as citizenship:
E21Person. (P107) was member of: E74 Group

3) as social characteristics:
E21Person. (P2) has type: E55 Type
Outcome

Proposal accepted. Nationality must be dealt with separately as social, legal and cultural characteristic.

How to aqcquire citizenship is a different issue (21)

Paris 18/10/2001.

Status done
Working Group 1
Starting Date 2001-07-05
Closing Date 2001-10-18



Issue No:31
Title How to model an actor's "active place"
Background
Old Proposals
Current Proposals In scope.

E31 Actor. (P14) performed - E7 Activity.(P7) took place at: E53 Place.

This solution may stretch a bit the notion of Event, implied in Activity, but does not cause any logical problems.
The CRM deliberately does not take any position about the size and granularity of events. The total of things produced can fairly be regarded as outcome of this activity. Activity may be specialized by suitable type (e.g: "painting"). This model provides the correct hook for the time-span of the activity - a context that must not be lost by any model.
Outcome Proposed solution accepted. The scope note of E7 Activity must be changed to allow also for non-targeted activities.

Paris 18/10/2001.
Status done
Working Group 1
Starting Date 2001-07-05
Closing Date 2001-10-18



Issue No:32
Title How to model the depiction of a group
Background
Old Proposals
Current Proposals In scope.
Outcome To be dealt with as part of issue 14.
Status done
Working Group 1
Starting Date 2001-07-05
Closing Date 2001-10-18



Issue No:33
Title How to model the depiction of a place
Background
Old Proposals
Current Proposals In scope. This needs to be modified to "site" - Places cannot be depicted.
Once modified this issue is complete.
Outcome No action. Depiction of Sites is covered by the CRM.

Barcelona 5/7/2001
Status done
Working Group 1
Starting Date 2001-07-05
Closing Date 2002-07-05



Issue No:34
Title How to model sequences of events (temporal or spatial)
Background
Old Proposals
Current Proposals
Outcome

Solved via issue 4.

Paris 18/10/2001.

Status done
Working Group 1
Starting Date 2001-07-05
Closing Date 2001-10-18



Issue No:35
Title Guidance for museums etc. to distinguish between titles and other appellations
Background In contrast to libraries, the notion of a title is used in museums in a fuzzy way.
Old Proposals
Current Proposals In scope.
Outcome The topic is mainly covered by issue 71. It has to become FAQ.

Monterey 22/2/2002.
Status done
Working Group 1
Starting Date 2001-07-05
Closing Date 2002-02-22



Issue No:36
Title How to model sequences of physical and conceptual objects
Background From discussion of issue 13 the need to model sequences of physical and conceptual objects also need to be added to the issues list. This could include page numbers, periodical series, acts in a play etc.
Old Proposals

Proposal to be compatible with METS.

The METS schema uses a series of nested DIV elements to represent compound digital objects. The DIV elements have an ORDER attribute, used to record an integer representation of the DIV's order with respect to it's siblings. I propose that we model ORDER as a specialization of E54 to the CRM.

However, since sequences can apply to both physical objects (e.g. folios in a manuscript) or information objects (e.g. sequences of digital page images), this proposal would require the domain of P43: Has Dimension to be promoted from E18: Physical Stuff to it's superclass, E70: Stuff.

N.B. The scope note for property P43 (CRM v3.3.1) is compatible with this proposal, although it needs to be copy-edited for grammar.

TG 26/6/2001

Current Proposals

Alternatively we could interpret the ORDER as a specific identifier, an Appellation of parts? Neither that would require a change. This is consistent with regarding spatial coordinates as identifiers.

To measure immaterial objects seems very reasonable to me, also for playing durations of video etc., see http://metadata.net/harmony/MW2002_paper.pdf.

This proposal would require the domain of P43: Has Dimension to
be promoted from E18: Physical Stuff to it's superclass, E70: Stuff.
and P39 measured (was measured by) to E70: Stuff.

MD 26/6/2002

Outcome Interpret the ORDER as a specific identifier, an Appellation of parts.
Domain of P43: Has dimension to be promoted from E18: Physical Stuff to it's superclass, E70: Stuff.
and P39 measured (was measured by) to E70: Stuff.

Copenhagen 3/7/2002.
Status done
Working Group 1
Starting Date 2001-07-05
Closing Date 2002-07-03



Issue No:37
Title Transforming activity terms into gerunds where possible
Background The term Measurement is ambiguous. Is may be the action or the result of the action. The same holds for several other activity terms.
Old Proposals

In scope. Working Group 3.

Transform activity terms into gerunds where possible:

E7 - - - - Activity (Acting)
E8 - - - - - Acquisition (Acquiring)
E9 - - - - - Move (Moving)
E10 - - - - - Transfer of Custody (Transferring Custody)
E11 - - - - - Modification (Modifying)
E12 - - - - - - Production (Producing)
E13 - - - - - Attribute Assignment (Attribute Assigning)
E14 - - - - - - Condition Assessment (Condition Assessing)
E15 - - - - - - Identifier Assignment (Identifier Assigning)
E16 - - - - - - Measurement (Measuring)
E17 - - - - - - Type Assignment (Type Assigning)
E65 - - - - - Conceptual Creation (Conceptually Creating)
E66 - - - - - Formation (Forming)
E63 - - - - Beginning of Existence (Beginning of Existence)
E67 - - - - - Birth (Giving Birth)
E12 - - - - - Production (Producing)
E65 - - - - - Conceptual Creation (Conceptually Creating)
E66 - - - - - Formation (Forming)
E64 - - - - End of Existence (Ending of Existence)
E6 - - - - - Destruction (Destroying)
E68 - - - - - Dissolution (Dissolving)
E69 - - - - - Death (Dying)

Alternatively, one could attach "event" like : "E7 Action Event".

TG, Nov 28, 2001.

Current Proposals

I prefer gerundifying or extending by "event" only those, which are ambiguous: Acquisition, Modification, Measurement, Creation, Formation, Production.

MD, January 2002.

Outcome

Rename:

E7 Acquisition Event, 
E11 Modification Event, 
E16 Measurement Event,
E65 Creation Event,
E 66 Formation Event,
E12 Production Event.

Monterey 21/2/2002.

Status done
Working Group 1
Starting Date 2001-07-05
Closing Date 2002-02-21



Issue No:38
Title Delete Gender
Background
Old Proposals
Current Proposals The entity Gender is not needed, as it can completely be covered by
E21 Person. (P2) has type: E55 Type
and there is nothing more important about gender than about any other properties giving rise to a set of people. Delete E76 Gender, P61 has gender.

In scope. Decision to be connected to general handling of types, issue 50
Outcome

Delete E76, P61. 

Monterey 22/2/2002.

Status done
Working Group 1
Starting Date 2001-07-05
Closing Date 2002-02-22



Issue No:39
Title Creation of test data set for validating CRM compliance
Background Compliance may be proven by ability to export in a CRM compatible format without loss of meaning. It could be proven by providing a mapping demonstrating the lack of ambiguity. It must be elaborated, how to formulate a notion of compliance that allows for extensions in user applications, and restricts itself on the declared scope of the CRM. Compliance must be allowed for semantically "poorer" and "richer" systems.
Old Proposals
Current Proposals

In scope, Working Group 2

Check ISO 9000 certification. Elaboration of proposals has been assigned to group members.

Outcome 39
Status open
Working Group 2
Starting Date 2001-07-05
Closing Date In Progress



Issue No:40
Title Physical features should have location
Background Physical Features have only one property: Physical Object: bears feature (is found on), but no way to declare a precise location.
Old Proposals
Current Proposals Physical Feature should inherit location as declared for Physical Object from Physical Stuff.
Outcome The properties about location declared for physical object to be moved to physical stuff. Those are: P53, P54, P55.

Paris 18/10/2001.
Status done
Working Group 1
Starting Date 2001-09-17
Closing Date 2001-10-18



Issue No:41
Title Missing motivation for Man-Made Object
Background The entity Activity has two properties: "was motivation for (motivated): Conceptual Object", "motivated the creation of (was created for): Conceptual Object".
Old Proposals
Current Proposals Either use one property "was motivation for (motivated): Man-Made Stuff" or change range of "was motivation for (motivated):" to "Man-Made Object".
Outcome P18 “motivated the creation of (was created for)” changes to “motivated the creation of (was created because of)” and has a range of E71 Man-Made Stuff.
This may be the case of a war memorial.
P17 "was motivation of (motivated)" changes its range to E71 Man-Made Stuff.
This may be the case of an written order.

Paris 18/10/2001.
Status done
Working Group 1
Starting Date 2001-09-17
Closing Date 2001-10-18



Issue No:42
Title Technique Application should be subproperty of "took into account"
Background The properties of influence and motivation should be seen together in order to control their consistency.
Old Proposals
Current Proposals The property "P33 used specific technique" should be subproperty of "P15 took into account".
Outcome Proposal accepted.

Paris 18/10/2001.
Status done
Working Group 1
Starting Date 2001-10-15
Closing Date 2001-10-18



Issue No:43
Title Scope Notes for Properties
Background The need for property scope notes has also been voiced by the ABC/Harmony folks.
Old Proposals
Current Proposals

The creation of scope notes for properties was distributed to members of the SIG in Paris, October 2001. A was created before the meeting in Monterey February 2002. In this meeting, all draft scope notes were revised. A common style was proposed, and the revised scope notes (second draft ) will be reedited before the 4th CIDOC CRM SIG meeting:

The link statement should not be repeated in the first line of the scope note.
It is useful when you have a reference to a class that you have direct access to its position in the class hierarchy.
The following requirements were identified for property scope notes, to be structured in the given order:

  1. Concise definition of meaning 
  2. Usage (including "Is there a shortcut or indirection?") 
  3. References 
  4. Example 
  5. Sub/Super properties 
  6. Properties on properties 7
  7. Cardinality (one to many, many to many etc.)  

Every scope not should stand on its own without reference to another scope note. We should handle references to other properties in the same way that we would handle references to other documents. All property scope notes should be harmonized for the use of "consists of" and "falls within". Properties which are short cut by another property should mention this in their property scope note. All of the time-span links would benefit from a diagrammatic representation.

The use of Types should be described in a special chapter, rather than in a scope note.

Monterey 20/2/2002.

The revised scope notes (forth draft) as edited for the 5th meeting that will take place in Rethymnon, proof-read and including proposals until issue 113.

Outcome The final scope notes as produced by proof reading from the forth draft and correcting errors following the minutes of the fifth meeting.

Issue closed.
Status done
Working Group 3
Starting Date 2001-09-28
Closing Date 2002-10-22



Issue No:44
Title Modeling States
Background At the DELOS harmonisation meeting with ABC/Harmony in Darmstadt recently, the notion of "states" came up, and it became very clear that this central aspect of the ABC/Harmony model was not really addressed by the CRM at all. For example, how would we model an assertion that an object O was at a location X at time T? The CRM can model a change of location event, but this is not exactly the same. Do we need to be able to model states in the CRM? I don't know, but it would make harmonisation with the ABC model a lot easier, so it's certainly worth adding to the list of issues.
Old Proposals

  • Use Periods for situations and states involving the presence of people and objects(move link “participated in” and “occurred in the presence of” to Period.
  • Generalize the notion of Condition States
  • Introduce untargeted activities and situations as subclasses of Period parallel to Event.
  • Change the scope note of Event.

Proposal Monterey 22/2/2002.

Current Proposals

Situations should not be included in the CRM. Extension guidelines to be given for those dealing with Situations.

Accepted in Copenhagen 3/7/2002. Issue open until guideline exists.

Outcome
Status open
Working Group 4
Starting Date 2001-09-28
Closing Date In Progress



Issue No:45
Title Causal relation between events
Background Another issue that has come up before at least once in the CRM SIG (I believe Steve brought it up) is the modeling of causality -- to explicitly say that event E1 had some kind of causal role in the occurrence of event E2. I think that the CRM deliberately avoids this at present, favouring a more neutral and objective modeling paradigm. However, there are some causal relationships that are sufficiently unarguable that we may want to explicitly identify them: I propose that we could do this using the Property Scope Notes. For example, the scope notes for the property "destroyed" could identify it as being a causal relationship.
Old Proposals E5 Event : has caused (was caused by): Event
Current Proposals

New proposal:  Identify which existing properties imply causality and model it as common superproperty:

On the last meeting I took over to look at the handling of causal relationships between two events. So far, only the link P20 "had specific purpose" connects two event. It denotes preparatory work. This cannot be regarded as one causing the other, rather both are planned by the same actor.
So, the notion "cause" between events becomes relatively obscure. E.g. "The earthquake caused the destruction of": Are those two events, or two parts of one? Is there a notion of the earthquake as pure a pure bad spirit, causing a series of events, or is the earthquake the total of it?
I'd argue, from a practical point of view, that only long-term effects are worth modelling such sequences. In that case, I ask myself if there is always a state involved: "The earthquake destabilized the building. It broke down a year later, killing five people".

Another notion would be "John caused the destruction of..": In that sense, all active participants and all properties expressing 
effects of events on objects are "causal", like "carried out by", "destroyed"...
Another notion would be: "The killing of his father caused John to take bloody revenge". In that case, an event brings an Actor into
a state, which motivates another action of him.

As in the last earthquake in Athens, the legal decision was something like : "The construction of the building X did not follow the prescriptions. This caused the death of ten persons in the earthquake at...".

The most tangible concept I see here is the initialization of a state, which may be worthwhile modelling.

I propose to drop the issue. MD, January 2002.

Outcome Issue dropped. Monterey 22/2/2002.
Status done
Working Group 1
Starting Date 2001-09-28
Closing Date 2002-02-22



Issue No:46
Title Explanation about referring to use of materials in events and procedures
Background Often cultural documentation formats do not separate between technique and material. The CRM distinguishes between both.
Old Proposals
Current Proposals

Techniques often imply the use of specific materials, or certain materials require respective techniques. When describing a production or modfication, the CRM gives preference to the documentation of the technique, which in turn implies the use of certain materials, e.g. "gold embroidery", "gilding". Not all materials are however captured directly by the technique, or the technique does not depend on more specific choices for the material, like the purity of the gold etc. If the technique is specific, i.e. a well defined plan or procedure, then material use can be documented as part of this procedure. It may be useful to have an additional property about the individual use of material in a production or modification. (see issue below). Materials actually embedded in an object are documented for the object directly. However, not all materials end up in the product, like solvents, detergents etc.

To become a FAQ.

Outcome Accepted , Copenhagen 5/7/2002
Status done
Working Group 1
Starting Date 2001-10-15
Closing Date 2002-07-05



Issue No:47
Title Use of kinds of objects
Background The CRM does not foresee the use of a general kind of object in an activity, but only:
E7 Activity:
 P16 used object (was used for): E19 Physical Object

So events like "He rang a bell with a hammer" can not be modelled.
Old Proposals
Current Proposals E7 Activity:
 P16 used specific object (was used for): E19 Physical Object
 P?? used general object (was used for): E55 Type (Physical Object Type)
Outcome Proposal accepted, Monterey 22/2/2002.
Status done
Working Group 1
Starting Date 2001-10-15
Closing Date 2002-02-22



Issue No:48
Title Use of materials in events
Background Issue 46.
Old Proposals
Current Proposals E11 Modification:
   employed (was employed by): E57 Material
Outcome Proposal accepted, Monterey 22/2/2002.
Status done
Working Group 1
Starting Date 2001-10-15
Closing Date 2002-02-22



Issue No:49
Title How to describe the technique that connects parts
Background This refers to gluing etc.
Old Proposals
Current Proposals When two parts are connected, either a new whole is produced, or a E11 Modification of type Part Addition is performed. The Technique is described in this event. No action required.
Outcome Proposal accepted, Monterey 22/2/2002.
Status done
Working Group 1
Starting Date 2001-10-15
Closing Date 2002-02-22



Issue No:50
Title Use of the has type property
Background Users find it difficult to comprehend the meaning of Type
Old Proposals

A specific document to be prepared, which details on the theoretical background, the constraints implied by a compatible use of types and practical examples. A specific notation for referring to types equivalent to CRM entities must be developped.

The text provided by NC is good but the numbering system is confusing. Decision on numbering to be deferred until October meeting

Current Proposals I propose not to include in the formal definition of the CIDOC CRM a formal theory about the "has type" property. I believe, that a more simplistic formulation is suited better for the community we address with the standard. Nevertheless, a formal theory can provided at any time as an accompanying document.
Outcome

This is dealt with adequately in the paragraph on Types within the Introductory Text of version 3.3.2.

Proposal 2 accepted.

Rethymnon 22/10/2002

Status done
Working Group 3
Starting Date 2001-10-22
Closing Date 2001-10-18



Issue No:51
Title Mappings may depend on object type
Background Mapping of data structures to the CRM can often not be performed with the optimal precision without making the mapping dependent on object types referred in the data.
Old Proposals
Current Proposals A good practice question. Group 4 to write a document explaining this issue and giving more details on dependencies of mappings on the object types.
Outcome
Status open
Working Group 4
Starting Date 2001-10-15
Closing Date In Progress



Issue No:52
Title Where does an instance of a multimedia object appear in the CRM
Background The CRM contains an entity "Image", and "Linguistic Object". A generalization to all kinds of multimedia objects is sought.
Old Proposals An instance of a multimedia object appears in the CRM
under Information Object. Suitable distinctions can be made
by using Types. No action needed.
Current Proposals

Fig 4 in :
Jane Hunter, "Combining the CIDOC CRM and MPEG7 to Describe
Multimedia in Museums",
http://metadata.net/harmony/MW2002_paper.pdf
Museums & the Web 2002,

is regarded a compatible extension of the CIDOC CRM.

MD 20/6/2002
Outcome Proposal accepted (points 1&2) Copenhagen 3/7/2002. See issue 101.
Status done
Working Group 1
Starting Date 2001-10-15
Closing Date 2002-07-03



Issue No:53
Title How to model digital surrogates
Background Images and other digital objects are used as surrogates of the real object (or performance?). How does the CRM model this situation?
Old Proposals
Current Proposals The relationship between a digital surrogate and the object it represents is modelled by the property P70 "documents (is documented in)".
Outcome Proposal accepted, Monterey 22/2/2002.
Status done
Working Group 1
Starting Date 2001-10-15
Closing Date 2002-02-22



Issue No:54
Title Create a list of FAQs
Background Even if the documentation of the CRM may be complete enough, a list of frequently asked questions is regarded helpful.
Old Proposals
Current Proposals

All items that have been raised as an issue at any time to become part of the FAQ list, as well as questions raised in the meetings. The FAQ list will be open to specific submissions at any time.

Monterey 20/2/2002.

List of FAQs
  • The difference between "falls within" and "consists of".
  • "What does the word 'general' mean in a property name in the CRM?"
  • "How should we model sequences of moves where intermediate places are not known?"(Property P24).
  • "How does one represent ranges of values?"(P30, a Dimesion should point to an interval).
  • "What is meant by a shortcut?"
  • "How the CRM deals with parts and wholes."
  • "Why do primitive values and recursive symmetric links not have reverse labels on their properties?"
  • "What are the principles used to choose one entity as the domain of a property and the other as the range (and not vice versa)
  • "Guidance for museums etc. to distinguish between titles and other appellations". (See Issue 71)
  • "Explanation about referring to use of materials in events and procedures" (See Issue 46)
Outcome
Status open
Working Group 4
Starting Date 2001-10-15
Closing Date In Progress



Issue No:55
Title Difference between museum and library information
Background Often library and museum information is taken to be equivalent. On the other side many attempts of unification have failed in the past. The understanding of the real commonalities and differences, and the analysis of the real needs for common information access or for relating information is crucial to the mission of the CRM. The discussion has not always been conducted with the due objectivity and care in the past.
Old Proposals
Current Proposals Museum experts to start with objective formulations of the perceived differences between museum and library information and the common information needs. This could leed to a kind of Memorandum of Understanding between representatives of both sides.
Outcome
Status open
Working Group 4
Starting Date 2001-10-15
Closing Date In Progress



Issue No:56
Title Objects which are typical for a class
Background Some objects give rise to the creation of a new class. They are prototypes for this class in a historical sense. Some objects are declared to be typical for a class. They become archetypes of that class. The CRM should model these relationships between objects and classes, as they are essential for scientific and scholarly reasoning.
Old Proposals

I propose to regard any "Stuff" as a candidate for archetypical or prototypical role.
Proposal:

Stuff: was prototype of (had prototype) : Type
Stuff: is an archetype of (has as an archetype) : Type

MD, January 2002

decision postponed Monterey 22/2/2002.

Current Proposals Issue covered by Issue 76.
Outcome

Issue covered by Issue 76. :
E55 Type
  is exemplified by (exemplifies) : Entity
    (in the taxonomic role: Type)

Copenhagen 2/7/2002

Status done
Working Group 1
Starting Date 2001-10-15
Closing Date 2002-07-02



Issue No:57
Title Effort to teach use of the CRM
Background A frequently asked question is: how long does it take to learn the CRM? To answer this question, several factors have to be taken into account. The CRM is a solution for a specific technical problem - information modelling and information integration - which is taught in other contexts and has to be separated from the issue of teaching the CRM itself. It depends further from the intended use : Making contributions to the CRM is different from using it as intellectual guide, and different from transforming data into a CRM compatible form.
Old Proposals
Current Proposals

Analyse the effort to teach the CIDOC CRM in terms of conceptual modelling, data integration technique and the contents of the CRM itself. Connect this to use cases and kinds of audiences. Collect data about that from teaching experience.

In particular, material from the CRM workshop held in April 2002 on CAA2002 in Heraklion was made available.

Monterey 20/2/2002.

Outcome
Status open
Working Group 4
Starting Date 2001-10-15
Closing Date In Progress



Issue No:58
Title How to organize the translation of the model
Background We must check copyright issues set by ISO. There may be copyright questions regarding translations once the document becomes ISO copyright. We may have to ask permission if we translate it after it becomes a standard. This may be a good reason to maintain two different documents with the same content, e.g. the full standard and the implemented model.
Old Proposals
Current Proposals Translation of the model contents for application purposes and for controlling consistency of full translations can be done by MS-EXCEL on lists of entity- and property names and scope notes. Translate first entity and property names.
Outcome

Reformulated proposal: The CIDOC CRM SIG should ask for proposals for names for entities and properties in different languages in order to get lists of alternatives for the proposed translations.

Proposal accepted, Copenhagen 5/7/2002.

Status done
Working Group 1
Starting Date 2001-10-15
Closing Date 2002-07-03



Issue No:59
Title How to name the standard
Background The name of the ISO standard to become may need to be different from CIDOC CRM.
Old Proposals
Current Proposals
Outcome
Status open
Working Group 4
Starting Date 2001-10-15
Closing Date In Progress



Issue No:60
Title Identify new communities for collaboration
Background Identify new communities to collaborate with for validation and harmization of the CIDOC CRM. Currently, we communicate with the libraries community. A contact to OpenGIS has been established. There should be formal contact with representatives of the archivists community. Other communities should be identified.
Old Proposals
Current Proposals
Outcome
Status open
Working Group 4
Starting Date 2001-10-15
Closing Date In Progress



Issue No:61
Title Do we need a property "is copy of" ?
Background Currently, the CRM uses the property "P15 took into account" to declare a relation between a product and a prototype. The property "P16 used object" can be used for tools as well as molds. May be the notion of a copy needs a stronger declaration in the CRM. There are two notions of copy: The relation between a manifestation and an item, and the relation between a physical prototype and the "copy", as e.g. the Roman copies of Greek statues.
Old Proposals
Current Proposals

Stuff
       shows features of (features are also found on): Stuff
            (kind of similarity: Type) 

This prperty generalizes the notion of  "copy of" and "similar to" into a dynamic, assymetric relationship, where the domain expresses the derivative, if such a direction can be established. Else the relationship is symmetric. It is a short-cut of P15 took into account in a creation or production, if such a  reason of the similarity can be verified. Moreover it expresses similarity, which can only be stated between two objects without historical knowledge about its reasons.

The link P15 should change range to "Stuff", as physical objects can also be intellectual sources. I prefer this over extending P16 to be used only in an intellectual sense.

MD, 20-5-2002

Outcome

This relation is needed.

Stuff: P132 shows feature of (features are also found on): Stuff
(kind of similarity: Type)

Proposal accepted, Copenhagen 2/7/2002.

Status done
Working Group 1
Starting Date 2001-10-15
Closing Date 2002-07-02



Issue No:62
Title Do we need an Actor Appellation entity?
Background Are there specific name forms for kinds of actors, like company registration numbers etc.? Then an Actor Appellation entity would be justified.
Old Proposals

We could not find any specific naming or registration practice, which may appear in cultural documentation or library documentation
for Actors. I propose to drop the issue.

MD 20/6/2002

Current Proposals

AACR2 (Anglo-American Cataloging Rules, 2nd Edition) is a very detailed and commonly-used practice for structuring actor names.

There are also a number of authorities for actor names in use in the museums, libraries and archives sectors, e.g. Library of Congress Name Authority File, Union List of Artists Names etc.

http://www.loc.gov/marc/authority/ecadintr.html
http://lcweb.loc.gov/marc/bibliographic/ecbdmain.html
http://www.getty.edu/research/tools/vocabulary/ulan/index.html

In addition, there are a number of culturally-based initiatives and projects currently seeking to address shared authority files for actor names (e.g. Encoded Archival Context, LEAF etc.)

I counter-propose that we do in fact add Actor Appellation to the CRM.

TG 21/6/2002

Outcome

Actor Appellation to be added to the CRM. Distinctions between people and corporate bodies to be made by use of Types

Proposal accepted 2 Copenhagen 3/7/2002.

Status done
Working Group 1
Starting Date 2001-10-15
Closing Date 2002-07-03



Issue No:63
Title Does the Appellation need a value property?
Background
Old Proposals
Current Proposals

The Appellation is the string itself, as it does not have any identification different from its value. Therefore it does not need an additional value property. This should be reflected in the scope note.

Proposal for new scope note:

E41 Appellation

Scope note: This entity comprises all names in the proper sense. Codes or words, meaningless or meaningful, in the script of some group or encoding of an electronic system, used solely to identify a specific instance of some category within a certain context. These words do not identify the object by their meaning but by convention, tradition or agreement. In contrast to other entities an instance of Appellation is not an identifier for a real world entity different in nature from it, but it is the appellation itself. E.g. an Appellation "Martin" does not refer to any Martin, but is nothing else than the name "Martin" itself. Therefore there is no property pointing to any value of it. Appellation should not be confused with the practice of naming a thing by some group over a certain period. 

MD, January 2002

Outcome Proposal accepted, Monterey 21/2/2002.
Status done
Working Group 1
Starting Date 2001-10-15
Closing Date 2002-02-21



Issue No:64
Title The definition of Number is too narrow
Background Reasonable values for dimensions in the cultural heritage area can be more complex than defined in the CRM
Old Proposals
Current Proposals

Extend the scope note of E60 Number to any encoding of a computable value:

Scope Note: This entity comprises any encoding of computable (algebraic) values like integers, reals, complex numbers, vectors, tensors etc. They are fundamentally distinct from identifiers in continua, like dates and spatial coordinates, even though their encoding may be similar. Whereas numbers can be combined with numbers to yield numbers in algebraic operations, identifiers in continua are combined with numbers expressing distances to yield identifiers. Instances of entity Number are the encoding itself, in contrast to the real world quantity measured by them. So one real world quantity can be measured by different numbers, based on the system of units and the procedure. E.g. 100 Greek Drachme are equal to 340.447 Euro. Examples: 5, 3+2i, 1.5e-04, (0.5,-0.7,88)

MD, January 2002

Outcome

Scope Note: This entity comprises any encoding of computable (algebraic) values like integers, reals, complex numbers, vectors, tensors etc., including intervals of those values to express limited precision. They are fundamentally distinct from identifiers in continua, like dates and spatial coordinates, even though their encoding may be similar. Whereas numbers can be combined with numbers to yield numbers in algebraic operations, identifiers in continua are combined with numbers expressing distances to yield identifiers. Instances of entity Number are the encoding itself, in contrast to the real world quantity measured by them. So one real world quantity can be measured by different numbers, based on the system of units and the procedure. E.g. 100 Greek Drachme are equal to 340.447 Euro. Examples: 5, 3+2i, 1.5e-04, (0.5,-0.7,88)

Monterey 21/2/2002.

Status done
Working Group 1
Starting Date 2001-10-15
Closing Date 2002-02-21



Issue No:65
Title Implementation guidelines for compounds
Background Compound values are values which are represented by a characteristic set of related data elements, which all together make up one value. Such are postal addresses of houses, species names in biology, 3D-coordinates etc. From an ontological point of view, one value must be represented as one instance of a suitable class. Often however the compound contains hierarchical higher order information, like street, city, genus etc. As this is a frequent encoding problem, a guideline would be helpful.
Old Proposals
Current Proposals
Outcome
Status open
Working Group 4
Starting Date 2001-10-15
Closing Date In Progress



Issue No:66
Title Define exclusivity between CIDOC CRM entities
Background The CRM foresees unconstraint multiple instantiation of any combination of entities. This makes not always sense, E.g. Stuff and Temporal Entity should never share instances. The same constraints hold for multiple inheritance.
Old Proposals
Current Proposals

Define exclusivity of entities at the appropriate level, e.g. in the scope note or as a formal construct.

I propose to introduce a formal construct: "disjoint with: CRM Entity". This should be listed before the scope note, and after the "superclass of" statement. E.g.:

E2 Temporal Entity
(former E2 Period, former E2 Things Having Time -Span)

Belongs to:

Period Type

Subclass of:

CRM Entity

Superclass of:

Condition State
Period

 

Disjoint with:

Existence
Place
Dimension
Type
Primitive Value

 
 
 
 

It means, that instances of the first argument cannot be instances of the second and vice a versa. "disjoint with" is symmetric and inherited. I.e. disjointness holds for any combination of a subclass of the first argument with a subclass of the second. It disallows multiple inheritance (multiple isA) between any subclasses of the two arguments.

Outcome

Proposal accepted. The notion of "disjoint" to be explained in the introduction.

Monterey 22/2/2002.

Status done
Working Group 1
Starting Date 2001-10-15
Closing Date 2001-10-18



Issue No:67
Title How to model birth of living beings in general
Background The scope note for E67 Birth currently reads "The birth of a human being." The scope of BIRTH could be usefully extended to included other life forms. Date of birth, place of birth, parentage are often recorded by zoological collections in "stud books", particularly for endangered species. Information on date, place and circumstances of birth ("hatch date" for birds) may also be a legal requirement for import and export of live specimens.
Similar information is recorded by botanical gardens for their specimes: date of planting, date of germination, etc. Software packages offer fields to record this sort of information, e.g. BG-BASE uses "sowing date" and "germination date(s)" as part of the "propogations" table.
Extending the scope of E67 will require modification of the properties. Parents are currently assumed to be instances of E21 PERSON :-
by mother (gave birth): Person
from father (was father for): Person.

It might therefore be preferable to create separate sub-classes for the beginning of existence of various types of biological entitites.
References :
"Guidelines for Data Entry and Maintenance of North American Regional Studbooks", Lincoln Park Zoo, 1996
URL http://www.aza.org/dept/csd/studguide.htm
URL Scott Swengel and Tori Kaldenberg : "North American Red-Crowned Crane Grus japonensis Studbook 2000", 2000
http://www.savingcranes.org/library/FixedSBfinalX.PDF
"DECREE of the Ministry of the Environment conditions for importing and exporting endangered species", Czech Republic, 1997 URL
http://www.env.cz/www/laws/cites2.nsf/a9f88a6e7295c630c125656e004d9786/faff78693c994a23c12566c2003507af?OpenDocument
Michael Foster, Greg Kleine, and Jaroy Moore "Impact of Seeding Rate and Planting Date on Guayule Stand Establishment by Direct Seeding in West Texas"
URL http://www.hort.purdue.edu/newcrop/proceedings1993/v2-354.html
BG-BASE URL http://www.rbge.org.uk/BG-BASE/tables.htm
Old Proposals
Current Proposals

In the Monterey Meeting, 22/2/2002., in presence of Natural History experts, it was proposed:

The birth of living beings in general is sufficiently covered by the entity Begin of Existence.

Outcome The birth of living beings in general is sufficiently covered by the entity Begin of Existence (see issue 99).

Proposal accepted, Copenhagen 2/7/2002.
Status done
Working Group 1
Starting Date 2001-10-15
Closing Date 2002-07-02



Issue No:68
Title How to model isA relations between types
Background In the light of formalizing better the relation between Types and CRM Entities, and modelling the events of inventing classification terms and systems, the definition of a property in the CRM that expresses isA semantics as the ISO2788 "BTG" relationship seems to be useful. Other relationships used for thesauri, like RT, UF etc, do not have the same relevance for the kind of reasoning the CRM intends to support.
Old Proposals
Current Proposals Introduction of a new property with "BTG" semantics:
E55 Type
has broader term (has narrower term): E55 Type
Outcome Proposal accepted, Monterey 22/2/2002.
Status done
Working Group 1
Starting Date 2001-10-15
Closing Date 2002-02-22



Issue No:69
Title Spatiotemporal overlaps of periods
Background In the discussion of temporal, spatial and spatiotemporal relationships, the question was raised which of the many possible relationships can be regarded as fundamental and worth standardizing.
Old Proposals

For spatiotemporal relationships:
It has been proposed to use only the following two spatiotemporal relationships.
Period - "overlaps with: Period", "falls within : Period" (existing)
This choice should be further justified.

In Paris I was ask to explain my position with respect to the spatiotemporal overlaps of periods. I
propose to use except for the part-whole relation and the inclusion only one more purely spatiotemporal
relationship:
"overlaps".

Here my view:
If we declare a property in the CRM, it should be clearly defined and clearly needed for the purpose
of the CRM both in functionality and in frequency of use.

From a mathematical point of view, all topological relationships can be derived from the inclusion. This may in practice be quite clumsy: E.g. in order to define an overlap we have to include the common part by both entities. So we have to define somehow artificially the overlapping part etc. So one argument is to introduce additional relationships for convenience.

Now, Periods extend over a 4-dimensional space. Such a space has no complete order, and arbitrary directions in time-space like the flight of a plane have few cultural relevance - i.e. we shall hardly find a documentation with enough data to decribe it precisely. Equally unlikely is the chance, to compare such data with others for reasoning, e.g. when the plane crashed into the building. More likely, we shall find documented relationships restricting overall time or place or both. So another argument is the complexity to handle relationships in multiple dimensions and the probability tofind data for them.

Finally, the purpose of the CRM is to facilitate resource discovery by precise descriptions. More specialized relationships can be replaced by simpler ones, which preserve recall. E.g. instead of seeking the plane that crossed Halifax at 16:00, I can search for planes on the route over Halifax within +/- 8 hours. This will return more planes than I needed, but it will include the candidates.

Temporal bounds are typically rich and with good precision in cultural documentation. The fact, that time is one-dimensional makes comparison easy. Therefore we have already decided on the relatively rich temporal relationships by Allen, which can be regarded as a standard in Knowledge Representation and are well studied and well-understood:

before (after) : E2 Temporal Entity
meets in time (met-by in time): E2 Temporal Entity
overlaps in time (overlapped-by in time): E2 Temporal Entity
during (includes): E2 Temporal Entity
starts (started-by): E2 Temporal Entity
finishes (finished-by): E2 Temporal Entity
equal in time: E2 Temporal Entity

All those are also available for Periods to describe the extent in time via inheritance.

Spatial relationships already deal with 2 or 3 dimensions. We have decided in Paris to use:
E53 Place - "borders with: E53 Place", "overlaps with: E53 Place".

Those have a high frequency in our data. Countries etc. have borders, modern districts may overlap with ancient ones etc. Reasoning and retrieval based on these is straightforward. One could introduce direction, like "north of" , distances etc. Reasoning and retrieval of such data exceeds the capabilities of usual applications. Of course GIS can deal with that. On the other side, if I look for some places being "north of" a known one, I can determine the area by hand and post a query on that base. Therefore we have decided in Paris, that the above spatial relationships together with inclusion are sufficient and appropriate for the CRM.

These spatial relationships are available to describe related periods. Hence, Periods can be restricted in time and in space by the above relationships. What else do we need?

As Periods can spread out over time and space in a "non-rectangular shape", i.e. not constant for a certain time-span at some spatial borders, even two Periods in the same time and space "box" need not overlap. Let us think for instance of some fashion movement coming from the US to Europe, and before it ends in Europe, another movement in the US has already taken over. A purely spatiotemporal overlap, which cannot be decomposed into spatial and temporal overlaps, is relatively rare, but difficult to be described
otherwise. It is also culturally relevant, because we can fairly assume mutual influences, or wonder why these periods behave independently.

Therefore I have proposed to include the pure spatiotemporal overlap as relationship for the CRM. All other purely spatiotemporal relationships I regard as too complex for a standard.

I could only imagine one more relevant relationship between Periods: "follows". Imagine a situation as with the fashion movement above. There is no overall temporal sequence, but at any individual place, the second period "follows (is followed by)" the first. This would be a complement to the spatial "borders with", and a refinement of the temporal "meets", relative to the various points in the respective area a period is active.

MD, January 2002.

Current Proposals

In Monterey, it was proposed to introduce two more properties:

Period - "overlaps with: Period", 
Period - "is separated from: Period", 
Period - "falls within : Period" (existing)

Monterey 22/2/2002.

Outcome Proposal accepted, Copenhagen 3/7/2002.
Status done
Working Group 1
Starting Date 2001-10-15
Closing Date 2002-07-03



Issue No:70
Title Relationship between P15 took into account and P17 was motivation for
Background P17 "was motivation of (motivated)" and "P15 took into account" seem to share some meaning. This should be clarified.
Old Proposals

I propose a new and more general property:

Pnn Activity - was influenced by (influenced) Persistent Item

This would subsume:

P15 Activity - took into account (was taken into account by) Conceptual
Object
P17 Activity - was motivated by (motivated) Man-Made Stuff (why not
Stuff?) (issue 79)

It would also resolve issue 79: Change Property Name P17 was motivation
for to was motivated by

TG 23/6/2002

Current Proposals

redefine range of:
P15 Activity - took into account (was taken into account by): Persistent Item
I take "took into account" as synonym to "influenced by", as the Actor of the
activity "must let it influence her/him".

redefine range of:
P17 Activity - was motivated by (motivated): Stuff ,

declare P16,P17 as subproperty of P15.

This complements the existing links:
P19 Activity - was intended use of (was made for) Man-Made Stuff
P16 Activity - used specific object (was used for) Stuff (issue 96)

I propose to either add:
Pxx Activity - was influenced by (influenced): E7 Activity

and declare
P18 Activity - was motivation of (motivated) : E7 Activity subproperty of Pxx

Or to generalize P18 into "was influenced by".


The link P20 corresponds to P19:
P20 Activity - had specific purpose (was purpose of) : E7 Activity
(intention, future)

Do we need an equivalent to P16 ?:
Pyy Activity - continued (was continued by) : E7 Activity

To my understanding, this is all that could be said about
influence between activity and stuff, and between activities.
It seems to me complete and symmetric.

MD 26/6/2002

Outcome P15 Activity was influenced by (influenced) E1 Entity

P17 Activity was motivated by (motivated) E1 Entity
P19 Activity was intended use of (was made for) Man-made Stuff
P16 Activity used specific object (was used for) Stuff

P20 Activity had specific purpose (was purpose of) E7 Activity
Pxx Activity continued (was continued for ) E7 Activity

Delete P18 Activity was motivation of (motivated) E1 Entity because it is subsumed by P17.

P16, P17, P19, P20 and Pxx are sub-properties of P15.

Scope note comment (for Pxx): If one activity is continued by another it would be possible to regard both activities as part of a larger one.

Proposal accepted, Copenhagen 3/7/2002.
Status done
Working Group 1
Starting Date 2001-10-15
Closing Date 2002-07-03



Issue No:71
Title Guidance to distinguish between titles and other appellations
Background Issue 15: There is a need to distinguish between Title and Appellation. A new issue needs to be added to draft guidance for museums etc. to distinguish between titles and other appellations. Working Group 4. The scope note for Title should be reformulated.
Old Proposals
Current Proposals E35 Title
[** Current Scope Note **]
This entity comprises the short pieces of texts that are used, by the creator or tradition, to characterize or identify a work, often alluding to its subject. The work may be linguistic, musical, iconographic or other.

Examples: Giaconda, La Joconde, Mona Lisa, Die Dreigroschenoper, La Pie,  La Marseillaise. 

[** Proposed revised Scope Note **]
The name of a work, such as a book, artwork or piece of music.

Examples: The Merchant of Venice, Giaconda, La Joconde, Mona Lisa, Lucy in the Sky with Diamonds.

Titles are proper nouns, and should not be confused with generic object names (such as chair, painting, book) which are common nouns and are modelled in the CRM as instances of E55 Type.
Outcome

The name of a work, such as a textual work, artwork or piece of music.

Examples: The Merchant of Venice, Giaconda, La Joconde, Mona Lisa, Lucy in the Sky with Diamonds.

Titles are proper nouns, and should not be confused with generic object names (such as chair, painting, book) which are common nouns and are modelled in the CRM as instances of E55 Type.

Monterey 21/2/2002.

Status done
Working Group 1
Starting Date 2001-10-15
Closing Date 2002-02-21



Issue No:72
Title Scope note of Modification
Background

The scope note of E11 Modification refers only to intentional modifications. That seems to be too narrow.

E11 Modification Event

Belongs to: Period Type
Subclass of: Activity
Superclass of: Production

Current Scope Note:
This entity comprises all activities which intentionally alter physical objects, regardless of the degree of intervention: creation of some item from raw material, restorations, use of ancient objects in jewelry, etc.. Since many cases the distinction between modification and creation is not clear, and the actions implied are basically the same, modification is regarded as the more general (and less ambiguous) concept. This implies that some items may be consumed or destroyed in a modification process, and others emerge from it. Typically, objects involved in the process, such as tools, materials, etc., which are foreseen by the applied technique are modeled as attributes of the Design or Procedure, for reasons of efficient data representation. Nevertheless, unusual and remarkable items used for a specific instance of a process should be referred to here.

This entity is thought to be collective, e.g. the printing of a thousand books should be one event. Conservation actions can be modeled as a type of modification.

Old Proposals
Current Proposals

New scope note:

This entity comprises all activities that alter or change physical man-made objects. Examples of modification events include the creation of an item from raw materials, the restoration or conservation of an object, or the re-use of an ancient object in the creation of a new object. This entity can be collective; the printing of a thousand books, for example, would normally be considered as a single event.

Since the distinction between modification and creation is not always clear, modification is regarded as the more generally applicable concept. This implies that some items may be consumed or destroyed in a modification event, and that others may be created as a result of it. Typically, objects routinely involved in the modification event, such as tools or materials, are modeled as attributes of the Design or Procedure for efficient data representation. However, unusual and remarkable items or materials used for a specific instance of a modification event should be associated with the modification event.

Outcome

New scope  for E11 Modification Event:

This entity comprises all activities that alter or change physical man-made objects. Examples of modification events include the creation of an item from raw materials, the restoration or conservation of an object, or the re-use of an ancient object in the creation of a new object. This entity can be collective; the printing of a thousand books, for example, would normally be considered a single event.

Since the distinction between modification and creation is not always clear, modification is regarded as the more generally applicable concept. This implies that some items may be consumed or destroyed in a modification event, and that others may be created as a result of it. Typically, objects routinely involved in the modification event, such as tools or materials, are modelled as attributes of the Design or Procedure for efficient data representation. However, unusual and remarkable items or materials used for a specific instance of a modification event should be associated with the modification event.

Proposal accepted, Copenhagen 3/7/2002.

Status done
Working Group 1
Starting Date 2001-10-15
Closing Date 2002-07-03



Issue No:73
Title Scope and Name of Existence
Background
Old Proposals
Current Proposals E77 Existence

E77 Existence encompasses (and thereby isolates) entities which share two attributes: having the potential to exist over a period of time, and having persistent identity during this period of existence. These attributes are intended to apply to both concrete objects, whether animate or inanimate and to ideas or concepts. Hypothetical or imaginary objects fall within this category insofar as they can be considered as conceptual objects i.e. E77 Existence is not intended to be restricted to physical existence.

The conditions under which an object can be deemed to maintain its identity are often difficult to establish - the decision depends largely on the judgement of the observer. Most people would agree, for example, that a building ceases to exist if it is dismantled and the materials reused in a different configuration. Human beings, on the other hand, in common with many other organisms, go through radical and profound changes during their life-span, affecting both material composition and form, yet preserve their identity. Identity in these cases would seem to depend more on continuity rather than the presence of any particular physical state or component.

The main classes of objects which fall outside the scope E77 Existence are temporal objects such as periods, events and acts, and descriptive properties, (such as materials) which function as adjectives and adverbs. The former may have persistent identity but are excluded primarily to avoid the possibility of a meaningless regression of beginning and ending periods of periods , the later because they have no real identity, or, to be more precise, their identity is of no interest in the present context.

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

Remarks:
The name *Existence" is confusing and may be need to be changed. It contravenes the general requirement of the ISA hierarchy that sub classes may be described by the form "X is a Y". "Stuff is an Existence", for example, stretches comprehension into the realms of speculative metaphysics. Placing the accent on persistent identity rather on existence may provide an acceptable alternative: "Persistent Item", for example, or possibly just "Thing". However, this would appear to create some overlap with the E70 Stuff (cf scope note). I would suggest renaming E70 Stuff to emphasise the notion of potential use, (which is the only attribute introduced by this entity) "Useable Thing", perhaps. Apart from being disarmingly colloquial the term 'stuff' is arguably inappropriate since the scope note clearly indicates that the entity is intended to encompass 'items' - the word "stuff" suggests (at least to me) undifferentiated material rather than persistent, identifiable and useable items.

NC 18 January 2002
Outcome

E77 Existence

E77 Existence encompasses (and thereby isolates) entities which share two attributes: having the potential to exist over a period of time, and having persistent identity during this period of existence. These attributes are intended to apply to both concrete objects, whether animate or inanimate and to ideas or concepts. Hypothetical or imaginary objects fall within this category insofar as they can be considered as conceptual objects i.e. E77 Existence is not intended to be restricted to physical existence.

The conditions under which an object can be deemed to maintain its identity are often difficult to establish - the decision depends largely on the judgement of the observer. Most people would agree, for example, that a building ceases to exist if it is dismantled and the materials reused in a different configuration. Human beings, on the other hand, in common with many other organisms, go through radical and profound changes during their life-span, affecting both material composition and form, yet preserve their identity. But also material objects in daily use also undergo material changes due to maintenance etc. without changing identity. Identity in these cases would seem to depend more on continuity rather than the presence of any particular physical state or component.

The main classes of objects which fall outside the scope E77 Existence are temporal objects such as periods, events and acts, and descriptive properties, (such as materials) which function as adjectives and adverbs. The former may have persistent identity but are excluded primarily to avoid the possibility of a meaningless regression of beginning and ending periods of periods , the later because they have no real identity, or, to be more precise, their identity is of no interest in the present context.

Rename E77 Existence into E77 Persistent Item.

Monterey 21/2/2002.

Status done
Working Group 1
Starting Date 2001-10-15
Closing Date 2002-02-21



Issue No:74
Title Collections have no owner
Background On implementing the new Collection entity, recognized that the ownership and custody links refer only to Physical Object.
Old Proposals
Current Proposals Now, once we regard Collections as non-objects in general, including sites and features, by sure they should by owned and kept. For Features in general I ask myself if "custody" makes sense. Probably yes, even though the keeper has to move to the site, rather than the object to the keepers facilities. An excavation site may have a keeper, as well as some rock paintings. So I propose to raise the domain of the ownerhip and custody links to Physical Stuff.
MD, 18 January 2002
Outcome Proposal accepted, Monterey 22/2/2002.
Status done
Working Group 1
Starting Date 2002-01-18
Closing Date 2002-02-22



Issue No:75
Title Rename E72 Stuff
Background The name "Existence" is confusing and may be need to be changed. It contravenes the general requirement of the ISA hierarchy that sub classes may be described by the form "X is a Y". "Stuff is an Existence", for example, stretches comprehension into the realms of speculative metaphysics. Placing the accent on persistent identity rather on existence may provide an acceptable alternative: "Persistent Item", for example, or possibly just "Thing". However, this would appear to create some overlap with the E70 Stuff (cf scope note). 
Old Proposals
Current Proposals I would suggest renaming E70 Stuff to emphasise the notion of potential use, (which is the only attribute introduced by this entity) "Useable Thing", perhaps. Apart from being disarmingly colloquial the term 'stuff' is arguably inappropriate since the scope note clearly indicates that the entity is intended to encompass 'items' - the word "stuff" suggests (at least to me) undifferentiated material rather than persistent, identifiable and useable items.
NC 18 January 2002
Outcome

1. Proposal to rename "E77 Existence" as "E77 Persistent Item" accepted.
2. Proposal to rename "Stuff" rejected. There seems not to be any alternative term that may be closer to the intended meaning.

Monterey 21/2/2002.

Status done
Working Group 1
Starting Date 2002-01-18
Closing Date 2002-02-21



Issue No:76
Title Contemporary Naming Procedure
Background

The discussion in Monterey, Feb. 2002 about Natural History requirements for the CIDOC CRM identified the following:

Documentation structures for Natural History can be separated into ordinary collection management issues and the taxonomic discourse. The first seems to be covered completely by the CIDOC CRM version 3.2.

Of particular interest is the field collection information of specimen - location, habitat etc., and ecosystem level observations. Formalization of the latter (ecosystem structure) seems however to be beyond the practical scope of the CRM.

The taxonomic discourse can be separated into taxon creation, naming conventions and identification procedures. The group felt, that the taxonomic discourse of Natural History is very similar to that in archaeology, to a degree that virtually all underlying concepts can be found in both domains. However, the Natural History discourse is more standardized in terms and procedure, and the employed terminology is completely different.

The CIDOC CRM requires extensions to cater for the taxonomic discourse of Natural History, in a generic way, such that all cultural and Natural History taxonomic work can equally benefit from this model. The difference in terminology should be dealt with in the scope notes.

Taxon Creation or Contemporary Naming Procedure:

A taxonomic grouping of organisms creates a taxon, which should be named according to the Codes of Nomenclature. In the case of a species, look at a range of specimens different from anything previously published, write a description (protologue in botany), find a single representative specimen or exemplar (holotype), assign a scientific name according to International Codes for Nomenclature, document it in a paper and, finally publish the paper which validates the name. This description refers to the creation and naming of a taxon ranked as a species or lower; other taxa may be groups of species (genera, families, etc.). Prior to the early days of the 20th century, “holotypes” were generally not selected from the original sample of specimens (“syntypes”), which may create ambiguous situations when a set of “original elements” that gave rise to a new taxon are found to belong to more than one species. For that purpose, contemporary work may declare one specimen of the “original elements” as the “prototype” = “lectotype”.

The Group agreed, that the terms "holotype", "lectotype" etc. are not of E55 Type, but kinds of relationships between a taxon and a specimen. The same holds for several other Natural History "Types", as defined in:
http://fp.bio.utk.edu/mycology/Nomenclature/nom-type.htm

Original sources on the web:
  http://www.iczn.org/code.htm(Zoology);
http://www.bgbm.fu-berlin.deorg/iapt/nomenclature/code/default.htm(Botany);
http://www.york.biosis.org/zrdocs/codes/icncp.htm(Cultivated Plants);
http://www.york.biosis.org/zrdocs/codes/icnb.htm(Bacteriology)
http://www.york.biosis.org/zrdocs/codes/icvcn.htm(Virology)

It was pointed out that different authors' concepts may be dealing with the same name. The problem of the "potential taxon" is largely dealt with using "secundum" ("according to") followed by the literary references (author and publication) used to define it.

See: W.Berendsohn (1995): The concept of “potential taxa” in databases. Taxon 44, 207-212.

The following statements hold:
Taxon Creation is an Event, more specifically a Conceptual Creation.
It takes place in a Place and Time.
It creates a Taxon. There is also a description of the Taxon (the Protologue) - similar to the scope note in a thesaurus.
The Taxon has note: String
(has type : Protologue).
The Taxon Creation is based on/ had original elements: Biological Object.

Taxon Creation had original elements: Biological Object
"Taxon Creation" designated holotype Biological Object
"Taxon Creation" designated paratype Biological Object
"Taxon Creation" created taxon Taxon
Taxon has type Type
Taxon is identified by (Taxon-) Appellation
Taxon has broader term: Taxon.
Taxon is documented in:Document (Publication)

Old Proposals
Current Proposals

Introduce a new entity, either biology-specific, or generic. Biology-specific it would read:

E?? Taxon Creation
  Subclass of: Conceptual Creation
  Scope note: Taxon Creation is the process that declares a new class of genetically related living beings. It looks at a range of like specimens, creates a description (protologue in botany), finds a single representative specimen or exemplar (holotype), assigns a scientific name (Taxon) according to International Codes for Nomenclature and documents it in a paper. The protologue will appear as note of the created taxon.
 
Properties:
  created taxon (was created by): Taxon
had original elements (is original element of) : Biological Object
designated (had taxonomic role for): Biological Object
(as type: Type)
where "as type" would be one of "holotype". "lectotype" etc.
 
E?? Taxon
  Subclass of: T20 Type
  Scope note: A Taxon is a class of genetically related living beings.
Properties:
  is identified by (identifies): Taxon Appellation
 
E?? Taxon Appellation
  subclass of: E41 Appellation

The generic model would be:

E?? Type Creation
  Subclass of: Conceptual Creation
  Scope note: Type Creation is the process by which a new class of items is defined and published, following a scholarly or scientific good practice in the definition of the distinctive properties and the naming of the new class. Archeologist would call the new class a type, whereas biologists would call a new class of genetically related living beings a taxon. A biological taxon creation consists of the following steps: It looks at a range of like specimens, creates a description (protologue in botany), finds a single representative specimen or examplar (holotype), assigns a taxon name according to International Codes for Nomenclature and documents it in a paper. The protologue will appear as note of the created taxon. Similarly, an Archeologist would look at a range of like objects, and publish the distinctive criteria and the name he assigns to the new type. He may or may not select a prototype or an archetype from the studied material.
 
Properties:
  created type (was created by): Type
was based on (supported type creation): Entity
 
  (in the taxonomic role: Type)

This model can be seen as an abstraction of the previous one. It basically introduces the relationship between the Type Creation process and the material (normally kept in a museum) that allows other researchers to verify the properties of the new type. There seems to be a need for a short-cut:

E55 Type
  is exemplified by (exemplifies) : Entity
    (in the taxonomic role: Type)

I propose to make Type a Conceptual Object. The link "refers to" seems however to be counterintuitive for both, Types and Rights. I propose to lower
the domain of "refers to" to Information Object. The links about use and intention seem to make sense: "Canis lupus. was intended for: Biological Classification", "LCSH bridges. was intended for: Access to Literature by Subject".

A question only touched during the meeting was how to deal with a-posteriori declaration event of taxonomic roles, like "lectotype". May be, this could be a specialization of a Type Assignment. Simpler seems to be, to regard it as an extension of the taxonomic process, but this may lead to irregularities with the creation date of the taxon. May be, it is out of scope.

Martin Doerr, Walter Berendson, Karl-Heinz Lampe
14/5/2002

Outcome The second, generic model  was accepted. 
Type becomes a subclass of  E28 Conceptual Object.
P67 changes domain from E28 to E73 Information Object.
Copenhagen, 5/7/2002
Status done
Working Group 1
Starting Date 2002-02-19
Closing Date 2002-07-02



Issue No:77
Title Identification Procedure
Background

The discussion in Monterey, Feb. 2002 about Natural History requirements for the CIDOC CRM identified the following:

Documentation structures for Natural History can be separated into ordinary collection management issues and the taxonomic discourse. The first seems to be covered completely by the CIDOC CRM version 3.2.

Of particular interest is the field collection information of specimen - location, habitat etc., and ecosystem level observations. Formalization of the latter (ecosystem structure) seems however to be beyond the practical scope of the CRM.

The taxonomic discourse can be separated into taxon creation, naming conventions and identification procedures. The group felt, that the taxonomic discourse of Natural History is very similar to that in archaeology, to a degree that virtually all underlying concepts can be found in both domains. However, the Natural History discourse is more standardized in terms and procedure, and the employed terminology is completely different.

The CIDOC CRM requires extensions to cater for the taxonomic discourse of Natural History, in a generic way, such that all cultural and Natural History taxonomic work can equally benefit from this model. The difference in terminology should be dealt with in the scope notes.

See:
W. Berendsohn, A. Anagnostopoulos, G. Hagedorn, J. Jakupovic, P.L. Nimis & B. Valdes (Forthcoming). "CDEFD Information Model for Biological Collections", Proceedings of the European Science Foundation Workshop "Disseminating Biodiversity Information" (Amsterdam 25-27 March 1996).

Identification Process:
The classification procedure or E17 Type assignment would be called "Determination" for genetically related living beings (normally at the species level). It includes both Systematic and Molecular identification. e.g. via gene bank. It should follow:
· International Code of Zoological Nomenclature
· International Code of Botanical Nomenclature

Determination usually works higher to lower rank within a determination tree. The determinator (person responsible for the determination) is its mark of quality.
It is possible to have multiple determination of a single specimen. The procedure of the determination may be different.

The following statements hold:
Type Assignment assigns: T1 Type

Type Assignment classified: CRM Entity
Physical Object IsA CRM Entity
Physical Object exhibits general feature: T26 Type
Physical Object exhibits feature: Physical Feature
Physical Feature has type: T26 Type
T26 Type is characteristic for T19 Type
Biological Object IsA Physical Object
Taxon IsA Type

Old Proposals
Current Proposals

Determination is a case of E17 Type Assignement.
No model needed.

If a complete dialogue on features and Types should be modelled,

the property:
Physical Object exhibits general feature: Type

would complement
Physical Object exhibits feature: Physical Feature,
and
T26 Type is characteristic for T19 Type would
allow to justify Types by registered general features.

The latter seems not to be done in current Natural History
databases. The proposal is, that both properties are out of
scope, but constitute a reasonable extension.

Monterey 22/2/2002.
Outcome Issue resolved by adding to scope note for E17 that determination is an example of Type assignment in the biological sciences (issue 97).

Proposal accepted, Copenhagen 2/7/2002.
Status done
Working Group 1
Starting Date 2002-02-19
Closing Date 2002-07-02



Issue No:78
Title P15 took into account to become a sub-property of P12 occurred in the presence of
Background P12 implies chronological consequences, which should also apply to P15. For non-material objects, spatial presence can not be derived.
Old Proposals
Current Proposals

P15 took into account to become a sub-property of P12 occurred in the presence of

Monterey 20/2/2002.

Outcome Proposal accepted (see issue 95), Copenhagen 3/7/2002.
Status done
Working Group 1
Starting Date 2002-02-20
Closing Date 2002-07-03



Issue No:79
Title Change Property Name P17 was motivation for to was motivated by
Background The "forward" name of P17 confuses meaning. Probably an editorial mistake.
Old Proposals
Current Proposals

Change Property Name P17 was motivation for to was motivated by

Monterey 20/2/2002.

Outcome Covered by Issue 70.

Proposal accepted, Copenhagen 3/7/2002.
Status done
Working Group 1
Starting Date 2002-02-20
Closing Date 2002-07-03



Issue No:80
Title Change range of P18 motivated the creation of
Background Link to have a range that is Activity E7 to Activity E7. Property name is "was motivation of (motivated)". 
Old Proposals
Current Proposals

E7 Activity:
       P18 was motivation of (motivated) : E7 Activity

Monterey 20/2/2002.

Outcome

P18 is deleted by Issue 70.

Copenhagen 3/7/2002.

Status done
Working Group 1
Starting Date 2002-02-20
Closing Date 2002-07-03



Issue No:81
Title Numbering of Properties
Background There is a requirement for the numbering of properties of properties, and the documenting of them.
Old Proposals
Current Proposals

These should be documented within the property that they are a property of, and numbered relative to those.

Monterey 20/2/2002.

Outcome

Approved and implemented.

Copenhagen 5/7/2002.

Status done
Working Group 1
Starting Date 2002-02-20
Closing Date 2002-07-04



Issue No:82
Title Review the range for P24 transferred title of
Background The range for P24 (currently E19 Physical Object) needs to be reviewed in the light of physical feature and immaterial objects (i.e. trademarks, patents etc.). Is this in scope?
Old Proposals
Current Proposals

Immaterial Objects cannot be acquired. It the rights that are acquired. Acquisition of rights is not a specialization of E8 Acquisition, as defined in the CRM, and dealing with rights is beyond the pratical scope of the CRM. However, pieces of land and other "fiat objects", caves etc. can be acquired in the same sense as mobile objects, houses etc. I propose to raise range of P24 to E1 Physical Stuff, also for consistency with issue 83.

MD15/5/2002

Outcome

Raise range of P24 to E1 Physical Stuff. Acquisition of other items is out of practical scope.

Proposal accepted, Copenhagen 3/7/2002.

Status done
Working Group 1
Starting Date 2002-02-20
Closing Date 2002-07-03



Issue No:83
Title P51 through to P55 should move from physical object to physical stuff
Background
Old Proposals
Current Proposals

The direct ownership and location properties P51 has former or current owner through to P55 has current location should move domain from E9 Physical object to E18 Physical Stuff

Monterey 20/2/2002.

Outcome

P51, P52 and P53 change domain from E19 to E18, but not P54,P55.

Copenhagen 3/7/2002.

Status done
Working Group 1
Starting Date 2002-02-20
Closing Date 2002-07-03



Issue No:84
Title Consistency of P60 is member of and P107 had member
Background Consistency of P60 and P107 need to be looked at. Should possibly point to group rather than legal body and should use the former-current and current construct used elsewhere.
Old Proposals
Current Proposals

Delete P60 as redundant.
P107 to be renamed: P107 has current or former member (is current or
former member of)

P107 makes Persons the atomic elements of Groups. This is sufficient.
Temporal validity of membership seems to be out of practical scope, if
not proven otherwise.

Outcome Proposal accepted, Copenhagen 2/7/2002.
Status done
Working Group 1
Starting Date 2002-02-20
Closing Date 2002-07-02



Issue No:85
Title Physical Carriers and Properties
Background The property links P62 depicts object - P65 shows visual item need to be revisited in the light of the physical carrier discussion. For revision of this we need to take into account the Getty Categories for the Description of Works of Art.
Old Proposals
Current Proposals

In the 3rd CIDOC CRM SIG meeting we found that:
The property links P62 depicts object - P65 shows visual item need to be revisited in the light of the physical carrier discussion. For revision of this we need to take into account the Getty Categories for the Description of Works of Art.

To my understanding, the Getty Categories for the Description of Works of Art deal with depictions as part of the aboutness facet of the Subject Matter. this is not in contradiction to the current CRM.

Two problems may be identified in the current CRM:
The analysis of the depicts link is too specific. Calligraphical subjects seem not to be covered. The entity E36 Visual Item inherits the general "refers to" link, but this is fairly abstract over what it is optically about. The relation "P65 shows visual item" has overlap with the new proposed "is carrier of".

There is however no subproperty relationship:
Any Physical Man-Made Stuff can show a minor visual item, without being designed as Information Carrier. P65 make no assumption on the essential role for the carrier.

On the other side, "is carrier of" comprises clearly non-optical contents, e.g. electronic contents not visible.

If a Physical Object shows a visual item, which depicts a Person's face, the Object clearly depicts that also. In other words, depiction by an Object can be seen as short cut of a path going through the Visual Item. The Visual Item lacks now the adaquate link.

A statue, a 3-D picture in a transparent substance may not be regarded as having a corresponding indirection through a Visual Item.

Under those considerations, I propose

1. Change P62 into P62 depicts (is depicted by): E1 CRM Entity.
2. Delete P63,64.
3. Create a new link: E36 Visual Item "visualizes (has visualization)" : E1 CRM Entity,
subproperty of "P67 refers to"

MD 20/6/2002

Outcome

1: Change P62 into P62 depicts (is depicted by): E1 CRM Entity - Proposal accepted
2: Delete P63 & P64. Proposal accepted
3: Create a new link: E36 Visual Item "visualizes (has visualization)": E1 CRM Entity, a sub-property of "P67 refers to".

Proposal accepted, Copenhagen 2/7/2002.

Status done
Working Group 1
Starting Date 2002-02-21
Closing Date 2002-07-02



Issue No:86
Title P66 refers to concept is redundant
Background P66 refers to concept is completely covered by P67 refers to.
Old Proposals
Current Proposals

Delete P66 refers to concept.

Include the meaning of subject relationship in P67

Monterey 21/2/2002.

Outcome Proposal accepted, Copenhagen 2/7/2002.
Status done
Working Group 1
Starting Date 2002-02-21
Closing Date 2002-07-02



Issue No:87
Title Ownership and Legal Rights
Background In the E30 Right scope note there is no mention of the fact that we have Ownership as a means of expressing legal rights to something.
Old Proposals
Current Proposals

Add:

An E8 Acquisition Event implies establishment and/or loss of ownership rights on the implied physical objects or features. E8 does however not imply changes of rights in general.

MD 15/5/2002

Outcome

Add to scope note:

An E8 Acquisition Event implies establishment and/or loss of ownership rights on the implied physical objects or features. E8 does not, however, imply changes of rights in general

Proposal accepted, Copenhagen 5/7/2002.

Status done
Working Group 1
Starting Date 2002-02-21
Closing Date 2002-07-05



Issue No:88
Title Rename Properties P81 at least covering and P82 at most within
Background MS to provide EH definitions for time spans - Check MIDAS.
Old Proposals

The names equivalent names of "P81 at least covering "
and "P82 at most within" used by MIDAS are
"throughout" and "within".

Proposal 1:

Rename P81 to "P81 throughout"
Rename P82 to "P82 within"

Current Proposals

Proposal 2 (verbose):

Rename P81 to "P81 ongoing throughout"
Rename P82 to "P82 at some time within"

MD 20/6/2002

Outcome Proposal 2:
Rename P81 to P81 ongoing throughout
Rename P82 to P82 at some time within

Proposal 2 accepted, Copenhagen 3/7/2002.
Status done
Working Group 1
Starting Date 2002-02-21
Closing Date 2002-07-03



Issue No:89
Title P85 consists of is redundant
Background This property should be deleted as the Allan Operators for Event, along with P86 falls within, give us all of the functionality that we need.
Old Proposals
Current Proposals

Delete P85 consists of.

Monterey 21/2/2002.

Outcome Proposal accepted, Copenhagen 3/7/2002.
Status done
Working Group 1
Starting Date 2002-02-21
Closing Date 2002-07-03



Issue No:90
Title Scope Notes of E52
Background The E52 Scope Notes need to stress that times spans may not have precisely known temporal extents.
Old Proposals
Current Proposals

New scope note: 

A determination of a range of dates or duration without any further connotations, to be used to confine periods, events, and any other phenomena valid for a certain time. A time appellation is a verbal form which refers to a time-span. The time-span itself is a temporal extent in the sense of Galilean physics. Different time-appellations may express the same time-span. The Time-Span represents the real extent of the entity it refers to, which is always fuzzy to a certain degree and only known in approximation. Respective properties of Time-Span allow to express approximations of a time-span according to our knowledge.
Example follows as before.

MD, 19/6/02

Outcome

Scope note to be rewritten as follows:

A determination of a range of dates or duration without any further connotations, to be used to set limits to the temporal extent of periods, events and any other phenomena valid for a certain time. A time appellation is a verbal form which refers to a time-span. The time-span itself is a temporal extent in the sense of Galilean physics. Different time-appellations may express the same time-span. The Time-Span represents the real extent of the entity it refers to, which is always fuzzy to a certain degree and only known in approximation. Respective properties of Properties of time-span allow the expression of approximations of a time-span according to our knowledge.

Proposal accepted, Copenhagen 3/7/2002.

Status done
Working Group 1
Starting Date 2002-02-21
Closing Date 2002-07-03



Issue No:91
Title P72 has language is redundant
Background

An opinion is, that P72 could be described as E33 Linguistic Object: has type.

Alternative opinion is, that language pertains more to contents, but the instantiation is not discrete, similar to materials.

Old Proposals
Current Proposals

Delete P72 has language, because it is covered by P2 has type

Christian-Emil Ore, 21/2/2002.

Outcome

A language has more complex relationship with a text. Keep link P72 and the type Language.

Proposal rejected. Copenhagen 3/7/2002 (see issue 100).

Status done
Working Group 1
Starting Date 2002-02-21
Closing Date 2002-07-03



Issue No:92
Title Declare all disjoint classes
Background
Old Proposals

In Monterey 22/2/2002, the "disjoint with" relationship was decided.

In the sequence, disjointness declarations are required whereever applicable.

I propose the following "disjoint with" relations in the CIDOC CRM. As the CIDOC CRM in general does not constrain multiple instantiation, this construct allows to exclude some obvious cases. The relationship is symmetric and inherited. I.e. if Persistent Item is disjoint with Temporal Entity, all subclasses of Persistent Item are disjoint with all subclasses of Temporal Entity and vice a versa. Therefore, I refer those relationships only once, and top-down. Any other notation would cause great confusion. As we support recall over precision, it would be worse to have one disjoint declaration too much than one too less. We have done without disjopintness declarations long enough. In this sense, the following list is comprehensive, to the degree we could decide without doubts about disjointness.

Assuming: Type isA Conceptual Object, Legal Object isA Stuff

E2 Temporal Entity Disjoint with:
- Persitent Item
- Place
- Dimension
- Time-Span
- Primitive Value

E77 Persistent Item Disjoint with:
- Place
- Dimension
- Time-Span
- Primitive Value

E53 Place Disjoint with:
- Dimension
- Time-Span
- Primitive Value

E54 Dimension Disjoint with:
- Time-Span
- Primitive Value

E52 Time-Span Disjoint with:
- Primitive Value

E39 Actor disjoint with:

- E24 Physical Man-Made Stuff
- E73 Information Object
- E41 Appellation
- E51 Contact Point
- E55 Type

E18 Physical Stuff disjoint with:
- Conceptual Object

E26 Physical Feature disjoint with:
- Physical Object

E55 Type disjoint with:
- Right

E56 Language disjoint with:
- Material
- Measurement Unit

E57 Material disjoint with:
- Measurement Unit

MD 19/6/2002

Current Proposals

In Monterey a proposal was accepted to declare all disjoint classes in order to aid comprehnsion of the CRM (See issue 66), and Martin has now produced a draft list of disjoint class declarations.

However, after reviewing Martin's draft list I realized that it was not (nor intended to be) comprehensive, and that it will be a significant and time-consuming intellectual undertaking to produce a fully comprehensive list of all disjoint class declarations. It almost certainly couldn't be done in time for the Copenhagen meeting.

So, we need to ask ourselves whether an incomplete list of disjoint class declarations is sufficiently useful and comprehsible to include in the CRM, or whether we should abandon the idea of disjoint class declararations altogether? In view of the time constraints we are facing, I am proposing the latter -- that we do not include an incomplete list of disjoint class declarations in the CRM.

TG 20/6/2002

Proposal 2 accepted. Issue open until scope notes written. Copenhagen 3/7/2002

Here the scope notes:

E2 Temporal Entity

Subclass of:

CRM Entity

Superclass of:

Condition State
Period

New Scope note:

This is an abstract entity and has no examples. It groups together transient phenomena such as events, states and others, which are limited in time, also called perdurants. It is specialized into Period, which holds on some geographic area, and Condition State, which holds for, on, or over a certain object. Even though Persitent Items (or endurants) have a limited existence in time, because they may be destroyed, lost or forgotten, we regard them as disjoint from Temporal Enties, as their persistent identity allows to relate Temporal Entities in which they participate.

 

E77 Persistent Item

Subclass of:

CRM Entity

Superclass of:

Stuff
Contact Point
Appellation
Actor

New Scope note:

E77 Persistent Item encompasses (and thereby isolates) entities which share two attributes: having the potential to exist over a period of time, and having persistent identity during this period of existence. These attributes are intended to apply to both concrete objects, whether animate or inanimate and to ideas or concepts. Hypothetical or imaginary objects fall within this category insofar as they can be considered as conceptual objects i.e. E77 Persistent Item is not intended to be restricted to physical existence. Persistent Items are also called endurants.

The conditions under which an object can be deemed to maintain its identity are often difficult to establish - the decision depends largely on the judgement of the observer. Most people would agree, for example, that a building ceases to exist if it is dismantled and the materials reused in a different configuration. Human beings, on the other hand, in common with many other organisms, go through radical and profound changes during their life-span, affecting both material composition and form, yet preserve their identity. But also material objects in daily use also undergo material changes due to maintenance etc. without changing identity. Identity in these cases would seem to depend more on continuity rather than the presence of any particular physical state or component.

The main classes of objects which fall outside the scope of E77 Persistent Item are Temporal Entities such as periods, events and
acts, and descriptive properties, (such as dimensions) which function as adjectives and adverbs. The latter depend in there identity on the object they are assigned to. The former acquire an identity only through the changes participating Persistent Items undergo, but not out of their own form or substance. We regard them as disjoint from Temporal Entities.

 

 

E18 Physical Stuff

Subclass of:

Legal Object

Superclass of:

Physical Object
Physical Man-Made Stuff
Physical Feature

Scope note:

Physical stuff is an abstract notion that groups all physical objects, man-made and natural, as well as physical features of objects, such as holes. We use the term 'feature' to refer to anything of a material nature, such as scratches, holes, rivers, and stains, which it would be strange to refer to as ?objects?.

New Scope note:

Physical stuff is an abstract notion that groups all physical objects, man-made and natural, as well as physical features of objects, such as holes. We use the term 'feature' to refer to anything of a material nature, such as scratches, holes, rivers, and stains, which it would be strange to refer to as ?objects?. Physical stuff is disjoint from E28 Conceptual Object, the immaterial products. The latter are exclusively man-made. Physical stuff can only be present at one place at a time, whereas conceptual objects may be present at multiple places at a time via multiple physical carriers. Physical stuff ceases to exist by destruction, whereas conceptual objects ceases to exist by loss of the last carrier or by forgetting.
Examples: Me, the Cave of Dirou in Peloponnese, the Euphrat River, Lassie the dog, the logbook of the Endeavor.


E28 Conceptual Object

Subclass of:

Man-Made Stuff

Superclas of:

Right
Information Object
Type

Scope note:

This entity is the attempt to group the non-material products of our minds, and specifically to allow for reasoning about their identity, circumstances of creation and historical implications. Characteristically, these things are created, invented or thought, and somehow documented or communicated between persons. Conceptual objects need not have a particular carrier, but may be found on several different carriers, such as paper, electronic signals, marks, audio media, paintings, photos, human memory, etc. They cannot be destroyed as long as they exist on at least one carrier or in memory. Examples include texts, maps, photos, music, sounds, fairy tales, signs, patterns, symbols, plans, rights, and rules. A greater distinction could be made between products having a clear identity, such as a specific text, or photographs, and the ideas and concepts shared and traded by groups of people.

New Scope Note:

This entity is the attempt to group the non-material products of our minds and of technical processes such as image taking, and specifically to allow for reasoning about their identity, circumstances of creation and historical implications. Characteristically, these things are created, invented or thought, and somehow documented or communicated between persons and technical means of communication. Conceptual objects need not have a particular carrier, but may be found on several different carriers, such as paper, electronic signals, marks, audio media, paintings, photos, human memory, etc. They cannot be destroyed as long as they exist on at least one carrier or in memory. Examples include texts, maps, photos, music, sounds, fairy tales, signs, patterns, symbols, plans, rights, rules, types, taxa and other concepts. A greater distinction is made between products having a clear identity, such as a specific text, or photographs, the Information Objects and the ideas and concepts shared and traded by groups of people. Conceptual objects are disjoint from physical stuff, the material things. The latter may be man-made or not. Physical stuff can only be present at one place at a time, whereas conceptual objects may be present at multiple places at a time via multiple physical carriers.
Examples: The contents of "Definition of the CIDOCobject-oriented Conceptual Reference Model, version 3.3.2, Sept.2002", the copyright by CIDOC on the latter, the species fringilla coelebs, the sound track of The Beatles "Yellow Submarine", Albrecht Durer's signature, Unicorn.

16/10/2002

Outcome

Solution in version 3.3.2 accepted. Text in introduction needs rewording.

Proposal Accepted

Rethymnon 22/10/2002

Status done
Working Group 3
Starting Date 2002-02-22
Closing Date 2002-10-22



Issue No:93
Title Also Represented By
Background
Old Proposals
Current Proposals

Decision: The group voted for Proposal 3 which requires the creation of a new property: "Also represented by". Appellation instances are identified by the name itself. Alternatives of the same name as opposed to alternative names of the identified object or person can be connected to an appellation instance by the property "Also Represented by" (which is bi-directional).

Monterey 20/2/2002.

Outcome Appellation: also represented by: Appellation. Proposal accepted, Copenhagen 3/7/2002.
Status done
Working Group 1
Starting Date 2002-02-22
Closing Date 2002-07-03



Issue No:94
Title Position of E72 Legal Object
Background The Position of Legal Object in the CRM seems not to serve the purpose it was intended for. The total of items, which could be subject to a right seems to be out of scope of the CRM. The items which are typically subject to rights in a museum are Information Objects and Physical Stuff.
Old Proposals
Current Proposals

I propose therefore to put Legal Object under Stuff, which makes the fundamental facets by far clearer.

MD 20/6/2002

Outcome

Put Legal Object under Stuff, which makes the fundamental facets by far clearer. Wider interpretations of Legal Objects are out of practical scope.

Proposal accepted, Copenhagen 3/7/2002.

Status done
Working Group 1
Starting Date 2002-02-20
Closing Date 2002-07-03



Issue No:95
Title P12 occurred in the presence of
Background The successful harmonization of the ABC Harmony for Digital Libraries and the CIDOC CRM
created some minor proposals fopr the CRM to widen definitions of some properties:
Old Proposals
Current Proposals

P12 occurred in the presence of (was present at) should have range E77 Persistent Item, in order to include Actors and other things. Non-material objects, like texts, ideas, plans, names, are understood to be present via some physical carrier or a Person having knowledge of it, Groups via some representative. Physical Stuff is understood to be present in the place of the Event.

This solves the conflict, that Groups may participate in an Event but not be present. It clarifies, that non-material items can be present at more than one place at the same time, but not be present everywhere at the same time.

MD 20/6/2002

Outcome

P12 occurred in the presence of (was present at) should have range E77 Persistent Item in order to include Actors and other things. Proposal accepted.

P11 becomes a sub-property of P12 occurred in the presence of (was present at).

Proposal accepted, Copenhagen 3/7/2002.

Status done
Working Group 1
Starting Date 2002-07-03
Closing Date 2002-07-03



Issue No:96
Title Use of S/W tools
Background The successful harmonization of the ABC Harmony for Digital Libraries and the CIDOC CRM
created some minor proposals fopr the CRM to widen definitions of some properties:
Old Proposals
Current Proposals

P16 used object
should have range E70 Stuff, in order to S/W tools, dying pits and other "stuff",
and not only Physical Objects.

MD 20/6/2002

Outcome Covered by Issue 70.

Proposal accepted, Copenhagen 3/7/2002.
Status done
Working Group 1
Starting Date 2002-07-03
Closing Date 2002-07-03



Issue No:97
Title Scope note for E17
Background
Old Proposals
Current Proposals

Add to scope note for E17 that determination is an example of Type assignment in the biological sciences.

New scope note:

This entity describes the act of classifying another entity, for example an object, a specimen, an action or a concept. The value of classification depends critically on the identity of the classifier and the date that the classification was assigned. This entity also comprises the process of "determination," i.e. the systematic and molecular identification of a specimen in biology.
Example: "first classification of object GE34604 as Lament Cloth, October 2,
1998 by I.Dionissiadou".

Copenhagen 2/7/2002

Outcome

Proposal accepted

Rethymnon 23/10/2002

Status done
Working Group 3
Starting Date 2002-07-03
Closing Date 2002-10-23



Issue No:98
Title Physical Object exhibits general features
Background
Old Proposals
Current Proposals

The possible extensions to support reasoning on features characteristic for types of objects as discussed in issue 77 should be included in the extended documentation

Copenhagen 2/7/2002

Outcome
Status open
Working Group 4
Starting Date 2002-07-02
Closing Date In Progress



Issue No:99
Title Birth of non-humans
Background
Old Proposals
Current Proposals

Create new extended document issue explaining how to deal with the birth of non-humans.

Copenhagen 2/7/2002

Outcome
Status open
Working Group 4
Starting Date 2002-07-03
Closing Date In Progress



Issue No:100
Title Scope note of E33 Linguistic Object
Background
Old Proposals

Change scope note to E33 linguistic Object - replace "physical language" with "natural language". Enrich scope note to include languages which are not documented in writing - see "Jabberwocky" by Lewis Carroll. Computer languages and other formal lanuages are to be excluded (to be kept as Information Objects).

Copenhagen 3/7/2002

Current Proposals

New scope note:

The Linguistic Object entity describes identifiable expressions in a natural language. Linguistic Objects can be expressed in many ways: For example, as written text, recorded speech or sign language. However, the CRM treats
Linguistic Objects as distinct from the medium or method by which they are expressed. Note that expressions in formal languages, such as computer code or mathematical formulae, are not treated as Linguistic Objects by the CRM; these should be modeled as instances of E73 Information Object.

Examples: the text of the Ellesmere Chaucer manuscript; the lyrics of the song "Blue Suede Shoes"; the text of the Jabberwocky by Lewis Carroll; the text of "Doktoro Jekyll kaj Sinjoro Hyde" (an Esperanto translation of Dr Jekyll and Mr Hyde).

7/10/2002

Outcome

First sentence should be changed to read: "The Linguistic Object class comprises identifiable expressions in natural languages(s)."

Proposal Accepted

Rethymnon 23/10/2002

Status done
Working Group 3
Starting Date 2002-07-04
Closing Date 2002-10-23



Issue No:101
Title Scope Note for E73 to contain Multimedia Objects
Background
Old Proposals
Current Proposals

TG to explicitly mention multimedia objects and reference Jane Hunter's mpeg 7 paper in extension to scope note for Information Object (E73).

Copenhagen 3/7/2002

Scope Note: An identifiable immaterial item, such as a poem, joke, data set, image, text, multimedia object, procedural prescription, computer program code, algorithm or mathematical formulae, that constitutes a unit for documentation and has an objectively recognizable structure. An information object does not depend on its physical carrier, which can include human memory, and can exist on one or more carriers. Information objects of a linguistic nature should be documented as instances of the E33 Linguistic Object subclass. Conceptual items such as types and classes are not information objects, nor are ideas without a reproducible expression.

Examples: Image BM000038850.JPG from the Clayton Herbarium in London, E. A. Poe's "The Raven", the movie "The Seven Samurai" by Akira Kurosawa, the Maxwell Equations.

Outcome

Replace "formulae" with "formula".

Replace: "Information objects of a linguistic nature should be declared as instances of the E33 Linguistic Object subclass."

Add: " Information objects of a documentary nature should be declared as instances of the E31 Document subclass."

Revise: "Can exist on one or more carriers <add>simultaneously</add>".

Proposal Accepted

Rethymnon 23/10/2002

Status done
Working Group 3
Starting Date 2002-07-03
Closing Date 2002-10-23



Issue No:102
Title Scope note for Exx Actor Appellation
Background
Old Proposals
Current Proposals

Write scope note for Exx Actor Appellation

Copenhagen 3/7/2002

PROPOSED ACTOR SCOPE NOTE:

An Actor Appellation is any sort of name, number, code or symbol used to identify an Actor. An Actor will typically have more than one Appellation, and Appellations in turn may have alternative representations.

The distinction between corporate and personal names, which is particularly important in library applications, should be made by explicitly linking the Actor Appellation to either a Person or Group/Legal Body entity. If this is not possible, the distinction can be made through the use of the "has type" mechanism.

Examples: "Johnny", "John Doe", "Doe, J.", "J.X.D.", "246-14-2304", "The Third Man". "Prince", "[Love Symbol]", "The Artist Formerly Known as Prince", "The Master of the Flemish Madonna", "The Master of Madonna with parrot", "Raphael's workshop", "the Brontes", "ICOM", "International Council of Museums".

TG

16/10/2002

Outcome

An Actor Appellation is any sort of name, number, code or symbol used to identify an Actor. An Actor will typically have more than one Appellation, and Appellations in turn may have alternative representations.

The distinction between corporate and personal names, which is particularly important in library applications, should be made by explicitly linking the Actor Appellation to an instance of either Person or Group/Legal Body. If this is not possible, the distinction can be made through the use of the P2 has type mechanism.

Examples; "Johnny", "John Doe", "Doe", "J.X.D.", "the U.S. Social Security Number 246-14-2304", "The Artist Formerly Known as Prince", "The Master of the Flemish Madonna", "Raphael's Workshop", "the Bronte Sisters", "ICOM", "International Council of Museums".

Proposal Accepted

Rethymnon 23/10/2002

Status done
Working Group 3
Starting Date 2002-10-16
Closing Date 2002-10-23



Issue No:103
Title Scope note for E42
Background
Old Proposals
Current Proposals

Write new scope note for E42

Copenhagen 4/7/2002

E42 Object Identifier

Subclass of:

Appellation

Scope note:

Unique codes assigned to objects in order to identify them uniquely within the context of one or more organizations. Typically alphanumeric sequences.
Examples: MM.GE.195, 13.45.1976, etc.

New Scope note:

An object identifier is a code assigned by a person or organisation to a physical object in order to identify it uniquely within the context of one or more organizations over a certain period of time. This class is intended primarily for museum identification numbers, such as object numbers, inventory numbers, registration numbers or accession numbers. (Note that the identification of the acquisition event is sometimes mistaken for the identification of the acquired objects themselves). An object identifier may be created prior to an assignment and never be used. It may come out of use, and, by chance, it may be reused for another object. It is typically an alphanumeric sequence, often encoding some meaning like year of acquisition etc.
Examples: MM.GE.195, 13.45.1976, etc.

16/10/2002

Outcome

Replace

"An object identifier is a code assigned by a person or organisation to a physical object"
with
"An object identifier is a code assigned by an actor to a physical object"

Else proposal accepted

Rethymnon 24/10/2002

Status done
Working Group 3
Starting Date 2002-10-16
Closing Date 2002-10-24



Issue No:104
Title P77 consists of is redundant
Background
Old Proposals
Current Proposals

Delete redundant property P77. This is addressed by P107.

Copenhagen 4/7/2002

Outcome

Property deleted. Proposal Accepted

Rethymnon 23/10/2002

Status done
Working Group 1
Starting Date 2002-07-04
Closing Date In 2002-10-22



Issue No:105
Title E67 Birth with multiple off springs
Background
Old Proposals
Current Proposals

Revise scope note for E67 Birth to clarify situation with multiple offsprings.

Copenhagen 5/7/2002

 

E67 Birth

Subclass of:

Beginning of Existence

Scope note:

The birth of a human being

New Scope note:

This class describes the birth of a human being only as an aspect of major cultural concern. Its focus is on the context of people coming into life. The coming into life of other living beings is covered by E63 Beginning of Existence. Twins, triplets etc. are brought into life by the same Birth event. The introduction of the birth event as documentation element allows for describing a considerable wealth of family relations in a simple model. Suitable extensions may describe more details and the complexity of motherhood with the intervention of modern medicine. The father is not seen as directly involved in the birth. In rare cases, multiple offsprings may have different fathers.
Example: The birth of Alexander the Great.

MD

16/10/2002

Outcome

Replace

"The introduction of the birth event as documentation element allows for describing a considerable wealth of family relations in a simple model."

With

"The introduction of the birth event s a documentation element allows the description of a range of family relationships in a simple model."

Else proposal accepted

Rethymnon 24/10/2002

Status done
Working Group 3
Starting Date 2002-07-05
Closing Date 2002-10-24



Issue No:106
Title P105 right held by
Background
Old Proposals
Current Proposals

Delete "has note" property on property for P105, which is a shortcut for P104 - P75 through Right. This should be a "has note" on Right.

Copenhagen 5/7/2002

Outcome

Delete "has note" property on property for P105. P105 is a shortcut for P104 - P75 through Right. If a note is needed, it should be attached to "has note" on Right using the full path.

  • The proposal to remove the link P105.1 was agreed.
  • The scope note for P105 needs to state that it is a shortcut.

Rethymnon 23/10/2002

Status done
Working Group 1
Starting Date 2002-07-05
Closing Date 2002-10-23



Issue No:107
Title P33 subproperty of P12
Background
Old Proposals
Current Proposals

P33 used specific technique (was used by) should be subproperty of
P12 occurred in the presence of (was present at)

(Scope note: This property describes the active or passive presence of a persistent item in an event without implying any specific role.
It connects the history of a thing with the place and 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))

Reason: the specific technique participates through its carrier, as any immaterial object can do.

30/9/2002

Outcome

P33 used specific technique (was used by) should be subproperty of P12 occurred in the presence of (was present at).

Proposal Accepted.

Rethymnon 23/10/2002

Status done
Working Group 1
Starting Date 2002-09-30
Closing Date 2002-10-23



Issue No:108
Title Property needed for Actor Appellation
Background
Old Proposals
Current Proposals

Actor Appellation needs a specific "is identified by" property, as all other appellations specific to a fundamental category.

30/9/2002

Outcome

P131 is created: Actor (E39) is identified by (identifies) Actor Appellation (E82).

Note: this is a specialization of P1 is identified by, and that P1 can result in unintended models (e.g. Actor is identified by Place Appellation).

Proposal Accepted

Rethymnon 23/10/2002

Status done
Working Group 1
Starting Date 2002-09-30
Closing Date 2002-10-23



Issue No:109
Title Declare "necessary" and "dependent" properties
Background
Old Proposals
Current Proposals

a) Dimension: "P90 has value" and "P91 unit" should have the same cardinality: Many to one. A Dimension can define only one value/unit pair, else the correlation between the value and the unit would be lost. May be the thing is already too implementation oriented for the CRM.

b) "P108 has produced" : There should be at most one production event per object. The next processing step would be a modification. Otherwies, if there are multiple events in the production process (such as mold building, cast etc.), they are PARTS ("P9 consists of") of one longer Production Event.

c) E6 Destruction P13 destroyed (was destroyed by) Physical Object should have carinality: "1:many, necessary",

as all other destructive properties (P93 etc.), and not "many:many". I assume a protocol error in Copenhagen.

d) I propose, in order to clarify fully the ontological meaning of CRM properties wrt cardinality constraints, to introduce the following:

a) "necessary" : in reality every domain instance has at least one such link.
b) "dependent" : in reality every range instance has at least one such link.
(The range instance "depends" in its existence on at least one domain instance)

Both terms are well introduced in computer science.

The backward link reads "necessary" as "dependent" and vice-versa.

Those constraints do not mean, that we know or ever should know the respective properties.
The constraints are ontological. An implementation would be oriented on epistemological
constraints, i.e. what can be learned. This is why I repeat the phrase "in reality".

To which degree a Condition State must exist or not without people having conceived it, might be debatable.
I assumed, that an Object does not always come with some may be non-thought-of Condition State.

All links to Dimension must express, that a Dimension is specific to the related: P83, P84 must be 1:something,
because P43 is 1:many, dependent. Necessarily, P83, P84 must be 1:1, dependent, and not "many:1".


Hence we read:

many:many = (0,n):(0,n)
many:many, necessary = (1,n):(0,n)
many:many, dependent = (0,n):(1,n)
many:many, necessary, dependent = (1,n):(1,n)

many:1 = (0,1):(0,n)
many:1, necessary = (1):(0,n)
many:1, dependent = (0,1):(1,n)
many:1, necessary, dependent = (1):(1,n)

1:many = (0,n):(0,1)
1:many, necessary = (1,n):(0,1)
1:many, dependent = (0,n):(1)
1:many, necessary, dependent = (1,n):(1)

I propose for:

Temporal Entity P4 has time-span (is time-span of) Time-Span : "many:1, necessary, dependent"

E4 Period P7 took place at (witnessed) Place : "many:many, necessary"

E5 Event P11 had participant (participated in) Actor "many:many, dependent",
comment: "In reality, Actors would at least participate in the Event that brings them about"

E7 Activity P14 carried out by (performed) Actor "many:many, necessary"
comment: "In reality, at least one Actor should have carried out the Activity"

E8 Acquisition Event P22 transferred title to (acquired title of) Actor "many:many" (no change!)
comment:"In reality, the title is at least either transferred to someone or from someone."

E8 Acquisition Event P24 transferred title of (changed ownership by) Physical Stuff "many:many, necessary"

E9 Move P25 moved (moved by) Physical Object "many:many, necessary"

E9 Move P26 moved to (was destination of) Place "many:many, necessary"
E9 Move P27 moved from (was origin of) Place "many:many, necessary"

E10 Transfer of Custody P28 custody received by (received custody) Actor "many:many" (no change!)
comment: "In reality, the custody is at least either transferred to someone or from someone."

E10 Transfer of Custody P30 transferred custody of (custody changed by) Physical Object "many:many, necessary"

E11 Modification Event P31 has modified (was modified by) Physical Man-Made Stuff "many:many, necessary"

E14 Condition Assessment P34 concerned (was assessed by) Physical Stuff "many:many, necessary"

E14 Condition Assessment P35 has identified (identified by) Condition State "many:many, necessary"

E15 Identifier Assignment P36 registered (was registered by) Physical Object "many:1, necessary"

E15 Identifier Assignment P37 assigned (was assigned by) Object Identifier "many:1, necessary"
comment: "An Object Identifier might be created prior to an assignment"

E16 Measurement Event P39 measured (was measured by) Stuff "many:1, necessary"

E16 Measuremen Eventt P40 observed dimension (was observed) Dimension "many:many, necessary"

E17 Type Assignment P41 classified (was classified by) CRM Entity "many:1, necessary"

E17 Type Assignment P42 assigned (was assigned by) Type "many:many, necessary"

E70 Stuff P43 has dimension (is dimension of) Dimension "1:many, dependent"

E18 Physical Stuff P44 has condition (condition of) Condition State "1:many, dependent"

E18 Physical Stuff P45 consists of (is incorporated in) Material "many:many, necessary"

E18 Physical Stuff P53 has former or current location (is former or current location of) Place "many:many, necessary"

E19 Physical Object P56 bears feature (is found on) Physical Feature "1:many, dependent"

E18 Physical Stuff P58 has section definition (defines section) Section Definition "1:many, dependent"

E31 Document P70 documents (is documented in) CRM Entity "many:many, necessary"

E32 Authority Document P71 lists (is listed in) Type "many:many, necessary"

E33 Linguistic Object P72 has language (is language of) Language "many:many, necessary"

E52 Time-Span P81 ongoing throughout Time Primitive "many:many, necessary"

E52 Time-Span P82 at some time within Time Primitive "many:many, necessary"

E52 Time-Span P83 had at least duration (was minimum duration of) Dimension "1:1, necessary, dependent"

E52 Time-Span P84 had at most duration (was maximum duration of) Dimension "1:1, necessary, dependent"

E54 Dimension P90 has value Number "many:1, necessary"

E54 Dimension P91 unit Measurement Unit "many:1, necessary"

E63 Beginning of Existence P92 brought into existence (was brought into existence by) Persistent Item "1:many, necessary, dependent"

E64 End of Existence P93 took out of existence (was taken out of existence by) Persistent Item "1:many, necessary"

E65 Creation Event P94 has created (was created by) Conceptual Object "1:many, necessary, dependent"

E66 Formation Event P95 has formed (was formed by) Group "1:many, necessary, dependent"

E67 Birth P96 by mother (gave birth) Person "many:1, necessary"

E67 Birth P97 from father (was father for) Person "many:many, necessary"

E67 Birth P98 brought into life (was born) Person "1:many, dependent"

E68 Dissolution P99 dissolved (was dissolved by) Group "1:many, necessary"

E69 Death P100 was death of (died in) Person "1:many, necessary"

E71 Man-Made Stuff P102 has title (is title of) Title "many:many, dependent"
comment: ". We cannot imagine a title being created without an object in mind."

E74 Group P107 has current or former member (is current or former member of) Actor "many:many, necessary"
comment: "A Group necessarily consists of more than one Person."

E12 Production Event P108 has produced (was produced by) Physical Man-Made Stuff "1:many, necessary, dependent"

E78 Collection P109 is curated by (curates) Actor "many:many, necessary"

E79 Part Addition P110 added to (was augmented by) Physical Man-Made Stuff "many:1, necessary"

E79 Part Addition P111 added (was added by) Physical Stuff "many:many, necessary"

E80 Part Removal P112 removed from (was diminished by) Physical Man-Made Stuff "many:1, necessary"

E80 Part Removal P113 removed (was removed by) Physical Stuff "many:many, necessary"

E81 Transformation P123 resulted in (was result on) Persistent Item "many:many, necessary"

E81 Transformation P124 transformed (was transformed by) Persistent Item "many:many, necessary"


Obviously, quite a lot of concepts depend on the existence of a relation to others. That seems to me an important element of
their definition

30/9/2002

Outcome

Both word and numeric cardinality notation to be used: e.g. many:many (0,n):(0,n)

Cardinality statements following the above proposal in the property list amended and accepted

Rethymnon 22/10/2002

Status done
Working Group 3
Starting Date 2002-09-30
Closing Date 2002-10-22



Issue No:110
Title P109 is curated by (curates)
Background
Old Proposals
Current Proposals "P109 is curated by (curates)" should be called : "P109 is or was curated by (curates or curated)", to make it timeless. 30/9/2002
Outcome

P109 is renamed to: "has current or former curator (is current or former curator of)" in order to make it timeless

Proposal Accepted

Rethymnon 24/10/2002

Status done
Working Group 3
Starting Date 2002-09-30
Closing Date 2002-10-24



Issue No:111
Title Add the crm scope definition, intended scope, to the final document
Background
Old Proposals
Current Proposals

Add the crm scope definition, intended scope, to the final document to be submitted as standard.

30/9/2002

Outcome

Proposal Accepted

Rethymnon 24/10/2002

Status done
Working Group 3
Starting Date 2002-09-30
Closing Date 2002-10-24



Issue No:112
Title Consistency of presence and participation
Background

E65 Creation Event P94 has created (was created by) Conceptual Object: is subproperty of P12,P92

E12 Production Event P108 has produced (was produced by) Physical Man-Made Stuff: is subproperty of P31,P92

E67 Birth P98 brought into life (was born) Person P92

E66 Formation Event P95 has formed (was formed by) Group P11,P92

P31 (modified) is subproperty of P12, as well as P11 (participated in).

Hence, all Groups, Stuff are present in their creation, but not Persons. I think the idea in Copenhagen was to
link P92 brought into existence, summarily to P12.

Equally:

E6 Destruction P13 destroyed (was destroyed by) Physical Object is subproperty of P93

E68 Dissolution P99 dissolved (was dissolved by) Group is subproperty of P11,P93

E69 Death P100 was death of (died in) Person is subproperty of P93

Meaning, that neither objects nor people are present at their end.
I think the idea in Copenhagen was to link P93 took out of existence, summarily to P12.

Immaterial things end by forgetting or destruction of all carriers. So, I think we can fairly assume
that all Persistent Items are present until and at the event of their end.

Old Proposals
Current Proposals

1). P94 to be subproperty of 92 only, as P98, and P92 to be subproperty of P12. This is consistent, as we declare presence
of immaterials as through their carriers.

2). I propose P93 to be subproperty of P12.

30/9/2002

Outcome

A person is present at his/her birth. P94 to be subproperty of 92 only, as P98, and P92 to be subproperty of P12. This is consistent, as we declare presence of immaterials as through their carriers.

  • Agreed to make P92 brought into existence subproperty of P12 is present at.
  • Agreed to make P93 took out of existence subproperty of P12 is present at.
  • Agreed to delete P95 has formed IsA P11 had participant

Proposal Accepted

Rethymnon 23/10/2002

Status done
Working Group 1
Starting Date 2002-09-30
Closing Date 2002-10-23



Issue No:115
Title Right & Legal Object
Background
Old Proposals
Current Proposals

Following the decision in Copenhagen to regard legal objects only under Stuff, for the purpose of the
CRM, which does not intend to provide a general model of legal issues, here my proposal for the required
revision of the respective scope notes:

E30 Right

Subclass of: Conceptual Object

Scope Note: Rights are used in the sense of legal privileges such as the right of property, reproduction rights, etc.

New proposed scope note:
Scope Note: Rights are used in the sense of legal privileges on the use of material and immaterial things and derivatives of those, such as the right of property, reproduction rights, etc.
Example: Copyright of CIDOC on the "Definition of the CIDOC Conceptual Reference Model", version 2.1
==================================================================

E72 Legal Object

Subclass of: Stuff
Superclass of: Information Object
Physical Stuff

Scope Note: An identifiable item, which can be owned or people can have a right on. It is not restricted to Stuff. May be Legal Bodies should be included.

Properties:
P104 is subject to (applies to): E30 Right
P105 right held by (has right on): E39 Actor
(P105.1 has type: E55 Type)

New proposed scope note:
Scope Note: A material or immaterial item, which can be owned or people can have a right on its use. This holds in general for all material stuff. In the case of conceptual objects however, identity or exploitation may not be clear enough to become subject to a right, such as taxa and inspirations. Ownership of corporations it currently regarded as out of scope of the CRM.
Example: The Cullinan, "Definition of the CIDOC Conceptual Reference Model", version 2.1.

15/9/2002

Outcome

E30 Right: New scope note:
The Right class is used in the sense of legal privileges to use material and immaterial things and their derivatives. For example the right of property, reproduction rights, etc.
Example Copyright of ICOM in the "Definition of the CIDOC Conceptual Reference Model" Version 2.1.

E72 Legal Object: New Scope Note:
The Legal Object class comprises of those material or immaterial items to which rights, such as the right of ownership or use, can be applied. This is true for all material stuff. In the case of conceptual objects, however, the identity of the conceptual object or the method of its use may be too ambiguous to reliably establish rights, as in the case of taxa and inspirations. Ownership of corporations is currently regarded as out of scope of the CRM.
Example: The Cullinan diamond, "Definition of the CIDOC Conceptual Reference Model", version 2.1.

Proposal Accepted

Rethymnon 24/10/2002

Status done
Working Group 3
Starting Date 2002-09-15
Closing Date 2002-10-24



Issue No:116
Title The new CIDOC CRM web site
Background
Old Proposals
Current Proposals
Outcome
Status open
Working Group 4
Starting Date 2002-11-19
Closing Date In Progress



Issue No:117
Title For P62, property P62.1 mode of depiction is missing
Background
Old Proposals
Current Proposals

For P138 visualizes, add property on property P138.1 mode of depiction (this is an equivalent to P62.1). Given the existence of P67.1, do we need this? We probably do. The new scope note of P62.1 will need to be checked for consistency of usage.

  • Upgrading Physical Stuff
  • Occurred in the presence of

Rethymon 22/10/2002

Outcome Proposal Accepted 22/10/2002
Status done
Working Group 1
Starting Date 2002-10-22
Closing Date 2002-10-22



Issue No:118
Title P30 transferred custody not to be a sub property of P12 occurred in the presence of
Background
Old Proposals
Current Proposals

It was agreed that transfer of custody does not imply the presence of the object of that custody transfer. See Issue 112.

Rethymnon 22/10/2002

Outcome Proposal Accepted 22/10/2002
Status done
Working Group 1
Starting Date 2002-10-22
Closing Date 2002-10-22



Issue No:120
Title Naming rules for properties
Background
Old Proposals
Current Proposals

Naming rules for properties of properties needs to be added to the Naming Rules section.

The reading of property names should be consistent throughout the document using Domain to Range or Range to Domain (not using Left to Right or Back to Front).

Rethymnon 22/10/2002

Outcome Proposal Accepted 22/10/2002
Status done
Working Group 3
Starting Date 2002-10-22
Closing Date 2002-10-22



Issue No:121
Title E12 Production Event
Background
Old Proposals
Current Proposals

E12 Production Event: In the scope note the categorical examples should be repeated as factual ones.

Rethymnon 23/10/2002

Outcome
Status open
Working Group 3
Starting Date 2002-10-23
Closing Date In Progress



Issue No:122
Title Should the word "characteristically" be added to the scope note of all sub-classes of Appellation?
Background

Should the word "characteristically" be added to the scope note of all sub-classes of Appellation? E.g. " …characteristically used to identify

Rethymnon 23/10/2002

Old Proposals
Current Proposals
Outcome
Status open
Working Group 3
Starting Date 2002-10-23
Closing Date In Progress



Issue No:123
Title Reclassification needs to be considered
Background

The process of reclassification needs to be considered (e.g. "not dog").

Rethymnon 24/10/2002

Old Proposals
Current Proposals
Outcome
Status open
Working Group 1
Starting Date 2002-10-24
Closing Date In Progress



Issue No:124
Title Scope note for E84 Information Carrier needed
Background
Old Proposals
Current Proposals

"This class comprises all instances of man-made objects that are explicitly designed to act as persistent physical carriers for instances of E73 Information Objects. This allows a relationship to be asserted between a physical object and its immaterial information contents.

Examples: The Rosetta Stone; My paperback copy of Crime and Punishment; the computer disk at ICS-FORTH that stores the canonical Definition of the CIDOC.

Rethymnon 24/10/2002

Outcome Proposal Accepted 24/10/2002
Status done
Working Group 3
Starting Date 2002-10-24
Closing Date 2002-10-22



Issue No:125
Title What notion of semantic interoperability should be contained within the CRM?
Background
Old Proposals
Current Proposals
Outcome
Status open
Working Group 3
Starting Date 2002-10-24
Closing Date In Progress



Issue No:126
Title Explanation of Allen Operations
Background Allen's Temporal Relationships are not easy to comprehend on a theoretical base, even though archeologists have rich examples.
Old Proposals
Current Proposals

There should be a specific section in the introduction to the CIDOC CRM explaining Allen's Temporal Relationships:

Examples of Allen operators:

Late Bronze Age finishes Bronze Age
Early Bronze Age starts Bronze Age

Graphical documentation would help to clarify this.






Place:

  • Falls within
  • Consists of
  • Overlaps with
  • Borders with

Period ·

  • Falls within
  • Consists of
  • Overlaps
  • Is separate from

Rethymnon 25/10/2002

Outcome
Status open
Working Group 3
Starting Date 2002-10-25
Closing Date In Progress