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
Post by Zoe Renaudie (22 September 2026)
Dear all,
I'm discovering this thread with interest. I'm new to both semantic web technologies and to this SIG, so please read what follows as questions from someone still learning the vocabulary, not as settled positions.
I have been working on a related problem from a different angle, I hope it is the place to share and I'd be glad to compare notes if it's useful. My starting point is a conservation report I wrote in 2017 for the preservation of an exhibition, where I used a colour code, in an entirely informal way at the time, to mark what was verified, what was missing, what was uncertain, and what had once been valid but no longer was. I added the notion of opacity, when an information exist but cannot be transmitted for legal, privacy or community reasons. Part of what drives this for me is a practical need: I need to be able to quantify, even roughly, what percentage of what is knowable about an artwork is actually known. I use CIDOC-CRM and its extensions to structure documentation for exhibitions and also for Indigenous collections, which is part of why opacity matters as its own case, not a variant of absence.
Trying to translating that into CRM terms, I ended up with something close to what Christopher describes: a value asserted with confidence goes one way, a value never obtained goes another, a value known but withheld a third. I used CRMinf for the confidence axis, and experimented with two subclasses of E13 for lacunae (Negative_Attribute_Assigment) and opacity (Witheld_Attribute_Assigment), typing the lacuna subclass with a vocabulary similar to Christopher's four members, and the opacity subclass with TK Labels for the cases where the restriction is a community protocol rather than an institutional choice. I chose subclasses because I need to visualise and query absences and withheld values with some precision, across a fairly large documentation set but I am not sure it is the right way to do it.
ex:Negative_Attribute_Assignment a owl:Class ;
rdfs:subClassOf crm:E13_Attribute_Assignment ;
rdfs:label "Negative Attribute Assignment"@en ;
rdfs:comment "Records a search having been carried out for the value of a property, and having found none." .
ex:Withheld_Attribute_Assignment a owl:Class ;
rdfs:subClassOf crm:E13_Attribute_Assignment ;
rdfs:label "Withheld Attribute Assignment"@en ;
rdfs:comment "Records a known value having been deliberately withheld by a named actor, optionally under a stated condition of access." .
On where this sits relative to NP and NTP: I don't think it belongs there because my lacuna declarations always carry an author and a date, they say that a named person, at a given moment, looked and found nothing, not that the object itself lacks the relationship. A later search by someone else doesn't contradict that record, it adds to it. That authorship is what keeps the declaration in the open world, and it's also, I think, the same point Christopher makes about the act belonging to the record rather than to the object's history.
I presented this at DH this summer, but the session didn’t spark the discussion I’d hoped for, so it's genuinely useful to see the same ground being worked through here, with more experience of how the SIG handles this kind of question. I plan to present my full model (once further developed) at the next SIG meeting.
Thank you and best regards,
Zoë Renaudie
Post by Thanasis Velios (22 September 2026)
Dear all,
This is indeed an interesting discussion and I am hoping I will be able
to join online for it at the next meeting. One aspect that is necessary
to consider is the circumstances under which such negative statements
are made. For example, something is "unknowable" with the available
expertise and examination tools, but it could be "knowable" if
examination is done in a different way by someone else. Therefore, the
added complexity may be in describing the closed world environment that
this negative statement is valid for.
All the best,
Thanasis
P.S. At the St. Catherine's condition survey we used "not checked" (I
forgot to ask), "not applicable" (the question is irrelevant) and "not
known" (I asked but I couldn't answer + known observation conditions,
agent, time, etc.)
Post by Chris Banks (22 September 2026)
Dear all,
Zoe, Thanasis, thank you both. Two things in your messages change what I was about to send, so I will take those first and then give Martin the analysis he asked for.
1. A CORRECTION TO MY OWN ISSUE TEXT
Thanasis, your postscript names a working vocabulary: at the St Catherine's condition survey you used "not checked" (I forgot to ask), "not applicable" (the question is irrelevant) and "not known" (I asked but I couldn't answer, with observation conditions, agent and time recorded).
My issue text of 13 September said that I had asked registrars and documentation heads at national museums on four continents and that none reported a system keeping the four cases apart. That sentence was too strong, and your postscript is why. What I could honestly claim is narrower: none of the people I asked reported one. That is a statement about whom I asked, not about the field. Your survey keeps three of the four apart and records the observation conditions alongside, which is more than the pattern in the issue asks for. I would rather correct that on the list now than carry it into Nuremberg.
It sharpens the issue rather than weakening it. If a condition survey already distinguishes these states in practice, the question for the SIG is not whether the distinction is needed. It is why it has no home in the model, so that the next implementer does not have to invent the vocabulary privately, as you did, as Zoe did, and as I did.
2. ON THE CLOSED WORLD, WHICH I THINK IS THE STRONGEST OBJECTION TO "UNKNOWABLE"
Thanasis, you are right that something unknowable with the available expertise and tools may be knowable if examined differently by someone else, and that the added complexity is describing the environment the negative statement is valid for.
I would put it this way: the act is never a claim about the world. It carries P14 carried out by and P4 has time-span precisely because it is one party's statement, at one moment, about one search space. A later search that succeeds does not contradict it; it supersedes it, and both remain readable. If the scope note for such a member said that explicitly, I think your objection is answered without new machinery. If it cannot be said plainly enough, then the member is misnamed and I would rather rename it than defend it.
The records bear you out. Of five entries typed unknowable across fourteen records, four rest on a named act that returned nothing: a magazine, forensic investigators, a foundation holding the subject's own records and a federal court for one; a probate court finding for another. The fifth rests on a source's silence and one physical fact, is the weakest of the five, and the record says so in those terms and commits to restating it if a named researcher's work supplies the answer. That entry is the one your objection is about, and it was already flagged as the weak case before you wrote.
3. ZOE
Your model and mine converge on the part I was least sure of and diverge exactly where I stopped.
We agree that the declaration carries an author and a date, and that this is what keeps it in the open world. You put it better than I did: a later search adds to the record rather than contradicting it.
Where you have gone further is opacity. My issue text sets withholding aside at (d) as a rights or access statement rather than an absence, and says so only to stop the four-member vocabulary stretching to cover it. You have built the thing I declined to build, and the Traditional Knowledge Labels are a route I do not have and would not have found. In fourteen records I have six withholding entries, all of them institutional or commercial (a house declining to name a buyer, a maker declining to name a mill). None is a community protocol. Your case is the one my evidence cannot reach.
One honest note from my side, because it is a finding about the format rather than about the objects: seven entries filed in my withholding section say of themselves that no party withheld the value and nobody recorded it. Those are absences filed under the wrong heading, by me. A sum that no source records and no party withholds is an absence. I am correcting the specification rather than the records, because a record that silently corrects itself is the thing this work is against.
On subclasses against typed E13: I have no position worth defending. I chose a typed E13 because it needs no schema change and I wanted to ask for as little as possible. You chose subclasses because you need to visualize and query absences and withheld values with precision across a large documentation set, which is a real requirement mine does not have. That is a question for the SIG rather than for either of us, and your quantification goal, what percentage of what is knowable is actually known, is a use case I cannot serve and would like to see served.
If you are presenting at the same meeting, I would rather our two items be read together than separately, and I am happy for mine to go second.
4. THE ANALYSIS MARTIN ASKED FOR
Martin, on 14 September you wrote that this is worth more analysis of the different cases, and asked two questions. Here is what the records show. Counts are dated because they move: twenty-one records now pass the specification's validator, measured today; the analysis below is over the eight readable on 14 September and the fourteen on 16 September, and I will restate it if the shape changes.
Across fourteen records, fifty-five declared absences:
not_yet_obtained 47 every one names a party who could close it
unknowable 5 four rest on a named act that returned nothing
not_applicable 3 all three about the particular
never_required 0
The shape does not change between the two samples. not_yet_obtained is 85 percent of entries in both (21 of 26, then 47 of 55).
Your first question, whether not_applicable is a fact about a subclass or a particular: in every instance it is the particular. One object has no sales price because it was a gift, so no consideration was exchanged. That is a fact about that acquisition, and it is documented because a reader seeing a blank price cannot tell a gift from an unrecorded sum. Where the property does not apply to a whole subclass, that is a fact about the model and I would not document it as an act.
One instance complicates it, and I raise it rather than smooth it. A car's record was asked how many of that body style were made. The maker did not break out production figures by body style, and the source says so. The question is proper to the class and the record answers for the particular by reporting the maker's own statement. Whether that should be typed not_applicable, or whether the guidance should say the question is not to be asked of the instance at all, I have one instance and no position.
Your second question, whether absence can be asserted for optional properties: in the records, every unknowable rests on a positive act. Nobody typed it from a blank. That is what makes it documentable at all, and it is also, I think, the answer to Thanasis: the act is evidence of a search, not a claim about the world.
And the member with no evidence: never_required did not arise once, in eight records or in fourteen. I state that so the silence is not read as completeness. If the SIG wants a vocabulary with three members and a note, that is a defensible reading of this evidence, and I would rather be told so than defend a member no record has used.
5. WHAT I AM ASKING NUREMBERG TO DECIDE, IN ORDER OF HOW LITTLE IT COSTS
1. One sentence in the E13 scope note, or one example, confirming that an E13 may document that a property of a given type was sought and no value assigned. No schema change.
2. One sentence beside the negative properties saying that "we do not know" is not NP and is documented by the above. No schema change.
3. A recommended minimal vocabulary, if the SIG wants one. The records evidence three members and the fourth not at all; the SIG should size it.
4. Routing. CRMinf if that is where it belongs. I need a place the next implementer can find, not a particular home.
Not asked: any change to CRMbase classes or properties, any reasoning semantics, any treatment of withholding.
The full analysis runs to every entry, fifty-five rows with the CRM property sought, the reason in one line, and the party who could close it, together with a comparison against a Linked Art profile used for a large provenance index, and two cases the vocabulary cannot hold. It is long for a list message. I am glad to send it to anyone who wants it now, and will circulate it before the meeting.
Christopher Banks
Post by Chris Banks (26 September 2026)
Dear all,
On 22 September, I said I would circulate the entry tables behind the 723 findings before the meeting. They are here as a link rather than an attachment:
https://drive.google.com/file/d/1Tc-JzFrdyC5fbNWU6_uVuGidhyLOq2hf/view
Fifty-four entries from fourteen provenance records, each written as an E13 Attribute Assignment with no P141 assigned value. It is not a proposal. It is what the records contain, so that the session on the 8th has data to argue with rather than an example.
The count shows three things, and only the third is an opinion. Not-yet-obtained is 85 percent of the fifty-four entries, and each one names a party who could close it, so the absence has an addressee. Every unknowable rests on a positive act that returned nothing, except one, which is the weakest in the set and is labeled as such rather than removed. Never-required occurs zero times in fourteen records, so the vocabulary may want three members rather than four.
One correction is in the document. The recount I circulated privately on 23 September said 47 and 55; the tables hold 46 and 54. The error is mine, and the pattern does not turn on it.
The ask is unchanged and is listed cheapest first at the end.
Sincerely,
Christopher Banks