Skip to main content

User account menu

  • Log in
Home
CIDOC CRM

Cidoc Horizontal Menu

  • Home
    • About & Info
    • Last official release
    • Versions
    • Compatible Models
    • Translations
    • Issues
    • SIG's activities overview
    • SIG meetings
    • Minutes
    • Workshops
    • Working Groups
    • Versions
    • Figures & Diagrams
    • Data examples
    • Templates
    • Publications & Documents
    • External Tools
    • Short Intro & Methodology
    • Mappings
    • Functional Overview
    • Tutorials
    • Use Cases
    • Best Practices
    • Recommendation for Museums
    • Short Intro
    • Bylaws
    • SIG Members
    • Become a SIG member
    • Host Organizations
    • Stakeholders
    • Activity Documentation
    • Mailing list
  • News
  • Contact

Choose a shortcut

Last official release
Compatible/harmonized models
Issues
Link to old CIDOC CRM website
Next meetings
CIDOC CRM Tutorial
Use cases
CIDOC CRM Website designs and logos 
Become a SIG member
Editorial Suggestions
Site Support
CRM SIG mailing list

 

inline_menu_issues

  • List of Issues
  • Issue formulation
  • CRM SIG Archive

amend the E13 / P140 / P141 / P177 scope notes

718
2026-02-26
1 - Editorial changes
Open

Post by Wolfgang Schmidle (26 February 2026)

Dear All,

Property types like "P46i forms part of" are not allowed in an Attribute Assignment. Instead, it should be "P46 is composed of (forms part of)". Since this isn't common knowledge, the E13 / P140 / P141 / P177 scope notes should be amended to mention it.

Best,
Wolfgang

Post by George Bruseker (26 February 2026)

Dear Wolfgang,

Why is this? I have not heard of it before. Is it written?

Best,

George
 

Post by Martin Doerr (26 February 2026)

 

Dear All,

May I correct Wolfgang's proposal.

The issue is about formal encoding. RDFS distinguishes forward and backward directions as distinct properties.
This had been amended in OWL with the construct inverse of. CIDOC CRM regards the backward direction as a question of label reading and not a ditinct identity. Therefore, P46i forms part of is NOT a different property type from P46 is composed of. If "P46i forms part of" would appear in a KB input in an E13 pattern, P140 and P141 should be turned around and P177 adjusted to P46 via input S/W.

We had discussed this as a question of formal logic and identity of properties.

Bet,

Martin

Post by George Bruseker (26 February 20206)

Dear Martin,

I think this is not a very reasonable ask. It kind of delegitimizes half of the properties that are out there and used in practice all the time.  There could very well be reasons to begin from one subject and land to the other such that you have to document that the inverse property was asserted of something. This cannot be predicted from the ontology perspective, it is the question of documenting the case (how the world is). It seems like this should be left as a question to the implementer. The example seems legitimate in either direction to me.

Cheers,
George

Post by Robert Sanderson (26 February 2026)

Yes, this would cause a fundamental break with how we manage relationships in Linked Art. There are fixed places at which Attribute Assignment can be used, thereby fixing which entity is the subject and which is the object, thereby sometimes requiring one direction, sometimes the other.

Also, you are misreading the OWL constructions. P46 and P46i are separate Object Properties with their own URIs. Otherwise there wouldn't be a subject/object distinction for the triple with the owl:inverseOf predicate.

Rob
 

Post by Martin Doerr (26 February 2026)

Dear Robert,

Please no panic!!

Please do not confuse implementations with the logical ontology. RDFS and OWL are implementations. This proposal does not invalidate anything you are doing. I am not misreading OWL instructions, I do have enough background in KR. Further, Linked Art is based on a Relational Model, as far as I know, therefore direction may be essential for you. It is also essential in an XML implementation. Only if you export into OWL and query in OWL for the existence of such a property, the query MUST return you both directions, and infer that the inverse is implicitly assigned by the same Activity. This is defined in the formalization of the CRM. If you implement the assigned property with a E-R relationship, it is bidirectional any way.

A different question is how to formulate this in the scope note not to confuse people that do not have so much KR background.

