dsp-api

dsp-api copied to clipboard

The CIDOC Conceptual Reference Model (CRM) "provides definitions and a formal structure for describing the implicit and explicit concepts and relationships used in cultural heritage documentation".

CIDOC has transitive properties. I'm trying to think of how we can deal with this, given the Knora FAQ about transitive properties.

Looking at the Erlangen CRM, which is an OWL encoding of the CIDOC CRM, they use owl:TransitiveProperty.

I think we could use this encoding and handle the transitive properties like this:

A project could make their own subproperties of the CIDOC transitive properties, to use in their resource classes. These subproperties would not have rdf:type owl:TransitiveProperty, so they would not be transitive. But they would cause the CIDOC transitive base properties to be inferred, and these inferred properties could be found using Gravsearch.

For example, consider ecrm:P5i_forms_part_of, which is transitive. You could make:

example:isPartOf rdf:type owl:ObjectProperty ;
    rdf:subPropertyOf ecrm:P5i_forms_part_of ,
        knora-base:hasLinkTo .

Then example:isPartOf would not be transitive. But if you used it to link resources example:A example:isPartOf example:B and example:B example:isPartOf example:C, then you would get the inferred link example:A ecrm:P5i_forms_part_of example:C, which could be found using Gravsearch (but this might need some work on the Gravsearch implementation).

Perhaps we could even find a way to show these inferred links in query results, separately from the other contents of the resource.

Interesting quotes from the spec:

Implementations may lead to solutions where elements and links between relevant elements of our conceptualizations are no longer explicit in a database or other structured storage system. For instance the birth event that connects elements such as father, mother, birth date, birth place may not appear in the database, in order to save storage space or response time of the system.

If necessary, to save storage space or response time in a particular project, I could imagine something like a project-specific route that would transform a simplified internal representation into a more complex, CIDOC CRM-compliant external representation. But I think it would be hard to offer any generic support for this. And what makes sense for one project might not make sense for another.

Users intending to take advantage of the semantic interoperability offered by the CRM may want to make parts of their data structures compatible with the CRM.... The CRM does not require complete matching of all user documentation structures with the CRM, nor that systems should always implement all CRM concepts and associations; instead it leaves room both for extensions, needed to capture the full richness of cultural information, and for simplifications, required for reasons of economy.

This is good: you just use what you need, and extend it as necessary.

Mediation systems, [Gio Wiederholt] which send out queries, formulated according to a virtual global schema, to multiple local systems and then collect and integrate the answers.

I wonder if any mediation systems like this are actually being used in the area of cultural heritage.

A CRM-compatible form should not implement the quantifiers of CRM properties as cardinality constraints for the encoded instances. Quantifiers may be implemented in an informative way, or not at all. Statements that violate quantifiers should be treated as alternative knowledge.

This open-world assumption is different from Knora's closed-world concept of a repository. To make the CRM compatible with Knora, we would have to replace all its cardinalities with owl:minCardinality 0. Anyway, it supports many more quantifiers than Knora does.

There are also different versions of the CIDOC CRM to be aware of. There's an "official" version corresponding to ISO 21127:2014, as well as more recent versions under development. The Erlangen CRM uses versioned namespaces to distinguish between the different versions.