Navigability condition is unclear

[Airy59]

"Navigability condition" raises some questions:

• why is it declared "disjoint with" Navigability? both classes have no superclasses, are involved by different properties, etc.
• what would individuals look like, and what meaning do they carry?

[Airy59]

for reference: the recent recast of RSM in semantic form led me to define navigabilities as RDF properties, thus getting rid of reification, but keeping directionality and ensuring that they are transitive: a big bonus for path search under constraints.

On the other hand, I reified the extremities of linear elements and generalized the notion of extremity to ports of nonlinear elements, thus making the MESO level possible with the same formalism, and also safeguarding transitivity of navigabilities at meso level (INFRABEL previously managed to implement that in a formally different, but essentially similar way). Even if MESO is not on the agenda of RINF, I'd recommend that we discuss the pros and cons of your envisaged solution (close to RSM1.2) and the SemanticRSM alternative (more elegant and more expressive)... or possibly figure out an even better one!

[Interoperable-data]

"Navigability condition" raises some questions:

• why is it declared "disjoint with" Navigability? both classes have no superclasses, are involved by different properties, etc.
• what would individuals look like, and what meaning do they carry?
• we couldn't find any example of an instance of era:Navigability to be at the same time an era:NavigabilityCondition, while the era:condition would become a reflexive property.

• 
  @prefix era: <http://data.europa.eu/949/>.
  @prefix era-nav: <http://data.europa.eu/949/concepts/navigability-conditions/>.

era:t1 a era:LinearElement. #Track
era:t2 a era:LinearElement. #Track era:t3 a era:LinearElement. #Track era:s1 a era:NonlinearElement. #Switch

era: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 era:t1 ], era:exceptionalNavigability. # navigability tuple with validity and some specific conditions

era:exceptionalNavigability a era:Navigability; era:from era:t1; era:to era:t3;

limited validity

era:validity 
        [ a era:TemporalFeature;
          time:hasBeginning/time:inXSDDateTime "01-01-2025"; 
          time:hasEnd/time:inXSDDateTime  "31-12-2025"; ];
#information about conditions
era:condition [
    a era:NavigabilityCondition;
    era:ofType era-nav:track-obstructions;
]. 

The concept of navigability condition is not defined, because it was not discussed in the RINF TWG for micro-level, but it was introduced to provide extra information in case of introducing new navigability paths, under certain conditions which can be, for example:
* scheduled (or un-scheduled) track maintenance, repairs
* weather conditions
* emergency situations
* signal failures
* TBD

[Airy59]

I never mentioned reflexive properties; you probably meant transitive.

Of course, if you "insert" a switch as a non-linear element in the topology to bear the navigabilities, it is possible to compute the possible paths, which requires previous identification of "switches" that are "attached" to linear elements.

Suggestion: try and set up and example of path search down a mock network.