Forum: railML.infrastructure » [railML3] New semantic constraint to ensure unambiguous infrastructure states

Home » railML newsgroups » railML.infrastructure » [railML3] New semantic constraint to ensure unambiguous infrastructure states (Eliminating overlap of validities)

Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend

[railML3] New semantic constraint to ensure unambiguous infrastructure states [message #3486]

Thu, 27 February 2025 16:18

Larissa Zhuchyi
Messages: 80
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

christian.rahmig
Messages: 529
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

Torben Brand
Messages: 205
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

Fredrik Jönsson
Messages: 11
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

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

Re: [railML3] New semantic constraint to ensure unambiguous infrastructure states [message #3655 is a reply to message #3499]

Thu, 19 June 2025 11:52

Larissa Zhuchyi
Messages: 80
Registered: November 2022

Member

Dear Torben

Quote:

I assume your proposal does not hinder this. Its only to clarify how to use <validity> such that it is consistent in time?

Dear Torben

The unrestricted <validity> is a valid way to define a validity in railML3 file. Please refer to "Case 1" of "Valid code" at https://wiki3.railml.org/wiki/IS:infrastructureState

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

Previous Topic:	How to interpret application direction for derailers
Next Topic:	associated netElements coordinates for LPS and measure precision issues

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

] [

]

Current Time: Sat Jan 17 05:11:59 CET 2026