CRMdig is highly relevant for work undertaken in many projects, but has been idle for far too long and needs to be updated.
Topics that can be elaborated in the model:
- Harmonization with CRMinf, CRMsci, PROV-O, Parthenos Entities Model
- Digitization (see how the human activity relates to the reaction of the machine: for the moment, the human activity that sets in motion the machine reaction and the machine reaction itself are inseparable. What is the temporal and other connection between these two events? Can they be seen as one and the same event?)
- Formal Derivation (Metadata descriptions for digital objects carry over from original to derivatives -assuming the latter retain features of the original digital object.)
- Unreliable transfer
- The relation among D9 Data Object and E54 Dimension and PE22 Dataset (D9 IsA E54 AND D9 IsA PE22)
- The relation between D3 Formal Derivation and S6 Data Evaluation
- D7 Digital Machine Event as E7 Activity vs. triggering an activity.
- F54 Utilized Information Carrier
Decision of the 50th SIG: to pursue this line of work further. Form a working group, formally raise a number of issues through the SIG mailing list and take it from there.
WG: CEO, SdS, GH, ML
Documents to consider:
(1) About CRMdig, (2) PEM, (3) Repository for 3D Model Production and Interpretation in Culture and Beyond, (4) 3d_metadata, (5) CRMdig_v3.1, (6) CRM digital (2.3)
HW: the WG to draft a number of issues for CRMdig.
In the 53rd CIDOC CRM & 46th FRBRoo SIG meeting, the SIG decided to continue in this line of work.
Proposal:
- Look at CRMdig, determine what parts of the model need to be kept in CRMdig vs the things that echo the project they were built to describe.
- Discuss the overlap with PEM.
- Break the model in small subtasks (review properties, Digital Objects etc)
HW: GB to coordinate the group of people involved in this task, CEO, (MD), and confer with ML and GH. Inform the Sig in the next meeting.
May 2022
Post by George Bruseker (17 August 2022)
Dear all,
Given that CRMbase 7.1.1 is now a static entity and needs to be so for the purposes of shepherding it through the ISO process (shout out to Philippe and Erin!), now seems a good time to be doing some consolidation on the many extensions and trying to tighten up official versions of these.
I have taken up the mission of consolidating notes and thoughts from the past few years regarding CRMdig and how to bring it into line with the best practices we have evolved at the CRM SIG.
I have, as a result, formulated the following three powerpoints / proposals:
- CRMdig Cleanup: https://docs.google.com/presentation/d/1xg9PvWh3BPmP_mcnEK5HmbPlj4NvH_MB_Z_7VT7J0uc/edit?usp=sharing
In which I propose a number of deletions and general consolidations to make the extension accord with 7.1.1 and its practices. Here I should acknowledge Rob Sanderson and Nicola Carboni for work which we did on this a number of years ago which I have borrowed from (hold them not responsible for any apostasies!). - CRMdig and CRMpe (Parthenos Entities): https://docs.google.com/presentation/d/1yqqnfEtoM2TJYvliwSVgbYmJoDBXbzh8KUHL7Saa-0M/edit#slide=id.p
Some time ago (it was in Paris in 2018 I think) we agreed to look into how to integrate the work of the Parthenos Project that was relevant to CRMdig into a common framework. In this powerpoint, I illustrate the basic proposals of CRMpe and make some proposals as to what elements might become parts of CRMdig (and other models). - CRMdig and CRMsoc: https://docs.google.com/presentation/d/1Wh3Vb9LInY7w_zx33ixwBvPboI7IxrKPyP5VOyMabik/edit?usp=sharing
In looking over CRMdig, the annotation modelling particular stood out as an outlier and not properly a question of digital workflow. I've done extensive work on how to cover this using the structures of CRMsoc, so here I put in an illustration of how that could be coherently harmonized.
The key point of this exercise, to my opinion, should be to focus on a cleanup of CRMdig that brings it into coherence with our present practice at CRM SIG but also takes into account the knowledge and experience of people who have used it and who have knowledge of other standards and well known practices in the community that should be taken into account.
Therefore, I present the above as a working framework for a discussion and to announce that we will start to have the discussion of improving CRMdig.
For those of you who are interested in the topic and have opinions on what is done right or wrong there, it would be great to hear your input, nothing suggested above is set in stone, but is meant to start the conversation.
To that end, if people want to make structured remarks regarding the proposals before the meeting, you can of course always use the emailing back and forth feature of the list OR you could make your remarks in this handy google doc I have constructed for that purpose: https://docs.google.com/document/d/1Qn9I3wsZYJIJ0NoHkzyolCLPX1YvdHv8-48TtiOkk8o/edit?usp=sharing
This review is well overdue and is a nice, concentrated piece of action which we could take up to facilitate the CRM community's modelling work, so I do look forward to constructive and pragmatic discussions!
Best,
George
In the 54th CIDOC CRM & 47th FRBR/LRMoo SIG meeting, George Bruseker shared a proposal on redefining constructs of the model. Details can be found in the CRMdig Cleanup document.
Decision: SIG members back the proposal by George. Stephen Stead wants to collaborate (to test with examples from work he’s currently undertaking with a group in San Francisco), Martin Doerr and Thanasis Velios have volunteered to work on the harmonisation of CRMdig and PEM.
Rome, September 2022
Post by George Bruseker (1 November 2022)
Dear all,
I am writing this as a preface to a number of emails that I hope I will be sending through to the list over the next while regarding CRMdig. Following the last SIG meeting in Rome, a decision was made to try to move forward with doing a general review of CRMdig both to check its general consistency with itself and the world and also to bring it into line with CRMbase 7.1.1.
https://cidoc-crm.org/Issue/ID-547-crmdig-update
In that regard, we will be first trying to give it a good trimming taking into account the modelling principles that have been consolidated over the last years and the best practices we have established. This will involve the proposal of deletion of unnecessary classes and properties relative to a domain ontology.
Thereafter for classes and properties that have been identified as problematic but useful/functional, we will create separate issues for each that at the very least identifies THAT they are problematic and hopefully also proposes a useful way to fix them.
We will of course bear in mind the need to make the extension consistent with CRMbase 7.1.1.
At first, the idea would be to bring CRMdig to a stable and consistent state and then to systematically and based on input and feedback from the community, add to its functionality modelling ground up from real world cases / needs.
It is a very handy and necessary extension given the strong emphasis on digital programmes in the CH community so it will be a real contribution we can make to consolidate this work and bring it up to date. As usual for those who are interested and have experience with implementing CRMdig or other standards which they think it should be able to interact with / be consistent with etc. please be in touch.
Best,
George
Post by George Bruseker (1 December 2022)
Dear all,
Please find in the following links some additional homework for the ongoing CRMdig update.
- Discussion Doc: https://docs.google.com/document/d/1mjPo_UVJ7MlHzQuhEU8TCd4GnwbgOkR308o…
- Supporting Diagrams: https://drive.google.com/file/d/10i763cRrosrzcJjmtMG48abI-fj1c4zR/view?…;
What you will find in the links is a list of proposals to modify, move or delete existing classes and properties in order to make CRMdig compatible with CRMbase 7.1.1 and current best modelling practice.
There are three proposals contained in the homework pertaining to:
- D13 Digital Information Carrier
- D9 Data Object
- Annotation Classes [D29 Annotation Object, D30 Annotation Event, D35 Area]
The present state of the classes and properties, the reason they should be modified/moved/deleted given and a proposal for how to do that is put forward. The work is an outcome of conversations with Rob Sanderson, Nicola Carboni (some time ago) and Martin Doerr. The final proposal can be pinned on me, however.
These are prepared for discussion at the upcoming SIG. If for whatever reason you are not able to participate in person or online in this SIG but are interested in the above matters, please do add your comments pro, con, querying here for them to be considered during the meeting and potential voting.
Best,
George
In the 55th joint meeting of the CIDOC CRM and SO/TC46/SC4/WG9; 48th FRBR/LRMoo SIG meeting, GB brought the SIG up to speed with the current state of CRMdig.
Following the decision to deprecate a number of classes and properties violating principles or common practices (documented in issues 618, 619), he and VA loaded the last edited version in OntoME and implemented the decisions (class/property deprecations) and issued a new release (v4.0), that is currently on the site.
The following modeling clusters were identified as clashing with CRMbase 7.1.1 and underwent reviewing by the SIG:
- D13 Digital Information Carrier
- D9 Data Object
- Annotation classes [D29 Annotation Object, D20 Annotation Event, D35 Area]
- Overall scope of the model –old statement, explicit mention to a project that is no longer relevant.
A summary of decisions & assigned HW can be found below:
- Make D13 Digital Information Carrier IsA E22 Human-Made Object
- Deprecate D9, introduce Lxx encodes dimension
HW: GB to provide definition - Make D35 ISA D1, add property (for association with a digital place primitive)
HW: MD to draft the property definition - D29, D30 to be moved to CRMinf instead
- HW: Provide a new scope, name editors (MD, GB)
For the details of the discussions see attached document
Belval, December 2022
Post by George Bruseker (6 September 2025)
Dear all,
Post by Martin Doerr (8 September 2025)
Dear George,
I kindly ask you to read carefully what I am proposing for CRMdig. I argue that I provide new evidence on issue 547.
I had carefully studied the text for issue 547, and propose a viable alternative to your arguments (which we had shared then) already in harmony with CRMsci for D9 and D11. Therefore I propose not to delete concepts we will possibly need to reintroduce, and are not backwards compatible.
Second, I have completed the Area concepts with the missing parts from the applied software. It is a generic concept in line with METS, a very important standard.
Finally, the fact that the Annotation model appears to be competitive with another annotation model does not make it obsolete per se. It makes use of Named Graph logic, which is very elegant and compact. Van der
Soempel personally told me that they made the Annotation Model as it is because Named Graphs were not mature at that time.
Note that I am editor of CRMdig and domain expert. I do not agree with this judgement:
"Annotation is an important area of digital humanities work. This modeling is very early modelling and misses out on many efforts since then. It is not informed by recent work and it is not a profound
ontological contribution anyhow. "
If we drop a requirement for these deletions, we can directly review the harmonization with the other models. I argue that my proposals are already mature enough.
Please let us review this together.
Kind regards,
Martin
Post by George Bruseker (9 September 2025)
Dear Martin,
Our goal was to complete the issues as tasked by decision of the committee and documented in the issue. Furthermore our aim was to come up with a harmonized version that was official so that we can have a smooth development process moving forward. It looks like your D35 changes fit within that hopefully (obviously the group needs to review and understand). I noticed you added new properties, will they have scope notes to consider by the SIG? Whether you agree with the comments on the annotation model it was already decided to take those classes out of CRMdig which this document simply reiterates. So unless you want to create an issue to undo that issue, I guess we will go ahead with that. I would ask you to consider the utility of having a harmonized official version.
Best,
George
Post by Martin Doerr (10 September 2025)
Dear George, All,
My submissions will speed up the harmonized official version of CRMdig.
We have new evidence, since CRMsci and CRMinf are hamonized now and nearly ready,
and we have identified actual users of CRMdig at hand.
Note that the minutes say:
"
- Break the model in small subtasks (review properties, Digital Objects etc)
HW: GB to coordinate the group of people involved in this task, CEO, (MD), and confer with ML and GH. Inform the Sig in the next meeting.
"
The decisions you refer to are 2 years old, things have changed since then:
A summary of decisions & assigned HW can be found below:
- Make D13 Digital Information Carrier IsA E22 Human-Made Object
- Deprecate D9, introduce Lxx encodes dimension
HW: GB to provide definition - Make D35 ISA D1, add property (for association with a digital place primitive)
HW: MD to draft the property definition - D29, D30 to be moved to CRMinf instead
- HW: Provide a new scope, name editors (MD, GB)
Therefore I propose
a):
Undo deprecation of D9, use my first submission (NEW ISSUE: Reviewing CRMdig 4.0 Digitization and D9) instead, because it resolves the ontological mismatch with E54 Dimension and provides harmonization already, and it is backwards compatible with the previous versions in use.
Obviously, it makes no sense to first deleting D9 and in the next reintroducing it. Must be decided before 547 is closed. Isn't it?
b) Deprecate L60 as foreseen, introduce L61 contains value set of (has value set representation) as "Lxx encodes dimension", fully described in my submission.
c) Undo D29, D30 to be moved to CRMinf instead. This is again a non-backwards compatible decision, and does not affect the sense of the concepts, which were not questioned.
Since CRMinf is now nearly finished, it would create an unnecessary interruption of the process f CRMinf, which should have priority.
Further, objections came from promoters of the Open Annotation Model as competitors, which is not based on a Named Graph logic. Competitive Models have never been an argument for deleting existing CR-compatible models, but an argument for investing in a mapping.
With my recent submissions, I broke it 547 into two small subtasks. This is the second:
d) I resolved D35 completely, my submission "NEW ISSUE: Reviewing Area in CRMdig 4.0" is the above homework, part of issue 547. You can change the label as part of Issue 547, not a new issue.
So, I kindly ask why my proposals should not directly be discussed before closing issue 547, since they answer exactly to the problems encountered with the current version and resolve basically the harmonization question already.
You wrote: "I noticed you added new properties, will they have scope notes to consider by the SIG? " Please do read my submissions before insisting on a less effective procedure, and consider that I am equally involved in issue 547 from the outset.
Best,
Martin
Post by George Bruseker (10 September 2025)
Dear Martin, all,
I withdraw my participation from the issue. Please proceed as you see fit.
Best
George
Post by Dominic Oldman (11 September 2025)
Just a general point on this subject.
During the next SIG meeting I would like to bring up some practical issues related to part of our key user base - museums and other heritage organisations.
As more heritage organisations adopt CIDOC CRM (in internal operational systems) we need to be aware of how CIDOC CRM works for them - part of our understanding of CIDOC CRM in practice.
The ontologies that have been in development with a particular eye on ontology harmonisation are very useful for practical implementation. The work on CRMInf and CRMSci, even though there is still some finishing to be done, have already been adopted (replacing previous versions) in an operational system and will be used in others. These will be used 9-5, 5 days a week by whole departments, etc.
In academic projects updates may not take place during the term of the project. Projects last for fixed periods and their objectives for community harmonisation (one of the main reasons for CIDOC CRM's development) have in practice been relatively low.
The CIDOC CRM is a museum standard under the auspices of CIDOC. As we install CIDOC CRM in organisational systems - these systems are expected to last many years and to evolve over time. The ecosystem is completely different to academic research projects.
At the National Archives (UK) we just upgraded their operational system (ResearchSpace) to the latest versions of Inf and Sci. This obviously meant altering patterns in their existing rdf graph. The changes to the ontologies were seen as highly beneficial because they addressed practical harmonisation issues - they had operational benefits amongst other improvements (my thanks to the people involved!). In these systems CRMDig is also used (scientific digital equipment). It is used successfully with no real practical problems. Again, harmonisation would be beneficial and should be the priority.
Using graph systems means that replacing patterns within the graph is less onerous. This is just one of many reasons why we use them - 'dynamic flexibility' in a transdisciplinary environment - and we should all expect the ontologies to change over time as part of a standard's workings. Graph systems are flexible and well suited to adopting these changes meaning that we can update organisations to the latest versions of the CRM ontologies (preventing them from being static and supporting community harmonisation even where those local models of CRM are continually expanding (again a benefit of graphs as evolving and expanding structures). However, they still require resources and time to implement and are not trivial - they require appropriate expertise (as with any system). We need to consider very carefully the changes we make and whether they are really needed partly by looking at their operation in practice which is interconnected to other considerations. This question of practice comes up frequently as a key element of CRM modelling. We would do well to consider practice (without any compromise the principles of the CRM - of course) more carefully. The recent changes to CRMSCi and CRMInf demonstrate a really good approach. CRMDig in practice works, and changes should also focus on harmonisation and errors, in the context of existing practical use and benefits of the current version.
The CRM is mature! - Surely we are in a phase of consolidating it and mostly making smaller but significant improvements, which improve harmonisation both in the ontology and across the museum community. This would, amongst other initiatives, very much help with adoption.
I would like to propose that we look at these issues and, with Pavlos' permission, will write something on this subject.
Thanks,
Dominic
Post by Martin Doerr (30 September 2025)
Dear All,
The attached file is my final proposal to be discussed under issue 547.
As George had insisted, I keep changes to the current version 4.0 minimal in order to quickly have a consistent base for further improvement,
with exception
a) the resolution of the iconsistency of D9 with Dimension by issue 708
b) adding L61 contains value set instead of the proposed Lxx encodes dimension
c) deprecate L60, L17, L54 is same as
d) make D13 Digital Information Carier subclass of E22 Human-Made Object
e) I left out issue 709, only making D35 Area not subclass of E26 Physical Feature
f) A minimal change to the scope note of D30 Annotation Event, because the text was corrupt
g) A minimal change to the scope note of L43 annotates, bcause it referred to a European project feature, the "Research Infrastructure".
At numerous places I left comments that scope notes need revision, without elaborating them.
( I do have made these revisions in a separate file, to be processed in separate issues.)
All the best,
Martin