Home » railML newsgroups » railml.timetable » [railML 3] New semantic constraint for trainVariant
[railML 3] New semantic constraint for trainVariant [message #3057] Mon, 13 March 2023 17:22 Go to next message
Milan Wölke is currently offline  Milan Wölke
Messages: 139
Registered: April 2007
Senior Member
Hi all,

in the last few timetable developer group meetings we have been discussing another semantic constraint in order to help understanding the new timetable model and in order to improve data exchange. This time it is focused on the operationalTrainVariant as well as the commercialTrainVariant. We propose for both of these to define the following semantic constraint:

Quote:

When calculating which <commercialTrainVariant> of a <commercialTrain> is valid on a particular day always a maximum of one active <commercialTrainVariant> shall be the result. If the result is more than one <commercialTrainVariant>, all except one shall be marked as <isCancelled> or <isOnRequest>.
The above wording exists in the same way for the operationalTrainVariant.
From our point of view this should help make it clear how to export and how import a railML 3 timetable. What do you think? Do you have use cases in mind where this semantic constraint would be a burden?

Best regards, Milan


Milan Wölke – Timetable scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: [railML 3] New semantic constraint for trainVariant [message #3061 is a reply to message #3057] Wed, 15 March 2023 13:39 Go to previous messageGo to next message
David Lichti is currently offline  David Lichti
Messages: 13
Registered: December 2020
Junior Member
This may be a more general topic: But how is the interaction of semantic constraints with custom extensions?

For example, if there was an extension adding a flag for propsed trains, f.ex. <ext:isProposed>. That train would be neither cancelled (because it hasn't been published), nor on-request (because it hasn't been agreed). In such a case it would be reasonable to have more than one proposed variant for one day.
Re: [railML 3] New semantic constraint for trainVariant [message #3069 is a reply to message #3061] Wed, 05 April 2023 12:25 Go to previous messageGo to next message
Milan Wölke is currently offline  Milan Wölke
Messages: 139
Registered: April 2007
Senior Member
Hi David,

this is an interesting question. Basically you try to extend railML with this custom extension not to add more information that is not included in the standard, but to support a use case that so far is not supported. I will add this to the agenda of the next TT-Telco and also to the agenda of the coordinators telco.

Best regards, Milan


Milan Wölke – Timetable scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: [railML 3] New semantic constraint for trainVariant [message #3079 is a reply to message #3069] Tue, 02 May 2023 17:57 Go to previous message
Milan Wölke is currently offline  Milan Wölke
Messages: 139
Registered: April 2007
Senior Member
We discussed this question in our last TT developer call. If, as stated above a new use case needs to be supported a modelling for that use case needs to be found that does not collide with the established semantic constraints. Usually this is possible. In this case for example a different kind of variant could be imagined that would then encode the needed data for the use case. That way the semantic constraint would remain valid and importing software would only import the parts that apply to it (assuming an importing software does not support the new use case) with all assumptions applicable.

Just to have this also documented here.

Best regards, Milan


Milan Wölke – Timetable scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Previous Topic: Semantic Constraints for Train Section
Next Topic: Extension of railML's Advanced Example
Goto Forum:
  


Current Time: Fri Mar 29 03:00:10 CET 2024