All the best,

Martin

Post by Robert Sanderson (26 February 2026)

Yes, this would cause a fundamental break with how we manage relationships in Linked Art. There are fixed places at which Attribute Assignment can be used, thereby fixing which entity is the subject and which is the object, thereby sometimes requiring one direction, sometimes the other.

Also, you are misreading the OWL constructions. P46 and P46i are separate Object Properties with their own URIs. Otherwise there wouldn't be a subject/object distinction for the triple with the owl:inverseOf predicate.

Rob

Post by Martin Doerr (26 February 2026)

Dear George,

Yes, of course, I regard it as well as an implementation question. Wolfgang has stumbled over the interpretation of being two different properities, because of the identity question of beliefs in CRMinf, i.e. is a belief in "P46i forms part of" different from a belief in "P46 is composed of" with domain and range interchanged? - obviously not...or?

The problem is that many people now identify formal ontologies with the OWL formalism, even though we have a quite elaborate text on the Site about implementing CRM in RDFS and the differences, where the identity of inverse properties is discussed.

Therefore, I think it could be just a phrase in the scope note, such as "note that assigning an property type implies the inverse reading direction and vice versa, such as ""P46i forms part of" implies "P46 is composed of" exchanging domain and range" ?

Cheers,

Martin

On 2/26/2026 12:21 PM, George Bruseker wrote:
Dear Martin,

I think this is not a very reasonable ask. It kind of delegitimizes half of the properties that are out there and used in practice all the time.  There could very well be reasons to begin from one subject and land to the other such that you have to document that the inverse property was asserted of something. This cannot be predicted from the ontology perspective, it is the question of documenting the case (how the world is). It seems like this should be left as a question to the implementer. The example seems legitimate in either direction to me.

Cheers,
George
 

Post by Robert Sanderson (26 February 2026)

Therefore, I think it could be just a phrase in the scope note, such as "note that assigning an property type implies the inverse reading direction and vice versa, such as ""P46i forms part of" implies "P46 is composed of" exchanging domain and range" ?

This I agree with.  

However this formulation:
> If "P46i forms part of" would appear in a KB input in an E13 pattern, P140 and P141 should be turned around and P177 adjusted to P46 via input S/W.

Is where the panic came from :)

R

Post by Martin Doerr (26 February 2026)

Dear George,

Yes, of course, I regard it as well as an implementation question. Wolfgang has stumbled over the interpretation of being two different properities, because of the identity question of beliefs in CRMinf, i.e. is a belief in "P46i forms part of" different from a belief in "P46 is composed of" with domain and range interchanged? - obviously not...or?

The problem is that many people now identify formal ontologies with the OWL formalism, even though we have a quite elaborate text on the Site about implementing CRM in RDFS and the differences, where the identity of inverse properties is discussed.

Therefore, I think it could be just a phrase in the scope note, such as "note that assigning an property type implies the inverse reading direction and vice versa, such as ""P46i forms part of" implies "P46 is composed of" exchanging domain and range" ?

Cheers,

Martin

 

Post by George Bruseker (26 February 20206)

Dear Martin,

I think this is not a very reasonable ask. It kind of delegitimizes half of the properties that are out there and used in practice all the time.  There could very well be reasons to begin from one subject and land to the other such that you have to document that the inverse property was asserted of something. This cannot be predicted from the ontology perspective, it is the question of documenting the case (how the world is). It seems like this should be left as a question to the implementer. The example seems legitimate in either direction to me.

Cheers,
George

Post by Robert Sanderson (26 February 2026)

 

Therefore, I think it could be just a phrase in the scope note, such as "note that assigning an property type implies the inverse reading direction and vice versa, such as ""P46i forms part of" implies "P46 is composed of" exchanging domain and range" ? 

This I agree with.  

However this formulation:

If "P46i forms part of" would appear in a KB input in an E13 pattern, P140 and P141 should be turned around and P177 adjusted to P46 via input S/W.

Is where the panic came from :)

R

Post by Thanasis Velios (28 February 2026)

Dear all,

