|
|
|
|
| Re: [Ontology v0.6] Missing properties for signals [message #3581 is a reply to message #3573] |
Tue, 22 April 2025 22:28   |
Mathias Vanden Auweele
Messages: 40
Registered: February 2025
Location: Brussels
|
Member |
|
|
Thank you for your answer Larissa. Indeed, I forgot about the scope limitation to "Partially Infrastructure (IS)"
I can't use the ETCS or speed signal suggestions as both don't apply. I was currently mapping normal light signals that serve as entrance/exit signals for stations.
I was looking more closely at speed signals and I also don't see a way to make the distinction between the announcement signal from the execution signal.
Quote:If you can think of an alternative suggestion on how to "map" this kind of XSD elements to the ontological way of modeling, please answer with a short example to be discussed in here the forum and in the meeting of the working group! Since the ontology is in beta version the modeling can still change!
I would propose to map the enumerations listed in the UML diagram linked in my first post to SKOS lists and include the different properties such as hasSignalSpeedType, hasSignalTrainMovementType, ...
Mathias Vanden Auweele
Railway data freelancer
https://matdata.eu
Brussels, Belgium
[Updated on: Tue, 22 April 2025 22:29] Report message to a moderator |
|
|
|
| Re: [Ontology v0.6] Missing properties for signals [message #3583 is a reply to message #3581] |
Wed, 23 April 2025 10:42 |
Larissa Zhuchyi
Messages: 69
Registered: November 2022
|
Member |
|
|
Dear Mathias
Quote:I can't use the ETCS or speed signal suggestions as both don't apply.
I see my answer was confusing. I do not at all suggest to use isSpeedSignal or isEtcsSignal instead of isTrainMovementSignal.
With my answer about isSpeedSignal and isEtcsSignal I just tried to present current suggestion on how to model elements "similar" to isTrainMovementSignal.
Quote:I was currently mapping normal light signals that serve as entrance/exit signals for stations.
railML.org makes it best to cover with ontology all the XSD schema as soon as possible.
However, railML is always community driven and based on expert experience. Therefore I'm encouraging once again to contribute to ontology! Please let me know if you need any assistance on this regard!
Quote:I also don't see a way to make the distinction between the announcement signal from the execution signal.
Does the documentation in Wiki of railML3 [1] answer your question?
Quote:map the enumerations listed in the UML diagram linked in my first post to SKOS lists
Currently at https://ontology.railml.org/ published railML ontology v0.6 vocabulary utilises rdf:List for enumerations for the illustration purposes.
In the railML.org cloud and ontology git repository there is file schema\railML3SHACL.ttl with SHACL shape railml3:SpeedSignalClassificationCriteria and sh:NodeShape railml3:tSignalSpeedType with SHACL list for validation purposes.
Does this way of modeling fit your use case?
If no, could you please elaborate on your use case, the advantages of SKOS lists and provide an example on how to use them for the above mentioned purposes?
[1] https://wiki3.railml.org/wiki/IS:isSpeedSignal
Sincerely,
Larissa Zhuchyi – Ontology Researcher
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
|
| Re: [Ontology v0.6] Missing properties for signals [message #3584 is a reply to message #3583] |
Wed, 23 April 2025 13:52 |
Mathias Vanden Auweele
Messages: 40
Registered: February 2025
Location: Brussels
|
Member |
|
|
Quote:With my answer about isSpeedSignal and isEtcsSignal I just tried to present current suggestion on how to model elements "similar" to isTrainMovementSignal.
Oooh OK, sorry I indeed misunderstood your comment.
I generally use the 'is' prefix when dealing with a boolean property. Something that is true or false. In the case of the TrainMovementSignal, there are 4 options, so I wouldn't use the 'is' prefix for this.
Quote:However, railML is always community driven and based on expert experience. Therefore I'm encouraging once again to contribute to ontology! Please let me know if you need any assistance on this regard!
Do you propose that I create a push request in Gitlab? That would be my preferred way to contribute instead of using the railML forum but I understood that it was best to first create a topic here and if the need for a change in the ontology was clear from the community discussion, a Gitlab Issue was created and assigned and only then the work started on that side.
But I would be more then happy to assist in active OWL development!
Quote:Does the documentation in Wiki of railML3 [1] answer your question?
Yes, the possibility is available in the railML3 xsd schema. It's just not available in the ontology. So I should have clarified my remark as to say "There is not yet a possibility to indicate the type of speed signal in the railML ontology".
Quote:Currently at https://ontology.railml.org/ published railML ontology v0.6 vocabulary utilises rdf:List for enumerations for the illustration purposes.
In the railML.org cloud and ontology git repository there is file schema\railML3SHACL.ttl with SHACL shape railml3:SpeedSignalClassificationCriteria and sh:NodeShape railml3:tSignalSpeedType with SHACL list for validation purposes.
Does this way of modeling fit your use case?
If no, could you please elaborate on your use case, the advantages of SKOS lists and provide an example on how to use them for the above mentioned purposes?
Using skos lists would be more in line with how the RINF ontology is developed (and as I understood, also other ontologies such as Gist). I would consider it good practice if we used the same approach used by industry. Here's an example on how the SHACL validation is performed for RINF when dealing with skos:
extract from https://gitlab.com/era-europa-eu/public/interoperable-data-p rogramme/era-ontology/era-ontology/-/blob/main/era-shacl/RIN F-contact-line-systems.ttl?ref_type=heads
#contactLineSystemType: # 1.1.1.2.2.1.1
era-sh:ContactLineSystemShape sh:sparql era-sh:ContactLineSystemTypeSKOS .
era-sh:ContactLineSystemTypeSKOS
a sh:SPARQLConstraint ;
era:affectedProperty era:contactLineSystemType;
era:affectedClass era:ContactLineSystem;
era:scope "local";
rdfs:comment "Indication of the type of the contact line system"@en ;
era:rinfIndex "1.1.1.2.2.1.1" ;
sh:severity sh:Violation ;
sh:message "contactLineSystemType (1.1.1.2.2.1.1): The contact line system {$this} has a value {?concept} that is not one of the predefined values and cannot be converted into a SKOS concept on this list: http://data.europa.eu/949/concepts/contact-line-systems/ContactLineSystems."@en ;
sh:prefixes era:;
sh:select """
PREFIX era: <http://data.europa.eu/949/>
PREFIX skos: <http://www.w3.org/2004/02/skos/core#>
SELECT $this ?concept
WHERE {
$this era:contactLineSystemType ?concept .
era:contactLineSystemType era:inSkosConceptScheme ?conceptScheme .
FILTER NOT EXISTS{
?concept skos:inScheme ?conceptScheme .
}
}
""" .
Mathias Vanden Auweele
Railway data freelancer
https://matdata.eu
Brussels, Belgium
|
|
|
|
| Re: [Ontology v0.6] Missing properties for signals [message #3585 is a reply to message #3584] |
Wed, 23 April 2025 15:32 |
Rémi Collet
Messages: 8
Registered: November 2024
|
Junior Member |
|
|
To elaborate and exemplify what Mathias probably means by using skos concept lists, here is a sample from Infrabel :
onotology.ttl :
### https://data.infrabel.be/edm/hasNetworkLevel
:hasNetworkLevel rdf:type owl:ObjectProperty ;
rdfs:domain :Network ;
rdfs:range skos:Concept ;
rdfs:comment """The level of detail a network has. The expected `skos:ConceptScheme` is: '[Network level] (concept-schemes/network-level.ttl)'."""@en ;
rdfs:isDefinedBy <https://data.infrabel.be/edm/> ;
rdfs:label "Has network level"@en .
Note that the ontology specificies in the rdfs:comment which skos concepts are eligible as objects of triples that use :hasNetworkLevel as predicate. This also needs to be formalized in the shacl constraints, like Mathias showed above.
Here is the associated network-level.ttl file that describes the skos concepts :
#################################################################
#
# Concept Schemes
#
#################################################################
inf-c:NetworkLevelScheme a skos:ConceptScheme ;
rdfs:label "Network level"@en ;
skos:prefLabel "Network level"@en ;
skos:definition "The amount of details a network contains."@en ;
skos:example "A railway station can be represented as a node in the Belgian network (higher level). Zooming in, a railway station can be represented as a set of multiple tracks, switches, and sidings (lower level)."@en ;
dct:source "https://wiki.railtopomodel.org/wiki/Levels_of_detail".
#################################################################
#
# Concept instances
#
#################################################################
########## Network level ##########
<https://data.infrabel.be/concepts/network-level/nano> a skos:Concept ;
rdfs:label "Nano"@en ;
rdfs:comment "Description of the insides of micro NetElements."@en ;
skos:inScheme inf-c:NetworkLevelScheme ;
skos:example "The individual parts of turnouts and crossings are network resources."@en;
skos:prefLabel "Nano"@en ;
dct:source "https://wiki.railtopomodel.org/wiki/Levels_of_detail#Nano".
<https://data.infrabel.be/concepts/network-level/micro> a skos:Concept ;
rdfs:label "Micro"@en ;
rdfs:comment "Description of the network in the nearest way to the physical level as commonly viewed."@en ;
skos:inScheme inf-c:NetworkLevelScheme ;
skos:example "Turnouts and crossings as a whole are network resources."@en;
skos:prefLabel "Micro"@en ;
dct:source "https://wiki.railtopomodel.org/wiki/Levels_of_detail#Micro".
<https://data.infrabel.be/concepts/network-level/meso> a skos:Concept ;
rdfs:label "Meso"@en ;
rdfs:comment "Description of the tracks between the operational points of the network."@en ;
skos:inScheme inf-c:NetworkLevelScheme ;
skos:example "Some turnouts, crossings and tracks are aggregated into logical groups (yards, stations, ...)."@en;
skos:prefLabel "Meso"@en ;
dct:source "https://wiki.railtopomodel.org/wiki/Levels_of_detail#Meso".
<https://data.infrabel.be/concepts/network-level/macro> a skos:Concept ;
rdfs:label "Macro"@en ;
rdfs:comment "Description of the network at regional or national level, with the NonLinearNetElements being the boundaries and the major operational points while the linear elements are the section of lines connecting those points."@en ;
skos:inScheme inf-c:NetworkLevelScheme ;
skos:example "Logical groups are defined for all operational points and used as network resources. In general, a single turnout or crossing is not a network resource on this level."@en;
skos:prefLabel "Macro"@en ;
dct:source "https://wiki.railtopomodel.org/wiki/Levels_of_detail#Macro".
|
|
|
|
| Re: [Ontology v0.6] Missing properties for signals [message #3587 is a reply to message #3584] |
Wed, 23 April 2025 17:25 |
Larissa Zhuchyi
Messages: 69
Registered: November 2022
|
Member |
|
|
Dear Mathias
Quote:I generally use the 'is' prefix when dealing with a boolean property. Something that is true or false. In the case of the TrainMovementSignal, there are 4 options, so I wouldn't use the 'is' prefix for this.
Do you think current general modelling approach described at [1] is be suitable in this case? This means that for <isTrainMovementSignal> there would be class railml3:TrainMovementSignalClassificationCriteria and a property railml3:hasTrainMovementSignalClassificationCriteria.
Quote:There is not yet a possibility to indicate the type of speed signal in the railML ontology.
From what I understand published railML ontology v0.6 includes all the needed means in this case: classes railml3:SignalIS and railml3:SpeedSignalClassificationCriteria ; properties railml3:hasSpeedSignalClassificationCriteria and railml3:hasType ; enumerated datatype railml3:tSignalSpeedType.
Property railml3:hasSpeedSignalClassificationCriteria has:
- railml3:SignalIS as domain (using rdfs:domain in the published version and dcam:domainIncludes in the latest version in railML cloud) ;
- railml3:SpeedSignalClassificationCriteria as range (using rdfs:range in the published version and dcam:rangeIncludes in the latest version in railML cloud) .
Property railml3:hasType has:
- railml3:SpeedSignalClassificationCriteria as domain ;
- railml3:tSignalSpeedType as range .
Class railml3:SignalIS has existential quantifier constraint indicating that it is to be used with property railml3:hasSpeedSignalClassificationCriteria and class railml3:SpeedSignalClassificationCriteria .
Class railml3:SpeedSignalClassificationCriteria has existential quantifier constraint indicating that it is to be used with property railml3:hasType and datatype railml3:tSignalSpeedType.
Why "there is not yet a possibility to indicate the type of speed signal in the railML ontology" ?
Quote:the advantages of SKOS lists
Enumerated datatype railml3:tSignalSpeedType at published railML ontology v0.6 does not include the documentation of enumerated values however. When modeling enumerations as rdf:resource one could simply provide documentation of enumeration value with skos:definition.
Quote:I would consider it good practice if we used the same approach used by industry.
I see at [2] an example of the other approach with enumerated OWL datatypes. They document the values of enumerated datatype using rdfs:comment at property using current enumerated OWL datatype.
Prima facie this approach seems simpler and easier to use when having the same enumeration values in the SHACL list.
What are the opinions of the community?
Quote:Do you propose that I create a push request in Gitlab? That would be my preferred way to contribute instead of using the railML forum but I understood that it was best to first create a topic here ...
As only working group members have access to both railML.org cloud and ontology Gitlab project, I would be grateful if you could fairly provide examples in Gitlab as well as here, in the railML forum for the rest of community. Same excellent way as Rémi Collet just did!
This is important to keep discussion possible outside of the working group. Thanks in advance!
[1] https://www.railml.org/forum/index.php?t=msg&th=1056& ;goto=3573&#msg_3573
[2] https://github.com/siemens/ProductConfigurationWithSHACL/blo b/feea2bfce2786a35dd22f55714999aaa7e369851/docs/topo/topo.tt l#L135
Sincerely,
Larissa Zhuchyi – Ontology Researcher
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
|
| Re: [Ontology v0.6] Missing properties for signals [message #3592 is a reply to message #3587] |
Thu, 24 April 2025 08:12 |
Sindre Asplem
Messages: 2
Registered: October 2024
|
Junior Member |
|
|
Similar to the discussion we have previously had in the working group about the usage of rdfs:domain and rdfs:range, the usage of enumerated datatypes warrants caution, especially where they place existential restrictions on the value-range of a property. The usage of enumerated datatypes for values of properties is problematic because it creates a closed definition of the value-range, which hinders the reusability of the ontology.
Take the definition of railml3:tSignalSpeedType as an example. It is defined as follows:
### http://ontology.railml.org/railml3#tSignalSpeedType
:tSignalSpeedType rdf:type rdfs:Datatype ;
rdfs:isDefinedBy "https://www.railml.org/schemas/3.2/railml3.xsd" ;
rdfs:label "tSignalSpeedType" ;
owl:equivalentClass [ rdf:type rdfs:Datatype ;
owl:oneOf [ rdf:type rdf:List ;
rdf:first "announcement" ;
rdf:rest [ rdf:type rdf:List ;
rdf:first "execution" ;
rdf:rest rdf:nil
]
]
] .
There cannot exist a world, according to the ontology, where any property with railml3:tSignalSpeedType as its range, has any other object than "announcement" or "execution". To use enumerated datatypes in this way, we must at a minimum be completely certain that there is not a use or need for any other objects. Usage of enumerated datatypes should be decided on a basis of necessity, e.g. where it adds value in terms of entailment.
While valid, as seen in [1] shared by Larissa, I find the expressivity of enumerated datatypes to be too low. A resource should be sufficiently defined on its own, and not rely on annotations (e.g. descriptions or comments) in other related resources to be understood. The argument for using SKOS is that we are building a thesaurus of these literal values (concepts), so that they can be understood on their own and in relation to other concepts.
[1] https://github.com/siemens/ProductConfigurationWithSHACL/blo b/feea2bfce2786a35dd22f55714999aaa7e369851/docs/topo/topo.tt l#L135
|
|
|
|
| Re: [Ontology v0.6] Missing properties for signals [message #3653 is a reply to message #3592] |
Wed, 18 June 2025 13:09 |
Larissa Zhuchyi
Messages: 69
Registered: November 2022
|
Member |
|
|
Dear all
on the railML ontology working group meeting 2025-05-28 by voting it was decided to use SKOS concept schemes for modeling enumerated types of XSD in the ontology.
Sincerely,
Larissa Zhuchyi – Ontology Researcher
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
|
Members
Search
Help
Login
Home
