Issue 627: explicitly document cross-references btw family models
In the 55th joint meeting of the CIDOC CRM and SO/TC46/SC4/WG9; 48th FRBR/LRMoo SIG meeting, the SIG resolved to start an issue where to document dependencies among CRMextensions themselves: (CRMarchaeo, CRMsci), (CRMinf, CRMsci), (CRMtex,CRMinf), (CRMba, CRMarchaeo), (CRMba, CRMsci) that are not declared in the version information (or in the specification documents). This information should be easily accessible. However, this information is not always known. To avoid using together incompatible versions of said models, editors of a CRM extension should add explicit cross-references to other models.
Decision: ETs to contact CRM-family model maintainers and collect explicit cross-references to other models, where they are missing. This is to be reported through a new issue (current).
Proposal: add a column in CRMfamily models versions labelled “Other dependencies”, where to list all necessary relevant information. FORTH to implement this and the SIG will give an opinion.
Belval, December 2022
In the 56th joint meeting of the CIDOC CRM and ISO/TC46/SC4/WG9 &49th FRBR/LRMoo SIG, the SIG resolved that model maintainers declare dependencies across versions of the extension that they manage and the versions of other family models that said extensions make use of.
Nb. they should make sure to only reference stable versions of other CRMfamily models when they declare dependencies between them.
CRMarchaeo: CEO, GH, AF, MK
CRMdig: GB, RS, MD
CRMinf: PF, MD, SdS
CRMsci: TV, AK, MD
CRMtex: PF, AF, FM, MD
Discusison about creating separate repositories per model extension
ETz suggested that the SIG create separate repositories per model extension, to document every decision relating to parsing the documents and deriving the rdfs. This way ad hoc decisions can be avoided in favor of best practices.
CRMsci, CRMinf, and CRMtex are very good candidates to be moved to separate repositories.
Topics that need to be addressed:
- Different consistency checks for CRMbase vs extensions: For CRMbase, each class is declared a subclass of E1 CRM Entity. This is not necessarily the case for extensions.
- No explicit mention of the existence of classes that have an equivalent scope to E59 Primitive Value in CRM extensions. ETz should know that to correctly parse family models.
The repository for CRMbase is in gitlab and a link points to it from the “more” button on the resources table of stable versions. Maybe it should be made more prominent on the site.
Crete, May 2023
In the 57th CIDOC CRM & 50th FRBR/LRMoo SIG Meeting, ETz walked the SIG through the HW he has undertaken (create separate gitlab repositories for CRMsci, CRMtex, FRBR/LRMoo; document RDF implementation decisions; document external references). He identified some problems while parsing the models, he will be directly consulting with the maintainers of each model.
- Always start by parsing stable versions of models.
- When the model in question has not had a stable release in a while, ask its maintainers for directions.
- ETz to generate a PC module similarly to the CRMbase repository. In CRMarchaeo, f.i., a .2 property needs to be implemented; AP13.2 justified takes AP13 has stratigraphic relation to as its domain, and AP11 has physical relation to as its range.
- ETz to generate a Supplement module similarly to the CRMbase repository. In CRMsci, f.i., O30 determined position (D: S23 Position Determination, R: E94 Space Primitive) is declared a subproperty of O16 observed value (D:S4 Observation, R: E1 CRM Entity).
Marseille, October 2023