Home » railML newsgroups » railML.infrastructure » [railML 2] <speedChange> semantic constraints revision (need to discuss a way to model speed changes)
[railML 2] <speedChange> semantic constraints revision [message #3078] Fri, 28 April 2023 13:16 Go to next message
Larissa Zhuchyi is currently offline  Larissa Zhuchyi
Messages: 38
Registered: November 2022
Member
Dear all,

railML 2 <speedChange> wiki page [1] includes semantic constraints that are quite ambiguous:

- Every <track> has to have at least one <speedChange> at the track begin with parameters @pos="0" and @dir="up".

- Every <track> has to have at least one <speedChange> at the track end with parameters @pos="{value equal to trackEnd@pos}" and @dir="down".


It would be good to extend them with the following points (based on the TT working group's view). Please communicate your thoughts in this regard:

(1) Only applies if speedChanges are exported at all [as they are not required by XSD (editor's comment)].

(2) It also only applies if both directions can be accessed, otherwise corresponding exceptions would have to apply.

(3) There is also the question of whether the SemCon is meant to apply to the entire file or only per <track>. So if speedChanges are issued in the file for one track, must the SemCon also be applied to all other <tracks>?

[1] https://wiki2.railml.org/wiki/IS:speedChange


Larissa Zhuchyi – Ontology Researcher
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: [railML 2] <speedChange> semantic constraints revision [message #3080 is a reply to message #3078] Thu, 04 May 2023 08:57 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 447
Registered: January 2016
Senior Member
Dear Larissa,

thanks for bringing up the findings of the TT dev group. I absolutely agree with points (1) and (2). Concerning (3) I consider the check of the preconditions to be done for each track individually as there may be a file including both, a track that can be passed only in one direction and another one for both directions. So, if there are no objections from the community until end of next week, I suggest to adapt the SemCons accordingly.

Best regards
Christian


Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: [railML 2] <speedChange> semantic constraints revision [message #3084 is a reply to message #3080] Wed, 10 May 2023 13:24 Go to previous messageGo to next message
Thomas Nygreen is currently offline  Thomas Nygreen
Messages: 68
Registered: March 2008
Member
Dear all,

I note that the current semantic constraint ("every <track>") is far more extensive than the origin referred to in the background information (ticket #425 [1] pointing to railML2.4nor, which requires <speedChange>s to be placed on "a <trackBegin> or <trackEnd> that is not connected to another track"). Was this difference intended? While our Wiki documentation says that "A <speedChange> defines a track element in which position the maximum allowed speed on a track changes", this semantic constraint would mean that a large share of <speedChange>s are not placed in a position where the maximum speed changes, but on all points where <track>s are split. It seems to me that with this use the element should not have a name containing "Change". While we cannot change the name, we should modify either the documentation or the semantic constraint.

As Christian, I agree with Larissa's points (1) and (2). The question in (3) is more tricky. How would you use a file that contains speeds for some tracks but not all? I would assume that an exporting or importing software either uses speed information on all tracks or on none of them. Also, how would the consuming software know which is which? (Should the initial <speedChange> work as a flag that this <track> has speed information?)

[1] https://development.railml.org/railml/version2/-/issues/425

Best regards,
Thomas


Thomas Nygreen – Common Schema Coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: [railML 2] <speedChange> semantic constraints revision [message #3106 is a reply to message #3084] Fri, 07 July 2023 09:39 Go to previous message
Larissa Zhuchyi is currently offline  Larissa Zhuchyi
Messages: 38
Registered: November 2022
Member
Dear all

As a result of a discussion, we extended the section on semantic constraints by (1-2) points [1].

From what I understood there is no consensus regarding point (3) though. Let's have it implementation specific for now.

Additionally, as ontology is now under development, probably a constraint in Shapes Constraint Language [2] (language for describing and validating RDF (Resource Description Framework) graphs) can be developed if found some tracks with speedChange and others without.

[1] https://wiki2.railml.org/wiki/IS:speedChange
[2] https://www.w3.org/TR/shacl/

Sincerely;
Larissa Zhuchyi


Larissa Zhuchyi – Ontology Researcher
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Previous Topic: Visual positionning in step-by-step example
Next Topic: Extension of railML's Advanced Example
Goto Forum:
  


Current Time: Mon Jul 15 09:49:38 CEST 2024