| [railML3] Adding globally unique identifiers [message #3776] |
Wed, 29 October 2025 11:36  |
Mathias Vanden Auweele
Messages: 85
Registered: February 2025
Location: Brussels
|
Member |
|
|
Dear railML community
On 28/10/2025 a Bane NOR / railML workgroup took place were the need was acknowledged to have globally unique identifiers in railML files.
Currently, many xml elements can receive an @ID. But that @ID is only to be used within the boundaries of the railML file and not beyond. Many systems do not retain these ID's after ingestion and will not export the same IDs again even if they would export the same data. This creates a problem for round-trip data exchange where system A exports a current state of the infrastructure, system B imports that state and allows users to change the data to be exported again and imported into system A.
Designators can be used in some cases to identify the entities in a globally unique way. But those rely on the existence of registers and are not always a good fit for elements such as in <Geometry> and <Topology>, let alone for elements that are regarded more as properties such as <LinearLocation> and even <AssociatedNetElement>.
Another possibility would be to extend the @ID attribute to all elements and change the semantics so that this ID also holds value outside of the railML file.
But maybe it would be better to look at the evolution that is happening with knowledge graphs and ontologies. There the usage of globally unique identifiers is by means of URI's, some examples:
http://publications.europa.eu/resource/authority/country/NOR
http://data.europa.eu/949/functionalInfrastructure/operation alPoints/NO0010-01000
What does the community think? We would like to propose this change for railML 3.4
Mathias Vanden Auweele
Railway data freelancer
https://matdata.eu
Brussels, Belgium
|
|
|
|
| Re: [railML3] Adding globally unique identifiers [message #3778 is a reply to message #3776] |
Thu, 30 October 2025 16:35  |
Thomas Nygreen
Messages: 110
Registered: March 2008
|
Senior Member |
|
|
Dear Mathias,
Thank you for a clear description of this issue. The syntax of @id in railML 3.1 and 3.2 allowed either an XML ID or a UUID. The purpose was to offer a way to provide a globally unique identifier. As discussed in [railML3] How to deal with UUIDs, this type union caused problems, as it is not possible in XML to specify which of the types was actually used for the attribute. Therefore, with railML 3.3, we restricted @id to only allow XML IDs. While we initially planned to create a new @uuid attribute, the final decision was rather to add "UUID" as a global register and try to make sure that all relevant elements have <designator>s. As you point out, this has some limitations. We can also discuss these limitations, but to me the requirement for a register seems tricky to fit into the case for many of the elements that do not already have a <designator>.
UUID is also just one of the possible ways to define a globally unique identifier. I agree that we should at least consider URIs too, as a method that aligns well with our ontology work, and is more flexible in format. For instance, if it is not practical to add UUIDs to a system, it is still easy to define a mapping between internally unique IDs and matching URIs.
With UUID the idea was also that this ID is Universally Unique, i.e. it is the same in all systems where the object exists. Knowledge graphs usually acknowledge that the same entity may have different native URIs defined in different systems, and you can link these URIs with owl:sameAs. So if we provide a property for an object's URI, should it allow multiple URIs (i.e. repeatable child element)?
I also welcome the community's opinions and feedback. What kind of identifier(s) should we support, and how would you prefer it implemented?
Thomas Nygreen – Common Schema Coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
|
| Re: [railML3] Adding globally unique identifiers [message #3782 is a reply to message #3778] |
Fri, 31 October 2025 23:30 |
Mathias Vanden Auweele
Messages: 85
Registered: February 2025
Location: Brussels
|
Member |
|
|
Thank you Thomas for the very good overview of the history on UUIDs!
As for your question: "So if we provide a property for an object's URI, should it allow multiple URIs (i.e. repeatable child element)?"
That's a very good question. In essence, yes, an entity can have multiple URI. But you could also say this about UUIDs. A typical infrastructure manager will have the same entity in different systems. Even if they work with UUIDs, those entities will have different UUIDs in the different systems. At least, that's my experience at Infrabel and now in BaneNOR. UUIDs are meant to be globally unique. As in, you can pass one to someone else and if that person finds information linked to that same UUID, it's very likely to be about the entity that the first person wanted to communicate about. But just like URIs they are not enforcing 1 ressource = 1 UUID. That other person can have another UUID for the same ressource. But contrary to RDF, there's not such a standard as owl:SameAs for UUIDs :)
I think for the use cases involving railML, one URI would be sufficient.
Mathias Vanden Auweele
Railway data freelancer
https://matdata.eu
Brussels, Belgium
|
|
|
|
Members
Search
Help
Login
Home
