| [railML 2] <speedChange> semantic constraints revision [message #3078] |
Fri, 28 April 2023 13:16  |
Larissa Zhuchyi
Messages: 30
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  |
christian.rahmig
Messages: 436
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 |
Thomas Nygreen
Messages: 66
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 |
Larissa Zhuchyi
Messages: 30
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
|
|
|
|
Members
Search
Help
Login
Home
