|[railML2/3] creating a new element to describe the project metadata [message #2682]
||Mon, 15 March 2021 15:23
Registered: March 2016
The Norwegian railway sector has the need to transfer information on the metadata of the project. We consider this separate from the existing <metadata> elements and attributes given by Dublin Core. These existing metadata we see as administrative metadata about the dataset. Examples for this are the author, the name of the database containing the model exported, the name of the software and its version creating the export or the export date etc. The project metadata are different. They describe the reason/the purpose for the railML data exists. Examples for this are the name of the project, the name of the different alternatives and if defined what project phase the contained <infrastructure>, <timetable> and/or <rollingStock> dataset is describing. Note that the same distinction is made towards the existing <state> element.|
Bane NOR and Jernbanedirektoratet currently use a nor: extension to describe infrastructure projects as a child to <infrastructure>. But we realised that there are also timetable and rolling stock projects. Because of this we suggest to add a new <project> element under <common> in railML3 and <metadata> in railML2.5. For <timetable> the suggested <project> could replace the deprecated (due to ambiguity) @processStatus attribute.
For more details see document "railML2.4nor Infrastructure Documentation" (https://www.jernbanedirektoratet.no/railML), version 1.4, 17.12.2020, point 4.13.
Jernbanedirektoratet and Bane NOR are suggesting adding the nor: extension into railML2.5 as:
<project> with container element <projects>. The project describing the referenced <infrastructure>, <timetable> or <rollingStock> dataset.
@name "human readable short name of the project" Example: "Lengthening Ler crossing loop"
@description "human readable description of the project" Example: "Lengthening of the crossing loop from 452m effective length to 650m effective train length".
I suggest not to have @code, as <designator> is more precise.
Sub element <projectDesignator> (or just <designator>) containing the standard designator attributes. The designator describes the project in an unambiguous way according to referenced existing registers. There can be multiple <projectDesignator> as the same project can be described in different registers.
Sub element <alternative> under <project>. The alternative describes the relevant alternative for the referenced dataset from the different alternatives of the project
@code "machine readable string to identify the alternative univocally within the project" Example:"1A"
@name "human readable short name of the alternative" Example: "extension south"
@description "human readable description of the alternative" Example: "Alternative with moving switch 1 198m south"
Sub element <phase> under <alternative>. The phase of the project defined in stages. To univocally describe a project all three elements <project>, <alternative> and <phase> must be described. Because of this, the reference attribute to the dataset is placed in the <phase> element. An example for this would be for a simple project where there is on one alternative and one phase. The receiving system does not know this unless this is defined. Here set <alternative>@name="main" and phase="built".
You can define unlimited projects, alternatives and phases. But as railML2 is only a snapshot the referenced dataset can only contains one set of the sub-elements. <nor:projectDesignator>, <nor:alternative>, <nor:phase> and <nor:revision>.
@code "machine readable string to identify the phase univocally within the project alternative Example:"40"
@name "human readable short name of the phase" Example: "built"
@description "human readable description of the phase" Example: "As built and ready for operation"
@ref "reference to the object describing/containing the project. This can be for example the entire <infrastructure>, <timetable> or <rollingStock> or when the dataset contains multiple projects. A subset defined by either <area@type="project" (separate posting), <trainGroup> or other existing container element.
The phase can also be defined by standards in the national planning law or by defined entity internal phases. For this we suggest to use:
@regulation Planning stage/phase defined by national law for public planning process. As this is independent per nation we suggest to have a loose standard here and make this attribute string. Alternative we could have some generic stages and map the different national stages to the generic ones. We suggest one semantic constraint value "built" for As built and ready for operations. This as an internationally unambiguous stage. As an example the Norwegian values would be "regionalplan" (regional plan), "kommunedelplan" (municipal plan) "reguleringsplan" (zoning plan) and "built"
@planningStage Planning stage/phase defined entity/company in charge of the planning process. As this is independent per entity we suggest having a loose standard here and make this attribute string.
As an example the Norwegian values would be "KVU" (conceptual plan), "utredning" (strategic plan), "hovedplan" (main plan), "detaljplan" (detailed plan) and "byggeplan" (building plan).
@startDate [xs:date] Refers to when the phase starts
@endDate [xs:date] Refers to when the phase ends
In the Norwegian extension for <nor:project> we also included extensions for a revision handling UC. I will make a separate posting for this, as the two topics can be implemented separately and not to overload this topic.
<project description="myDescr" id="pr1" name="Testprojekt">
<projectDesignator entry="K.04-51" register="_JDIRKontrakt"/>
<projectDesignator entry="265174" register="_BaneNorProsjektRegister"/>
<alternative code="Alt1" description="myAlternativeDescription" id="alt1" name="Better Alternative"/>
<phase code="22.1" description="myPhaseDescription" id="pha1" name="Better Phase" regulationPhase="built" planningPhase="byggeplan" startDate="1999-12-31" endDate="2001-12-31" ref="id-area31"/>
What does the community think?