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.

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.

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.

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"

Proposal accepted, Copenhagen 2/7/2002.

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"

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)

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.

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.

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.

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.

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.

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.

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

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.

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

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

MD 20/6/2002

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.

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.

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

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.

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

Rethymnon 22/10/2002

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.

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.

The model has been changed – dealt with by Issue 127.

Issue closed.

Oxford 7/10/2003

In scope. Working Group 4.

Adopt CHIOS Dissemination Plan. Develop training plan. 

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.

Solved via issue 4.

Paris 18/10/2001.

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

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

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.

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

MD, January 2002.

Rename:

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

Monterey 21/2/2002.

Delete E76, P61. 

Monterey 22/2/2002.

In scope, Working Group 2

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

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.

• 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.

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.

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.

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.

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

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

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.

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.

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.

Issue covered by Issue 76. :

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

Copenhagen 2/7/2002

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.

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.

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

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.

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

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

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.

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

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

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.

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)

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.

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

Monterey 22/2/2002.

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.

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.

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.

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

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

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.

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.

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.

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.

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.

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.

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.org/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.

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

The generic model would be:

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:

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

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

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.

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

Monterey 20/2/2002.

Change Property Name P17 was motivation for to was motivated by

Monterey 20/2/2002.

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

Monterey 20/2/2002.

P18 is deleted by Issue 70.

Copenhagen 3/7/2002.

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

Monterey 20/2/2002.

Approved and implemented.

Copenhagen 5/7/2002.

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

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

Proposal accepted, Copenhagen 3/7/2002.

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.

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

Copenhagen 3/7/2002.

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.

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

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.

Delete P66 refers to concept.

Include the meaning of subject relationship in P67

Monterey 21/2/2002.

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

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.

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"

Proposal 2 (verbose):

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

MD 20/6/2002

Delete P85 consists of.

Monterey 21/2/2002.

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

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.

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.

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

Christian-Emil Ore, 21/2/2002.

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).

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

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

E77 Persistent Item

E18 Physical Stuff

E28 Conceptual Object

16/10/2002

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

Proposal Accepted

Rethymnon 22/10/2002