Mereology

[Airy59]

About properties hasPart / isPartOf, belongsTo, and similar:

There are several problems that are bundled here, but may require differentiated treatment (and subsequent issues).

• Sub-issue 1: such part/whole relationships might be expressed as sub-properties of more generic ones, stemming from an "upper" ontology of choice. Some stakeholders are already considering adopting this or that general or upper ontology for their purposes. Is this a subject for the Agency?
• Sub-issue 2: era:belongsTo appears in two different contexts: between Signal and SignalGrid, and between NetworkResource and Network. The resulting definition of that property is: domain = Signal or NetworkResource, range = SignalsGrid or Network. Consequently, the semantics would allow a Signal to belong to a network (which makes sense), or a network resource to belong to a SignalsGrid (which possibly is "nonsense", e.g. if the resource is anything else than a signal).

Concerning sub-issue 1, for information: note: from the ERJU MOTIONAL CDM perspective, we are also looking into that issue. Previous works (see e.g. LinX4Rail D2.1) were unconclusive. While there seem to be no compelling arguments to adopt or reject upper ontologies, the issue should not be dismissed a priori. It may be low priority, as the linking with upper ontologies may be done a posteriori.

Concerning sub-issue 2, of course the "nonsense" could be tackled by introducing some SHACL shapes, but SHACL shapes should express constraints, not correct wrong semantics. Another point to consider is transitivity.

[Interoperable-data]

Hello @Airy59 , Thank you for your comments. Regarding the options:

• Sub-issue 1: We wanted to use dcterms:hasPart/partOf as the "upper ontology". However, we had some strange behavior our the reasoner (pellet incremental classifying some stuff as individuals). That's why we decided to create our own in the era namespace.
• You are right on the second point. What about renaming in two different properties to avoid the "mereology biais"...

1. • era:onSignalGrid (era:Signal, era:SignalsGrid)
2. • era:network(era:Resource, era:Network)

Would that solve the issue here?

[Airy59]

Sub issue 1: Note taken. That does not close the general question of upper ontologies, but I understand you are not passionate about it, so let us maybe postpone this to after Q2 2024. You mentioned strange behaviour of some reasoner, which is an invitation to be cautious.

Sub issue 2: that solves the issue.

I'd like however to suggest era:ofNetwork (with rdfs:label "ofNetwork") because:

• I do not like homonyms, with property era:network and class era:Network only differing by the initial cap;
• :gimmick a era:NetworkResource ; era:ofNetwork . is read more easily. a matter of taste.

[gatemezing]

New updates of the model diagram here https://linkedvocabs.org/data/era-ontology/3.1.0/doc/resources/era-ontology-3.1.0.jpg. You can also see the Turtle file in the repository.