Home » railML newsgroups » railML.infrastructure » [railML3] New semantic constraint to ensure unambiguous infrastructure states (Eliminating overlap of validities)
[railML3] New semantic constraint to ensure unambiguous infrastructure states [message #3486] Thu, 27 February 2025 16:18 Go to next message
Larissa Zhuchyi is currently offline  Larissa Zhuchyi
Messages: 66
Registered: November 2022
Member
Dear all

During certification we have encountered a case of ambiguous infrastructure states when there are more than one of those defined. See invalid excerpt below. The problem of excerpt is that reader cannot identify what is the state of the <infrastructure> in the file: "operational" or "conceptual" because it applies for the whole infrastructure unlimited time. 

      <infrastructureState id="state1" value="operational">
        <elementState id="xxx" refersToElement="zzz" value="closed" />
      </infrastructureState>
      <infrastructureState id="state2" value="conceptual">
        <elementState id="yyy" refersToElement="jjj" value="disabled" />
      </infrastructureState>

We suggest the following semantic constraint IS:019:

When calculating which <infrastructureState> of an <infrastructure> is valid at a particular time always a maximum of one active <infrastructureState> shall be the result.

See an example below.

      <infrastructureState id="state1" value="operational">
        <validityTime>
          <period from="2002-09-24-06:00" to="2002-09-30-06:00" />
        </validityTime>
        <elementState id="xxx" refersToElement="zzz" value="closed" />
      </infrastructureState>
      <infrastructureState id="state2" value="conceptual">
        <validityTime>
          <period from="2022-09-24-06:00" to="2022-09-30-06:00" />
        </validityTime>
        <elementState id="yyy" refersToElement="jjj" value="disabled" />
      </infrastructureState>

Validities of "state1" and "state2" do not intersect therefore in reader can identify when each of them applies.

This example provides the following information:

- the whole infrastructure except element "xxx" from "2002-09-24-06:00" to "2002-09-30-06:00" was is state "operational".

- element "xxx" from "2002-09-24-06:00" to "2002-09-30-06:00" was is state "closed".

- the whole infrastructure except element "xxx" from "2022-09-24-06:00" to "2022-09-30-06:00" was is state "conceptual".

- element "xxx" from "2022-09-24-06:00" to "2022-09-30-06:00" was is state "disabled".

- the state from "2002-09-30-06:00" to "2022-09-24-06:00" is undefined.

Please let us know if you do not agree with IS:022, IS:023 till 2025-04-30. How could the wording be improved to avoid misunderstandings especially for people new to railML?

Thanks in advance!

Sincerely,

Larissa Zhuchyi – Ontology Researcher
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org

Report message to a moderator

Re: [railML3] New semantic constraint to ensure unambiguous infrastructure states [message #3494 is a reply to message #3486] Mon, 03 March 2025 15:04 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 505
Registered: January 2016
Senior Member
Dear all,

I want to add the remark, that this issue is only relevant up to railML version 3.2. In railML 3.3, the state of the infrastructure is modeled in the common schema with element <state>. However, the semantic constraint remains the same: at a certain point in time, an (infrastructure) element can be only in one and only one state.

Please share your comments and ideas on that topic with us!

Best regards
Christian

Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org

Report message to a moderator

Re: [railML3] New semantic constraint to ensure unambiguous infrastructure states [message #3499 is a reply to message #3494] Wed, 05 March 2025 21:37 Go to previous messageGo to next message
Torben Brand is currently offline  Torben Brand
Messages: 180
Registered: March 2016
Senior Member
Thank you Christian for pointing out that this is only relevant for railML3.2. I suggest to also change the example to railML3.3 as this is the current version.
Also I suggest to improve the wiki page [1] to explain that the <infrastructureState> has been removed but that it has been replaced with <state> [2] under <common> (preferably with link). Also move/copy wiki content to new wiki page state in commmon.

I do not understand the change of state for whole infrastructure (3.2)/document (3.3)? This makes no sense to me? Can you define a purpose/use case for this? I understand railML files to be snapshots at a certain state/date!

At Jernbanedirektoratet we need to have the possibility to have <validity> undefined under <state> or <elementState>. I assume your proposal does not hinder this. Its only to clarify how to use <validity> such that it is consistent in time?

Can I suggest as clearer rule?
Multiple <infrastructureState> (3.2)/<state>(3.3). with defined <validityTime>(3.2)/<validity>(3.3) shall not have overlapping <validityTime>/<validity> in time.
The same applies for <elementState> under the same object.
<elementState> can have overlapping validityTime>(3.2)/<validity>(3.3) with <infrastructureState> (3.2)/<state>(3.3) as it overwrites <infrastructureState> (3.2)/<state>(3.3).


[1] https://wiki3.railml.org/wiki/IS:infrastructureState
[2] https://wiki3.railml.org/wiki/CO:state#3.3-0

Report message to a moderator

Re: [railML3] New semantic constraint to ensure unambiguous infrastructure states [message #3575 is a reply to message #3499] Tue, 22 April 2025 12:53 Go to previous messageGo to next message
Fredrik Jönsson is currently offline  Fredrik Jönsson
Messages: 7
Registered: June 2024
Location: Sweden
Junior Member
We at Trafikverket agree with the proposed semantic constraint.
As for validity type options, the undefined value should be allowed (like Torben mentioened), since there is not always known for all parts of network.

Fredrik Jönsson
Trafikverket - Swedish Transport Administration

Report message to a moderator

Re: [railML3] New semantic constraint to ensure unambiguous infrastructure states [message #3579 is a reply to message #3575] Tue, 22 April 2025 16:05 Go to previous message
Stéphane Kaloustian is currently offline  Stéphane Kaloustian
Messages: 8
Registered: September 2024
Junior Member
Hi Larissa

I think we have to be more precise. I use here the 3.3 schema but I think the rationale should be the same with 3.2.

Do we mean
1) "At any given moment, a maximum of one state shall be active" which is equivalent to "state periods shall not overlap"
or
2) "At any given moment, there shall be one and only one active state" which is stronger, as it means "state periods shall not overlap" and "state periods shall cover the complete timeline".

I think we mean 1) here, though I don't know how, if for example state A goes from 2024 to 2027 and state B from 2029 to 2035, what I should deduce for the status of the installation in 2028.

In addition, as Torben wrote, we need a way to say "until further notice" in a period. Having @to undefined is ambiguous because it may be interpreted as "we don't know" or "forever/until further notice"

Regards
Stéphane Kaloustian
SBB Swiss Railways

Report message to a moderator

Previous Topic: usage of @branchingSpeed and @joiningSpeed
Next Topic: [railML3] Restricting IS:line and RTM:linearPositioningSystem
Goto Forum:
  

[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Sun May 18 21:59:58 CEST 2025