| Extension suggestion for <upTime> [message #2330] |
Mon, 17 February 2020 15:06  |
Torben Brand
Messages: 162
Registered: March 2016
|
Senior Member |
|
|
Dear railML-community,
For the Norwegian railway sector, we are looking for a way to model an ocp, that is unmanned on certain timely restrictions. The restrictions we would like to model are specific days, for example Saturdays or public holidays.
The element <upTime> (https://wiki2.railml.org/index.php?title=IS:uptime) makes it possible to state that an ocp is unmanned with @mode="unmanned". But it doesn't give us the possibility to restrict this property to certain days, but only certain times in a day with @from and @until.
The element <propOther/states/state> on the other hand would give us the option to refer to an operating period via @operatingPeriodRef and thus makes it possible to model restrictions for certain days (in the sub element <operatingDay>).
We would like to propose a solution to extend the element <upTime> with the time attributes of <state>: @operatingPeriodRef and @endDayOffset. The existing attributes @from and @until seem to be semantically equivalent to @startTime and @endTime. So, we suggest keeping them as is, but to change their semantic constraint from mandatory to optional.
Furthermore, we are looking for a description of the value "off" in <upTime>@mode. What does this value stand for?
What does the community think?
|
|
|
|
| Description of <upTime>@mode (Re: Extension suggestion for <upTime>) [message #2339 is a reply to message #2330] |
Fri, 21 February 2020 21:40  |
Vasco Paul Kolmorgen
Messages: 60
Registered: November 2004
|
Member |
|
|
Dear Torben, dear all,
I don't want to anticipate the discussion by the community about the
proposed extensions, but I would like to contribute something to the
meaning of the individual values at <ocp> <propOperational><uptime>@mode:
Am 18.02.2020 um 03:06 schrieb Torben Brand:
> Furthermore, we are looking for a description of the value
> "off" in <upTime>@mode. What does this value stand for?
- „manned“: The <ocp> is operational/usable and staffed with IM's
personnel ready for operation on site (in the area of the <ocp>).
- „unmanned“: The <ocp> is operational/usable and not staffed with on
site personnel by the IM. Even the <ocp> is not controlled or is remote
controlled by any staff of the IM and there is no IM’s staff is
available in the area of the <ocp>.
- „off“: The <ocp> is temporarily not operational/usable. No
information about local staff is given by this value. Please note that
the values <ocp><states><state>@status={disabled|closed} shall be used
for a long-term non-defined or permanent disabling of an <ocp>.
Additonally the following semantic constraints should apply:
- an <ocp> with attribute @operationalType“blockSignal“ shall not have
<propOperational><uptime>@mode=“manned“ (as a manned blockSignal shall
be modelled in railML 2.x as blockPost),
- an <ocp> with attribute @operationalType=“stoppingPoint“ shall not
have <propOperational><uptime>@mode=“manned“ (as a stoppingPoint has no
operational usage and therefore no operational staff by the IM),
- an enumeration of several time periods by @from and @until for one
<ocp> shall not overlap so that for every time there shall be a unique
status of <uptime>.
What do you think about?
Are there additional semantic constraints to be described?
Best regards,
--
Vasco Paul Kolmorgen - Governance Coordinator
railML.org (Registry of Associations: VR 5750)
Phone railML.org: +49 351 47582911
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
|
|
|
| Re: Extension suggestion for <upTime> [message #2355 is a reply to message #2330] |
Wed, 26 February 2020 21:58 |
christian.rahmig
Messages: 465
Registered: January 2016
|
Senior Member |
|
|
Torben Brand wrote on Mon, 17 February 2020 15:06Dear railML-community,
For the Norwegian railway sector, we are looking for a way to model an ocp, that is unmanned on certain timely restrictions. The restrictions we would like to model are specific days, for example Saturdays or public holidays.
The element <upTime> (https://wiki2.railml.org/index.php?title=IS:uptime makes it possible to state that an ocp is unmanned with @mode="unmanned". But it doesn't give us the possibility to restrict this property to certain days, but only certain times in a day with @from and @until.
The element <propOther/states/state> on the other hand would give us the option to refer to an operating period via @operatingPeriodRef and thus makes it possible to model restrictions for certain days (in the sub element <operatingDay>).
We would like to propose a solution to extend the element <upTime> with the time attributes of <state>: @operatingPeriodRef and @endDayOffset. The existing attributes @from and @until seem to be semantically equivalent to @startTime and @endTime. So, we suggest keeping them as is, but to change their semantic constraint from mandatory to optional.
Dear Torben, dear all,
the current implementation of <ocp><propOperational><uptime> is not usable for regular/repeating time patterns as descibed by you. Your proposal to add an attribute @operatingPeriodRef as it is already available in <ocp><propOther><states><state> sounds reasonable.
However, for version compatibility reasons (within railML 2.x), we are not able to set <uptime> attributes @from and @to from mandatory to optional. Further, I see a semantic overlap between the usage of <ocp><propOperational><uptime> and <ocp><propOther><states><state>. I would like to solve this potential conflict by clarifying the current practical usage of both elements. Therefore, any feedback from the community is very much welcome.
Thank you very much and best regards
Christian
Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
|
|
|
|
|
| Re: Semantic constraints for <upTime> [message #2688 is a reply to message #2344] |
Thu, 25 March 2021 15:39 |
Vasco Paul Kolmorgen
Messages: 60
Registered: November 2004
|
Member |
|
|
Dear all!
Am 25.02.2020 um 10:46 schrieb Torben Brand:
> Excellent! This explains a lot! Could you post the
> definitions to the wiki?
As the semantic constraints IS:008, IS:009 and IS:010 are in the
railML's wiki (https://wiki2.railml.org/index.php?title=IS:uptime) since
more than a year without objection I suggest to set the status of these
to "accepted".
Please let us know up to April 15th, if this is not okay for you.
Best regards,
--
Vasco Paul Kolmorgen - Governance Coordinator
railML.org (Registry of Associations: VR 5750)
Phone railML.org: +49 351 47582911
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
|
Members
Search
Help
Login
Home
