Topology Inconsistency

[Ajala111]

1. To say that era:LinearElement is a subClassOf era:NetElement, and that era:NetElement can itself be a part of another era:NetElement poses a potential ambiguity. This setup creates a loop that may lead to misinterpretation and misuse. I propose adopting a more precise approach to defining the topology, as depicted in the attached image (in blue).

2. The reason for era:NonlinearElement is unclear. It is unclear whether it refers to a specific 'point' on a NetElement (because it hasPosition which is SpotLocation) or a group of parallel LinearElements. In either case, the necessity of era:NonlinearElement is questionable, as all era:InfrastructureObjects abstract era:TopologicalObjects (era:NetElement) where all LinearElements that define them can be accessed. I will propose that it should be removed (see red mark in the attached image); Then, spotLocation should also have era:carrierObject (see green line)

[gatemezing]

Dear @Ajala111 , thank you for your feedback.

1. The current modeling considers that there are two disjoint classes era:LinearElement and era:NonLinearElement as subclassOf era:NetElement. For example, a Switch can be considered as era:NonLinearElement. The idea is to be able to deal with navigability and navigability conditions when you have switch in the network. The class era:Position can have more properties, not only related to geographical aspect, but also relative position, useful in a schematic view. In general, the ability of subClassing is a way to be able to add more specific properties, not only for the container-view from the OOM.

Consider the following example in Turtle with one switch and three tracks, with navigability conditions. Could you elaborate a use case of your proposal by adding the corresponding triples if needed to this sample? If you already have some sample data for your use case, it will also help.

@prefix era: <http://data.europa.eu/949/>.
@prefix rera: <http://data.europa.eu/949/id/>.
@prefix era-nav: <http://data.europa.eu/949/concepts/navigability-conditions/>.
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix time: <http://www.w3.org/2006/time#> .

# definition of 3 tracks and one switch
rera:t1 a era:LinearElement.        #Track         
rera:t2 a era:LinearElement.        #Track
rera:t3 a era:LinearElement.        #Track
rera:s1 a era:NonlinearElement.     #Switch

#navigability 

rera:s1 era:navigability 
    [ era:from era:t1; era:to era:t2 ],  #basic anonymous instance of navigability
    [ era:from era:t2; era:to era:t1 ],  #along with the first instance it defines the bi-directionality traffic
    [ era:from era:t3; era:to rera:t1 ],

    era:exceptionalNavigability.        

    # navigability tuple with validity and some specific conditions

# case of navigability conditions

rera:exceptionalNavigability a era:Navigability;
    era:from era:t1; 
    era:to era:t3;
    #limited validity
    era:validity 
            [ a era:TemporalFeature ;
              time:hasBeginning [ a time:Instant; 
                            time:inXSDDateTime "2025-01-01T00:00:00+1:00"^^xsd:dateTimeStamp ];
              time:hasEnd [
                a time:Instant;
                  time:inXSDDateTime  "2025-12-31T23:59:00+1:00"^^xsd:dateTimeStamp ];
             ];
    #information about conditions
    era:condition [
        a era:NavigabilityCondition;
        era:ofType era-nav:track-obstructions
    ]. 

[Ajala111]

Thanks for the response.

In the text, you mentioned that a switch can be considered a LinearElement, but in the TTL sample, you define it as a NonLinearElement. Is this a typo? . . . I believe you meant it's a NonLinearElement.

I understand that the class era:Position does not only relates to geographical aspects but also to relative position. Meanwhile, this also applies to LinearLocation and AreaLocation. So, what distinguishes SpotLocation from these?

The issue is that one can also defines a era:Switch as a BasicObject (as seen below).

era:s1 a era:BasicObject;             #Switch
        era:hasAbstraction [
        a era:NetElement;
        era:Location [
            a era:SpotLocation;
            era:carrierObject era:t1;
            era:carrierObject era:t2;
            era:carrierObject era:t3;
        ];
        ].

rera:s1 era:navigability      # <-- one only need to add navigability 'object' property to the Switch
    [ era:from era:t1; era:to era:t2 ],    #basic anonymous instance of navigability
    [ era:from era:t2; era:to era:t1 ],    #along with the first instance it defines the bi-directionality traffic
    [ era:from era:t3; era:to rera:t1 ],
    era:exceptionalNavigability.

In the end, a consistent approach is advisable.

[Airy59]

I recommend NOT to consider switches (and crossings, by the way) as nonlinear elements at all:

1. switches are already identified as infrastructure objects that are placed on the topology.
2. if switches are also considered topology elements, which technically is possible, these would create duplicate (twin) individuals
3. navigabilities would have to be expressed between non-adjacent linear elements, so chained navigabilities will not yield the actual vehicle path

Duplicating information and reducing the usability of navigabilities do not seem appealing.

[gatemezing]

Thanks for the response.

In the text, you mentioned that a switch can be considered a LinearElement, but in the TTL sample, you define it as a NonLinearElement. Is this a typo? . . . I believe you meant it's a NonLinearElement.

Yes, a typo. I correct it, thanks. I understand that the class era:Position does not only relates to geographical aspects but also to relative position. Meanwhile, this also applies to LinearLocation and AreaLocation. So, what distinguishes SpotLocation from these?

This has to be defined with the set of attributes. Hopefully tomorrow during the TWG on micro.

The issue is that one can also defines a era:Switch as a BasicObject (as seen below).

SHACL (constraints) are not yet defined to be able to restrict the constructions + all the necessary axioms (to be checked)

era:s1 a era:BasicObject;             #Switch
        era:hasAbstraction [
      a era:NetElement;
      era:Location [
          a era:SpotLocation;
          era:carrierObject era:t1;
          era:carrierObject era:t2;
          era:carrierObject era:t3;
      ];
        ].

rera:s1 era:navigability      # <-- one only need to add navigability 'object' property to the Switch
    [ era:from era:t1; era:to era:t2 ],    #basic anonymous instance of navigability
    [ era:from era:t2; era:to era:t1 ],    #along with the first instance it defines the bi-directionality traffic
    [ era:from era:t3; era:to rera:t1 ],
    era:exceptionalNavigability.

In the end, a consistent approach is advisable.

Yes, consistent here means how we "close the world" in the ontology + the SHACL rules to avoid misuse of the model when collecting the data. Let's first agree on the main concepts and how they are related.

[sixdiamants]

Airy is right in separating topology from hardware such as a point.

To return to Felix' original query, a use case for nonlinear topological elements is a termination of track or a cut. See this diagram

As for Felix' first remark, I would instead suggest reproducing the original RSM approach which would require some intermediate concepts.

As for misinterpretation and misuse of the model, that is a price for flexibility and has to be excluded by Application Profiles including Shacl shapes. E.g. "though shallt not state era:signal era:hasAbstraction/era:location [a era:LinearLocation] ."

This said, my guess is that this issue is now overtaken by #11

[gatemezing]

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