explicitly document cross-references btw family models

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. 

CRMact: TV 
CRMarchaeo: CEO, GH, AF, MK
CRMba: ?
CRMdig: GB, RS, MD
CRMgeo: GH
CRMinf: PF, MD, SdS
CRMsci: TV, AK, MD
CRMsoc: GB
CRMtex: PF, AF, FM, MD
FRBR/LRMoo: PR
PRESSoo: ?
 

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.

Decisions:

• 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.

HW:

• 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

Post by Elias Tzortzakakis (8 March 2024)

Dear all,

In order to avoid a lengthy complex e-mail with the updates and my remarks on each FM, I created a temporary html page which I hope keeps things tidy.

More details on this issue will be presented in the upcoming 58^th SIG meeting on Thursday 21 March 2024 Session 3.1.

I think it would be worth having a look at the following page before the meeting, especially the model maintainers of each FM.

 https://www.cidoc-crm.org/extensions/

 This page includes a table with one row per each FM.

• First column points to a link (usually the namespace link of each FM) which resolves in an HTML representation of the classes and properties declaration of the model
• Dependencies column lists the external models that have been used for the documentation parsing of each FM. For draft or older versions I tried to use the most recent dependencies.
• Repository links column includes notable links to the most recent development repository including:
  
  • Direct link to the latest repository development branch (master branch is empty)
  • Link to documentation issues detected during parsing of the model documentation for review
  • Detailed external references list
  • RDFs generation policies
• Encodings Status column defines a status that indicates whether the files included in the repository are ready for review and approval
• Current maintainers column is just filled with the contacts assigned to each FM

I will probably soon include the above description inside the page.

[HERE the Working Document for the 58th SIG meeting]

Cheers,

Elias

In the 58th CIDOC CRM & 51st FRBR/LRMoo SIG Meeting, ETz gave an outline of the current state of the issue and the repositories he has set up to monitor dependencies btw CRMbase and CRM-compatible extensions. Link to the slide deck here. 

Discussion points: 

• Concerning CRMarchaeo:
  • based on the decisions for CRM OWL & RDFS, assuming we add the examples in comments there too, then we will have to generate another RDFS file for CRMarchaeo (the examples have been completely redone for v2.1, to match the template for examples). But it’s not particularly pressing to implement this.
  • 3 properties lacking an inverse name: AP29 appears in, AP30 restricted to, AP31 is typical for that associate a type of thing with the instance(s) of E4 Period it is characteristic of. This is intentional, there is no reason to declare the inverse property for that.
• Concerning CRMtex: it uses classes from CRMinf 0.7 and FRBRoo 2.4 (so not compatible with 7.1.2). For F28 Expression Creation, this is not a problem for CRMtex, as it has carried over to LRMoo, which has resulted in a stable release. But the SIG needs to prioritize CRMinf and produce a stable form by the next meeting (or at the next meeting, at the latest).
• For referenced classes/properties of CRMbase and other extensions in the html representation: They should always point back to the version they reference. Not the official one, not the most current one.
• For draft versions of family models: Provide resolvable URIs, but indicate that the model is draft, so it should be used for consultation, not implementation purposes.  Add this to the “Encodings” column as well
• Encodings column “Useful Links”: rather than calling the link to gitlab “more”, just call it “gitlab”

The SIG accepted the proposals by ETz. He will be implementing them and then the issue will close. 
 

Paris, March 2024