Home » railML newsgroups » railML.infrastructure » [railML3] Restricting IS:line and RTM:linearPositioningSystem (New semantic constraints suggested)
[railML3] Restricting IS:line and RTM:linearPositioningSystem [message #3224] Wed, 10 April 2024 16:59 Go to next message
Larissa Zhuchyi is currently offline  Larissa Zhuchyi
Messages: 33
Registered: November 2022
Member
Dear all

Based on the issues discovered during the recent certifications of railML3 data and the "new" initiative of railML.org defining best practices for splitting and merging railML3 file, railML.org suggests to introduce new semantic constrains. Please review the suggested semantic constrains IS:006 and IS:014 and provide your comments.

Suggested semantic IS:006 constraint for railML3
each railway line with own mileage should always be associated with its own <linearPositioningSystem>, i.e. Advanced example of railML has three lines with their own mileages, thus should have thee <linearPositioningSystem>s.

Suggested semantic IS:014 constraint for railML3
@startMeasure and @endMeasure are start and end values of a railway <IS:line> associated with <RTM:linearPositioningSystem> not max and min values of a current file with e.g. line section

See the all semantic constraint on the Wiki https://wiki3.railml.org/index.php?title=Dev:Semantic_Constr aints

Thanks in advance.

Sincerely,


Larissa Zhuchyi – Ontology Researcher
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: [railML3] Restricting IS:line and RTM:linearPositioningSystem [message #3231 is a reply to message #3224] Thu, 25 April 2024 20:13 Go to previous messageGo to next message
Michael Gruschwitz is currently offline  Michael Gruschwitz
Messages: 12
Registered: May 2020
Junior Member
Dear Larissa,
dear all,

Thank you for proposing the new semantic constraints IS:006 and IS:014
for railML3. At Bahnkonzept, we specialize in railway infrastructure
surveys, often of only partial lines, and face challenges with the
current constraint IS:014. It assumes definitive start and end values
(@startMeasure and @endMeasure) for a railway line, which isn't always
possible in our operations.

We suggest either providing an alternative to indicate uncertainty in
these measures or considering the removal of this constraint while
retaining IS:006. This adjustment would better support the real-world
scenarios of data providers like us and ensure broader applicability and
accuracy of railML3 data.

We appreciate your attention to this matter and look forward to a
productive discussion.

Best regards,
--
Michael Gruschwitz
Bahnkonzept Dresden/Germany

Am 10.04.2024 um 16:59 schrieb Larysa Zhuchyi:
> Dear all
>
> Based on the issues discovered during the recent
> certifications of railML3 data and the "new" initiative of
> railML.org defining best practices for splitting and merging
> railML3 file, railML.org suggests to introduce new semantic
> constrains. Please review the suggested semantic constrains
> IS:006 and IS:014 and provide your comments.
>
> Suggested semantic IS:006 constraint for railML3
> each railway line with own mileage should always be
> associated with its own <linearPositioningSystem>, i.e.
> Advanced example of railML has three lines with their own
> mileages, thus should have thee <linearPositioningSystem>s.
>
> Suggested semantic IS:014 constraint for railML3
> @startMeasure and @endMeasure are start and end values of a
> railway <IS:line> associated with
> <RTM:linearPositioningSystem> not max and min values of a
> current file with e.g. line section
>
> See the all semantic constraint on the Wiki
> https://wiki3.railml.org/index.php?title=Dev:Semantic_Constr aints
>
> Thanks in advance.
>
> Sincerely,
> --
> Larissa Zhuchyi – Ontology Researcher
> railML.org (Registry of Associations: VR 5750)
> Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: [railML3] Restricting IS:line and RTM:linearPositioningSystem [message #3236 is a reply to message #3231] Mon, 29 April 2024 16:24 Go to previous message
Larissa Zhuchyi is currently offline  Larissa Zhuchyi
Messages: 33
Registered: November 2022
Member
The idea of IS:014 was to try to avoid postprocessing of split file when merging them together issued by either:
- multiple partial linear positioning systems in the merged file or
- one linear positioning system with multiple e.g. @endMeasure attributes.

From what I understand merging may happen even in your use case of surveys. As conceptually what you produce, partitioned files, can be considered as equivalent to split ones. Please correct me if I'm wrong.

How would you handle it if you made incremental surveys and the data would belong to the same railway line?
- introduce one linear positioning system with persistent identifier only in the first measurement trip and then replace @endMeasure every time new data come from the next measurement trip or
- introduce new linear positioning systems every time new data come. Then the railway line will be associated with more then one linear positioning systems.


Larissa Zhuchyi – Ontology Researcher
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Previous Topic: Infrastructure element datamodel quality and input-data source
Next Topic: [railML3] Restricting aggregation of RailTopoModel
Goto Forum:
  


Current Time: Tue Apr 30 21:33:41 CEST 2024