Post by Chris Banks (14 September 2026)
A provenance record in a museum or archive routinely lacks a value the model expects: no P23 transferred title from for an acquisition, no P7 took place at for a production, no P52 has current owner for a period. In practice, the record leaves the field empty. From outside, an empty field cannot tell a reader whether the value was never sought, was sought and not found, cannot be recovered by anyone, or does not apply to this object. Those are four different facts about the record; they license four different actions by the next researcher (stop looking; keep looking; ask someone else; do not ask), and an empty field conflates them.
The CRM already handles the neighboring cases and, as far as I can find, not this one. Negative properties state that a relationship is known not to hold (NP: "X was not produced by Y"), which is a claim about the world and requires positive knowledge of the negation; they are explicitly not for cases where the value is simply unknown or unresearched. CRMinf's I6 Belief Value carries TRUE, FALSE, and UNKNOWN about a stated proposition, and its scope note recommends a richer vocabulary without prescribing one; its axis is confidence in a proposition, not the reason a record holds no proposition at all. E13 Attribute Assignment documents the act of assigning a value, and every worked example I can find assigns a value.
What is missing is the documentation act with no assigned value: a record's statement that it looked, or has not looked, or cannot, or need not. Because this is a statement about the record and the party keeping it, and not about the object's history, it is consistent with the open-world assumption: a second record that supplies the value does not contradict it, it supersedes it.
I raise this from practice. I publish an open specification for provenance records with declared absence (Lacuna, v0.5, CC BY, DOI 10.5281/zenodo.22063353, https://www.google.com/url?q=https://www.objectsofaffectioncollection.c…), in which a gap is a typed, reasoned entry with the same standing as a fact, and the question of how such entries map to the CRM is the one alignment its author has not specified and would rather ask the SIG than answer alone. Eleven records have been written to it; none by a CRM implementer yet. In the same period, I have asked registrars and documentation heads at national museums on four continents, and none report a system that keeps the four cases apart.
Current Proposal (offered for discussion; no new classes or properties are required for the first two parts)
(a) Confirm, by a sentence in the E13 Attribute Assignment scope note or an example, that an instance of E13 MAY document that a property of a given type was sought for an entity and that no value was assigned, i.e. E13 with P140 assigned attribute to and P177 assigned property of type and without P141 assigned value, carried out by (P14) a documented actor at (P4) a documented time, with (P3) a note stating the reason.
(b) Recommend, as CRMinf does for belief values, a minimal vocabulary of E55 Type for such documentation acts, applied by P2 has type, with four members and a completeness test that each member licenses a different action by the reader:
- unknowable: the fact cannot be recovered by anyone (stop looking)
- not applicable: the question does not arise for this entity (stop asking)
- not yet obtained: the fact exists and has not been collected (this is work, and it can be closed; the act SHOULD name, via P67, the actor who can close it)
- never required: the question is not proper to ask here (do not ask)
A vocabulary whose members produce identical behavior is one state wearing four names; the four above were chosen because they do not.
(c) Note, in the section that introduces the negative properties, that NP asserts a known negation about the world and that the unknown or unresearched case is documented by the pattern in (a) and (b), so that implementers do not reach for NP to express "we do not know."
(d) Withholding is a separate case and is not proposed here: a value that is known and deliberately not disclosed is a rights or access statement about a known value, not an absence. I mention it only so the vocabulary in (b) doesn't stretch to cover it.
Example (Turtle, abbreviated):
<acq_1824> a crm:E8_Acquisition ; crm:P24_transferred_title_of <obj_206> ; crm:P23_transferred_title_from <drovetti> .
<doc_act_1> a crm:E13_Attribute_Assignment ;
crm:P140_assigned_attribute_to <obj_206> ;
crm:P177_assigned_property_of_type crm:P7_took_place_at ; # the find-spot was sought
crm:P2_has_type <absence/unknowable> ;
crm:P14_carried_out_by <museum_documentation_desk> ;
crm:P4_has_time-span <ts_2026-09-13> ;
crm:P3_has_note "The acquisition papers record the vendor and the year and no find-spot; the vendor's agents are known to have bought in the open market; no source that could supply the find-spot is known to survive." .
Post by Athina Kritsotaki (14 September 2026)
Dear all,
I see the problem and in my opinion, it exists as a problem and makes
sense for the community; however, I am not sure if this is a gap of
CIDOC CRM base. I think that it is declared in the introduction that the
CIDOC CRM follows the open world assumption and that the knowledge is
incomplete and the model respects this principle.
At the level of data we cannot impose closed world constraints because
of the incompleteness of our particular knowledge at any one time. There
is guideline in the principles of "How can I represent characteristic
states of lack of knowledge in my modelling" (and to avoid strict rules
of closed world - we remember the problem with the current values and
properties).
I think this is an issue of implementation that the model does not
foresee. This kind of knowledge validity is an issue for the knowledge
manager. States can be managed by the database manager who should be
able to verify the respective reality at the latest date of validity of
the database. In the introduction there is this:
"...This does not imply that the knowledge described in the KB is
complete. So long as the information is under active management, it
remains continuously open to revision and improvement as further
research reveals further understandings. A KB does not represent a
slice of reality, but the justified beliefs of its maintainers about
that reality. For simplicity, we speak about a KB as representing some
reality.
......
Quantifiers for properties are provided for the purpose of semantic
clarification only, and should not be treated as implementation
recommendations. The CIDOC CRM has been designed to accommodate
alternative opinions and incomplete information, and therefore all
properties should be implemented as optional and repeatable for their
domain and range (“many to many (0,n:0,n)”).....
Note that if a dependent property is not specified for an instance of
the respective domain or range, it means that the property exists, but
the value on one side of the property is unknown. In the case of
optional properties, the methodology proposed by the CIDOC CRM does not
distinguish between a value being unknown or the property not being
applicable at all. For example, one may know that an object has an
owner, but the owner is unknown. In a CIDOC CRM instance this case
cannot be distinguished from the fact that the object has no owner at
all. Of course, such details can always be specified by a textual note.
..."
This is my opinion, however it should be discussed in the meeting as an
interesting issue that exists in documentation reality.
Best,
Athina
‘States’ are not modelled in CRM Basic because they are subject to
strong interpretational ambiguity (and therefore false instance association)
Post by Chris Banks (14 September 2026)
Dear Athina,
Thank you, and thank you for finding the sentence in the introduction, because it is the one the issue rests on: "the methodology proposed by the CIDOC CRM does not distinguish between a value being unknown or the property not being applicable at all... such details can always be specified by a textual note." I agree with every word of it, including the open world assumption, and I would put the proposal inside that sentence rather than against it.
The distinction I am after is not a state of the object, and I would not want to model one; you are right that states carry interpretational ambiguity. It is a fact about the documentation: that a particular actor, on a particular date, sought a value and recorded why none was assigned. That is an E13 Attribute Assignment with an actor and a time and no P141. It asserts nothing closed about the world; a later E13 that assigns the value does not contradict it; it supersedes it. So part (a) asks only that the scope note or an example say that E13 may be used this way, which is the textual note the introduction already permits, given a place where a machine can find it.
Part (b), the four-member vocabulary, I would happily keep outside the base model, as a recommendation in the same spirit as CRMinf's belief values, and let implementers adopt or ignore it.
So the question I would bring to Nuremberg is narrower than the issue as posted: is (a) alone acceptable as the base-model part, with (b) as guidance? If the answer is that even (a) belongs in implementation guidance rather than the scope note, that is a useful answer too, and I would ask where the SIG would want it written so that the next implementer finds it.
Thank you for taking it seriously so quickly.
Christopher Banks
Post by George Bruseker (14 September 2026)
Dear all,
I have certainly run into this use case as well working on provenance data with the Getty Provenance Index. It is a real issue to represent this meta documentation that, in fact, someone has looked at some aspect of the world and has specifically said or not said things for various reasons.
This actually feels much closer to the original intent of E13 than many of the stretch applications it is put to once we try to document richer historical data. It is an interesting case and regardless what outcome we came to, I would think it worth discussion at Nuremberg.
So, seconded, on my part.
Cheers,
George
Post by Martin Doerr (14 September 2026)
Dear All,
Of course this will appear in the issues list!
Note that these are epistmological questions, deliberately kept out of
CRMbase so far, because of their theoretical complexity, and not because
they are not thought of.
In my mind, this is a CRMinf issue, even though a simplified notation
may be useful. The values proposed for Belief Value are minimal, not a
restriction.
The main problem is the question how do you want to deal with querying
such information.
SPARQL so far cannot even deal with UNKOWN properties.
Logical reasoning with such information is quite different from
informing a human reader.
The different cases described below appear to me to pertain to different
kinds of informing, possible actions and reasoning.
From this widely depends, if a solution in CRMbase for E13 is adequate.
I think this is worth more analysis of the different cases. E.g., so
far, only for necessary properties we can assert from the absence that
they are unknown. Optional properties that are not applicable are
interesting: Why should that be? Is that the case for a whole subclass
or only for a particular?
I'll give you more feed back the next days.
Best,
Martin
Post by Chris Banks (14 September 2026)
Dear Martin,
Thank you. That it will appear in the issues list is what I asked for, and I am content with CRMinf as the home if that is where the SIG puts it; I just need a place the next implementer can find.
On querying, you are right and I should have said so. The four types were built to tell the next researcher what to do, which is to inform a reader, not to infer. A SPARQL query can find the documentation act by its type and its actor; it cannot reason from it, and I make no claim that it should.
On your question, from the eleven records written so far: "not applicable" has arisen only for a particular, never for a subclass. The case was a gift. The object's record has no consideration because nothing was exchanged, a fact about that object's history, while acquisitions as a class plainly have one. Where the property does not apply to a whole subclass, that is a fact about the model, not the record, and I would not want it documented as an act. So the narrowing you point to is right: the pattern is for the particular, and the reason is always a fact of that entity's history.
I will wait for your further notes and bring the case analysis to Nuremberg in whatever form the SIG prefers.
George, thank you for the second, and for placing it against the Getty Provenance Index; that is exactly the data I hoped had met this.
Christopher Banks