To avoid the complexity of querying for both directions in RDFS, during
the Linked Conservation Data project, all inverse properties were
automatically turned around. But I can see why this may be problematic
in some implementations.

All the best,

Thanasis

Post by George Bruseker (2 March 2026)

Dear all,

So it sounds like the practical consensus would be on either using the example as originally proposed and putting the note or perhaps even doing it the reverse direction (in the example) but again putting the same note. Like if it says p46i in the example we can put a note, and this implies also p46 reading the other way or if it says P46 in the example then we can put the inverse comment. Would that be a satisfactory solution to all?

Best,

George

Post by Christian-Emil Ore (2 March 2026)

Dear all,
Isn't this an issue for most properties - in principle - and should be dealt with in the introduction? On the other hand, who reads an introducion?
Best
Christian-Emil

Post by Martin Doerr (2 March 2026)

Dear All,

I agree and I'll try to formulate a repective not in the next days.

Best,

Martin

Post by Wolfgang Schmidle (4 March 2026)

I think there is some mix-up here between the issue at hand (issue 718) and issue 720 (the Lewis Chessmen).

My starting point was a discussion with Martin about the identity of Proposition Set and One-Proposition Set. As a byproduct of this (ongoing) discussion I learned that {y P46i x} is regarded the same as {x P46 y}. The CRMbase introduction says:

> In contrast to some knowledge representation languages, such as RDF and OWL, we regard that the inverse of a property is not a property in its own right that needs an explicit declaration of being inverse of another, but an interpretation implicitly existing for any property.

To illustrate this more clearly, I came up with the Lewis Chessmen example (issue 720). It is fine to use the inverse label in an example (The “Antique Walrus Tusk Warrior Chessman” forms part of the Lewis Chessmen). This is standard practice, see e.g. the examples for P11 had participant (participated in): Napoleon participated in The Battle of Waterloo, and The Beatles participated in Harry Benson photographing the Beatles in Paris. But P140 and P141 nevertheless encode the domain and range of the property, which in the case of "P46 is composed of (forms part of)" is the direction from whole to part (The Lewis Chessmen is composed of the “Antique Walrus Tusk Warrior Chessman”), and not what one could call the "intuitive direction", which in the case of the Lewis Chessmen would be from part to whole. After some comments on the list I added some more explanation, and in my view the example is fine now. Feel free to disagree, of course.

However, this is issue 718, which unfortunately has a label very similar to issue 720. From early reactions to the Lewis Chessmen example I had the impression that the passage in the introduction quoted above plus the new examples are still not enough. It should also be explicitly stated in the scope notes. So this issue is about amending the scope notes of E13 / P140 / P141 / P177.

Best,
Wolfgang
 

THE MODEL

  • About & Info
  • Short Intro
  • Scope
  • Recommendations
  • References
  • Critics
  • Important Theories
  • Use&Learn
  • Short Intro
  • User Guidance
  • Methodology
  • Tutorials
  • Functional Overview
  • Last Official Release
  • Concept Search
  • Website designs & logos
  • Issues
  • Short Intro
  • Issue Formulation
  • Issue Processing
  • CRM SIG Archive
  • Mappings
  • Short Intro
  • Mapping Methods
  • Mapping Tools
  • Mapping Memory
  • Reports about Mappings
  • Compatible Models
  • Short Intro
  • Models
  • Use Cases
  • Short Intro
  • Use Cases

RESOURCES

  • Related Activities
  • Versions
  • References
  • Presentations
  • Technical Papers
  • Tutorials
  • Critics
  • Important Theories
  • Publications
  • Mappings
  • Compatible Models
  • Translations
  • Best Practices
  • Meeting Contributions
  • Minutes
  • Issues
  • CRM SIG Archive
  • Meeting Contributions
  • Link to old CIDOC CRM website

ACTIVITIES

  • Short Intro
  • SIG Meetings
  • Minutes
  • Workshops
  • Related Activities

PEOPLE

  • Short Intro
  • Related Stakeholders
  • SIG Members
  • Hosts

NEWS

HOME

 

 

Copyright © 2026 Company Name - All rights reserved

Developed & Designed by Alaa Haddad