Post by Wolfgang Schmidle (4 October 2022)
Dear all,
I am struggling with the E13 scope note: This class comprises the actions of making assertions about one property of an object or any single relation between two items or concepts. The type of the property asserted to hold between two items or concepts can be described by the property P177 assigned property [of] type: E55 Type.
It seems that the word "property" is used here in the sense of "any property one can think of", as in "The condition assessment of the endband cores of MS Sinai Greek 418 (E14) assigned property of type damage (E55)", as well as in the sense of "a CRM property", is that right?
And I found the last paragraph particularly difficult to understand: All cases of properties in this model that are also described indirectly through a subclass of E13 Attribute Assignment are characterised as "short cuts" of a path via this subclass. This redundant modelling of two alternative views is preferred because many implementations may have good reasons to model either the action of assertion or the short cut, and the relation between both alternatives can be captured by simple rules.
- What does "this model" refer to? The CRM?
- What does the "two alternative views" refer to? When I model a Property directly or via E13?
- What are the "simple rules"? Does this mean a transformation like this?
- Ex Py Ez
- Ex P140i was attributed by E13 Attribute Assignment (P177 assigned property of type "Py") P141 assigned Ez
- Should "short cut" be "shortcut" (and possibly without " ")? (Yes, there is a place for small edits, but I am really not sure about this.)
- Do the "any CRM property" paths (via E13) that can reify any CRM property have any relationship with the paths of "explicit" shortcuts (not via E13) at all? For example:
- shortcut: E72 Legal Object P105 right held by E39 Actor
- explicit path: E72 Legal Object P104 is subject to E30 Right P75i is possessed by E39 Actor
- via E13: E72 Legal Object P140i was attributed by E13 Attribute Assignment (P177 assigned property of type "P105 right held by") P141 assigned E39 Actor
- shortcut: E1 CRM Entity P1 is identified by E42 Identifier
- explicit path: E1 CRM Entity P140i was attributed by E15 Identifier Assignment P37 assigned E42 Identifier
- via E13: E1 CRM Entity P140i was attributed by E13 Attribute Assignment (P177 assigned property of type "P1 is identified by") P141 assigned E42 Identifier
6. Or is this paragraph no longer about E13 but explicitly about the subclasses of E13, as the first sentence seems to suggest? If yes, is this sentence talking about "any CRM property" paths or the long forms of explicit shortcuts for the Properties from the following list?
- E14 Condition Assessment: P44 has condition
- E15 Identifier Assignment: P48 has preferred identifier, or P1 is identified by (if the E41 Appellation is also an E42 Identifier)
- E16 Measurement: P43 has dimension (if the E70 Thing is also a E18 Physical Thing and thus can be measured)
- E17 Type Assignment: P2 has type
In other words: No "explicit" shortcuts are mentioned for E13. Do the subclasses E14, E15, E16, E17 somehow inherit the ability to create "any CRM property" paths, or are they only used in the long forms of "explicit" shortcuts of the following properties?
- P38 "deassigned" is only for Identifiers. How would one express the general situation when an attribute gets deassigned?
(Both P37 "assigned" and P38 "deassigned" are in fact subproperties of P141 "assigned". On the other hand, according to its scope note P1 is a shortcut for "P140i was attributed by E15 Identifier Assignment P37 assigned" but the counterpart "P140i was attributed by E15 Identifier Assignment P38 deassigned" is not mentioned.) - Both E15 and E17 can be applied to any E1 CMR Entity. Why is there a subproperty P41 "classified (was classified by)" of P140 "assigned attribute to (was attributed by)" for E17 Type Assignment, but no subproperty of P140 for E15 Identifier Assignment?
Best,
Wolfgang
Post by Martin Doerr (4 October 2022)
Dear Wolfgang,
Nice ISSUE to review!
I think this C should be deleted. When we wrote the third paragraph, we had abandoned the policy to generally regard properties as shortcuts of assertions by third parties, and deleted many shortcut expansion statements. We introduced the concept of a maintainer of the KB as default whose opinion the KB represents.
I think the last paragraph became obsolete by that time.
At least some subclasses of E13 thought of here are cases in which the shortcut property is produced, rather than recognized, by an explicit necessary action - the measurement, but also having an identifier.
The idea is indeed that E13 may also be used for describing properties not in the CRM.
Best,
Martin
In the 55th joint meeting of the CIDOC CRM and SO/TC46/SC4/WG9; 48th FRBR/LRMoo SIG meeting, the SIG talked about the questions raised by WS on the last paragraph of E13 Attribute Assignment. Said questions will no longer be relevant if the SIG accepts the proposal by MD to delete the paragraph.
- “All cases of properties in this model that are also described indirectly through a subclass of E13 Attribute Assignment are characterised as "short cuts" of a path via this subclass. This redundant modelling of two alternative views is preferred because many implementations may have good reasons to model either the action of assertion or the short cut, and the relation between both alternatives can be captured by simple rules.”
Decision: postpone until a proposal has formally been made
A summary of the other questions posed by WS to the SIG and the main discussion points can be found in the attached document.
Belval, December 2022
In the 56th joint meeting of the CIDOC CRM and ISO/TC46/SC4/WG9 &49th FRBR/LRMoo SIG, the SIG approved the proposal by MD & WS to deprecate the last paragraph in the scope note of E13 Attribute Assignment.
Details of the decision can be found in the attached document.
Crete, May 2023
Post by Martin Doerr (24 August 2023)
Dear All,
I propose to close issue 615 by e-vote. The new text for E13 Attribute assignment has been approved already. Trailing an issue into another entity is not good practice, but to answer the question:
As a rule, multiple properties of a superclass should not be specialized altogether by analogy. Properties are and must be specialized if and only if they convey a more specific meaning than the superproperty of the superclass in the context of the subclass. Obviously, there is nothing you can say about an entity that enables it to have an Identifier assigned and not only an Appellation. Conversely, there should exist at least one entity that, by its nature, cannot be assigned an identifier to.
This rule, even though general KR, may be worthwhile to be documented as another ISSUE. We had more frequently cases in CRM extensions, were properties were not specialized but should have been.
Best,
Martin
In the 60th joint meeting of the CIDOC CRM and ISO/TC46/SC4/WG9 & 53rd FRBR/LRMoo SIG, the group appointed WS to look at the issue, because no progress has been made in the past, and in the meantime new issues about the semantics of E13 have started and they do seem to have a great deal of overlap (like 694 for example).
Bern, April 2025
Wolfgang Schmidle shared HW on the issue --14 October 2025
The document can be found here.
In the 61st joint meeting of the CIDOC CRM and ISO/TC46/SC4/WG9 & 54th FRBR/LRMoo SIG, WS shared with the SIG the proposal to redraft the scope note of E13 Attribute Assignment. The proposal involved adding a clause to the scope note that expands on the kind of property/relation attributed by an instance of E13.
Since the proposal had not been made before the SIG meeting, it was decided that it be handled through an evote instead.
The details of the proposal can be found in the attached document.
Heraklion, October 2025
Post by Eleni Tsouloucha [e-vote] (13 January 2026)
Dear all,
Please reply by yes or no to the proposal formally made at the 61st SIG meeting, namely to add the clause marked in boldface to the scope note of E13 Attribute Assignment.
The reason that the group would not vote on it at the time, is that it was made at the meeting.
You have until the end of next week (23 January 2026) to vote on it.
++++++++++++++
E13 Attribute Assignment
Subclass of: E7 Activity
Superclass of: E14 Condition Assessment, E15 Identifier Assignment, E16 Measurement, E17 Type Assignment
Scope note: This class comprises the actions of making assertions about one property of an object or any single relation between two items or concepts. The property or relation does not have to be part of the CRM. The type of the property asserted to hold between two items or concepts can be described by the property P177 assigned property of type (is type of property assigned): E55 Type.
For example, the class describes the actions of people making propositions and statements during certain scientific/scholarly procedures, e.g., the person and date when a condition statement was made, an identifier was assigned, the museum object was measured, etc. Which kinds of such assignments and statements need to be documented explicitly in structures of a schema rather than free text, depends on whether this information should be accessible by structured queries.
This class allows for the documentation of how the respective assignment came about, and whose opinion it was. Note that all instances of properties described in a knowledge base are the opinion of someone. Per default, they are the opinion of the team maintaining the knowledge base. This fact must not individually be registered for all instances of properties provided by the maintaining team, because it would result in an endless recursion of whose opinion was the description of an opinion. Therefore, the use of instances of E13 Attribute Assignment marks the fact that the maintaining team is in general neutral to the validity of the respective assertion, but registers someone else’s opinion and how it came about.
All properties assigned in such an action can also be seen as directly relating the respective pair of items or concepts. Multiple use of instances of E13 Attribute Assignment may possibly lead to a collection of contradictory values.
Examples:
- the examination of MS Sinai Greek 418 by Nicholas Pickwoad in November 2003 (Honey & Pickwoad, 2010)
- the assessment of the current ownership of Martin Doerr’s silver cup in February 1997 (fictitious)
In first-order logic: E13(x) ⇒ E7(x)
Properties:
P140 assigned attribute to (was attributed by): E1 CRM Entity
P141 assigned (was assigned by): E1 CRM Entity
P177 assigned property of type (is type of property assigned): E55 Type
+++++++++++++
All the best,
Post by Guenther Goerz (13 January 2026) [pc]
yes
Best wishes
— Guenther
Post by Stephen Stead (13 January 2026)
YES
Post by Robert Sanderson (13 January 2026)
YES
Post by Martijn van Leusen (13 January 2026)
Dear all,
the import of the phrase in bold is not clear to me. The property or relation itself does not have to be part of the CRM, but assertions about it are? Can this be clarified using the examples?
Martijn
Post by Martin Doerr (13 January 2026)
Dear All,
I vote YES,
BUT! I suggest to reformulate:
"The property or relation needs not be part of the CRM." because this is less ambiguous for non-native speakers of English....
In answer to Martijn, see the current examples of P177:
- The examination of MS Sinai Greek 418 (E13) assigned property of type binding structure type (E55). [‘binding structure type’ refers to a property, external to the CIDOC CRM, which connects a book (E22) to the type of its binding structure (E55)] (Honey & Pickwoad, 2010)
- The condition assessment of the endband cores of MS Sinai Greek 418 (E14) assigned property of type damage (E55.) [‘damage’ refers to a property, external to the CIDOC CRM, which connects an instance of a physical thing like an endband core (E22) to the type of damage (E55) it shows] (Honey & Pickwoad, 2010)
- The condition assessment of the cover of MS Sinai Greek 418 (E14) assigned property of type quality (E55). [‘quality’ refers to a property, external to the CIDOC CRM, which connects an instance of a physical thing like a book cover (E22) to its quality (E55)] (Honey and Pickwoad, 2010)
Post by Stephen Stead (13 January 2026)
"The property or relation need not be part of the CRM."
Post by Christian Weiss (13 January 2026)
YES
Post by Thanasis Velios (13 January 2026)
YES
Thanasis
Post by Daria Hookk (13 January 2026) [pc]
YES
Post by Pat Riva (14 January 2026)
YES
(either formulation, both work well in English)
Post by George Bruseker (14 January 2026)
YES
either formulation seems fine
Christian-Emil Ore (14 January 2026)
YES
Chr-E
Post by Gerald Hiebel (14 January 2026)
YES
Best,
Gerald
Post by Oyvind Eide (15 January 2026)
YES
Muriel Van Ruymbeke (20 January 2026) [pc]
Yes
There were 13 votes in favor of the proposed change. The use of "need not" vs "does not have to" is considered editorial, which means that we don't need another voting round for it. The new definition (see below) will appear in CIDOC CRM v7.3.2
+++
E13 Attribute Assignment
Subclass of: E7 Activity
Superclass of: E14 Condition Assessment, E15 Identifier Assignment, E16 Measurement, E17 Type Assignment
Scope note: This class comprises the actions of making assertions about one property of an object or any single relation between two items or concepts. The property or relation need not be part of the CRM. The type of the property asserted to hold between two items or concepts can be described by the property P177 assigned property of type (is type of property assigned): E55 Type.
For example, the class describes the actions of people making propositions and statements during certain scientific/scholarly procedures, e.g., the person and date when a condition statement was made, an identifier was assigned, the museum object was measured, etc. Which kinds of such assignments and statements need to be documented explicitly in structures of a schema rather than free text, depends on whether this information should be accessible by structured queries.
This class allows for the documentation of how the respective assignment came about, and whose opinion it was. Note that all instances of properties described in a knowledge base are the opinion of someone. Per default, they are the opinion of the team maintaining the knowledge base. This fact must not individually be registered for all instances of properties provided by the maintaining team, because it would result in an endless recursion of whose opinion was the description of an opinion. Therefore, the use of instances of E13 Attribute Assignment marks the fact that the maintaining team is in general neutral to the validity of the respective assertion, but registers someone else’s opinion and how it came about.
All properties assigned in such an action can also be seen as directly relating the respective pair of items or concepts. Multiple use of instances of E13 Attribute Assignment may possibly lead to a collection of contradictory values.
Examples:
- the examination of MS Sinai Greek 418 by Nicholas Pickwoad in November 2003 (Honey & Pickwoad, 2010)
- the assessment of the current ownership of Martin Doerr’s silver cup in February 1997 (fictitious)
In first-order logic: E13(x) ⇒ E7(x)
Properties:
P140 assigned attribute to (was attributed by): E1 CRM Entity
P141 assigned (was assigned by): E1 CRM Entity
P177 assigned property of type (is type of property assigned): E55 Type