| [Ontology] Ensuring reusability of the railML ontology [message #3460] |
Wed, 12 February 2025 11:08  |
Andreas Nakkerud
Messages: 2
Registered: October 2024
|
Junior Member |
|
|
First time poster! My name is Andreas Nakkerud, and I am Tech Lead for Optimization at Bane NOR (the Norwegian IM). I hold a Master's degree in ontology-based data access and a PhD in mathematical optimization (rail and transportation domain).
I want to point out that the current use of rdfs:domain hinders the reusability of the railML ontology. Before going into detail, I want to point out that the arguments I will be making depend on the assumption that the railML ontology should be reusable in a very broad sense. There are two directions we could go:
- The railML ontology has one fully supported purpose: to mimic the structure of railML
- The railML ontology should be able to model the same information as railML while being reusable by other ontologies and for other purposes
For the remainder, I will assume the second option.
I have uploaded a presentation explaining the details of rdfs:domain and some finer points regarding reusability. I recommend reading this presentation before continuing.
When using rdfs:domain, we are stating universal truths that no ontology should every challenge.
- Good: :hasChild rdfs:domain :Parent (Anything that has a child is a parent)
- Bad: :hasChild rdfs:domain :Person (Anything that has a child is a person)
The good example is a proper part of the definition of a parent, the bad example prevents the ontology from being used for animals.
In the current version (0.6) of the ontology, rdfs:domain is used in a way that frequently prevent reuse without alteration. If the user of an ontology is forces to alter the ontology, then we no longer agree on the definitions of the terms in the ontology and interoperability is lost.
The core of the problem is that ontologies are a limited modelling framework that is highly specialized for Open-World modeling, and the current demands being put on rdfs:domain are not really supported in ontological modeling. I initially suggest two options:
- Avoid the use of rdfs:domain as much as possible
- Use a technique similar to the one proposed in the presentation to allow reusability while keeping the current use of rdfs:domain
---
Andreas Nakkerud
Tech Lead Optimization, Bane NOR
|
|
|
|
|
|
|
|
| Re: [Ontology] Ensuring reusability of the railML ontology [message #3484 is a reply to message #3460] |
Tue, 25 February 2025 13:30  |
Sindre Asplem
Messages: 1
Registered: October 2024
|
Junior Member |
|
|
I agree with your sentiment that the current usage of rdfs:domain and rdfs:range is problematic, but I see this as a result of a lacking class taxonomy. However, I don't believe that the solution should be to avoid defining the domain and range for properties. Domain and range serve as a failsafe to ensure that individuals in the KG are appropriately typeset, based on, as you said, universal truths about the type of individuals related by a role. This is important for interoperability and reuse of the ontology.
Going forward I will only describe domain of a property, but this also applies to range.
I would suggest an approach in line with your suggestion:
"b. Use a technique similar to the one proposed in the presentation to allow reusability while keeping the current use of rdfs:domain"
Meaning, replacing complex domains with a single class. However, I fear that your wording "dedicated domain classes" may be misinterpreted.
For the domain of a property to serve its purpose, it should state some universal truth about the subject of the triple, while still being sufficiently general. To allow for broad reuse, including specialisation of the class stated as the domain of the property. I believe that a "dedicated domain class" should not be a class that is specific only to one property, such as :DomainOfHasChild, rather a class that carries meaningful information, e.g. ":Parent".
In my view, the current structure of the class taxonomy is limiting its usability, and should be restructured.
As a simple example we can look at the property :hasTime:
@prefix : <http://ontology.railml.org/railml3#> .
### http://ontology.railml.org/railml3#hasTime
:hasTime rdf:type owl:DatatypeProperty ;
rdfs:domain [ rdf:type owl:Class ;
owl:unionOf ( :Arrival
:Departure
)
] ;
As there is no taxonomic relation between :Arrival and :Departure, we are missing a class to be used as the domain for the property :hasTime. Since we want to state that the domain of this property could be either of the classes :Arrival or :Departure, this can be defined as the union of these classes. As an alternative to this, we can introduce a generalised superclass to both of these classes, e.g. :Event. Resulting in:
@prefix : <http://ontology.railml.org/railml3#> .
:Event rdf:type owl:Class .
:Arrival rdf:type owl:Class ;
rdfs:subClassOf :Event .
:Departure rdf:type owl:Class ;
rdfs:subClassOf :Event .
:hasTime rdf:type owl:DatatypeProperty ;
rdfs:domain :Event .
This fulfills what I believe intended purpose of the complex domains, with much less complexity. Resulting in an ontology that can more easily be understood and maintained. While also allowing for improved reusability, where any third party can extend the ontology based on their specific requirements by introducing new sub-classes of :Event.
|
|
|
|
| Re: [Ontology] Ensuring reusability of the railML ontology [message #3488 is a reply to message #3460] |
Mon, 03 March 2025 09:51 |
Larissa Zhuchyi
Messages: 57
Registered: November 2022
|
Member |
|
|
Dear all
Based on discussion from 2025-02-26 railML ontology working group it was preliminary decided to replace rdfs:domain and rdfs:range with schema:domainIncludes and schema:rangeIncludes.
I agree with this suggestion as soon as:
- rdfs:domain and rdfs:range bring not needed so far kind of inferencing in the ontology.
- vocabulary should demonstrate how to use properties (discussion of working group from 2024-10-16), therefore just removing rdfs:domain and rdfs:range is not a case.
I think however that dcam:domainIncludes and dcam:rangeIncludes would be more appropriate because of licensing of Schema.org (Creative Commons Attribution-ShareAlike License) and Dublin Core (Creative Commons Attribution 4.0 International License).
Please let railML.org know your opinions! Thanks in advance!
Sincerely,
Larissa Zhuchyi – Ontology Researcher
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
|
|
|
| Re: [Ontology] Ensuring reusability of the railML ontology [message #3514 is a reply to message #3484] |
Mon, 17 March 2025 20:45 |
Andreas Nakkerud
Messages: 2
Registered: October 2024
|
Junior Member |
|
|
To have a time is indeed one of the defining characteristics of an event, so in this case Event is indeed the rdfs:domain of hasTime. This is just an example of the proper use of rdfs:domain, and is therefore not very illuminating.
I think it is very important that we also discuss properties that are not defining characteristics of a natural class. In that case, the options remain to stop using rdfs:domain, to use a dedicated domain class, or to use some version of domainIncludes.
Let us consider hasLength as an example. In this case, there is no very natural rdfs:domain. Geometric objects, furniture, vehicles, roads, people, and foot races are just a few examples of things with length. We can consider artificial options like ObjectWithLength, Lengthy, and DomainOfHasLength. In this case, I think using domainIncludes makes a lot of sense, but not using rdfs:domain.
Finally, a note for those following this discussion. It may seem tempting to be a bit loose with the use of rdfs:domain, but this is a very dangerous path to start down. It would go against everything RDFS stands for and would very seriously undermine the project.
|
|
|
|
| Re: [Ontology] Ensuring reusability of the railML ontology [message #3517 is a reply to message #3514] |
Wed, 19 March 2025 09:40 |
Rémi Collet
Messages: 6
Registered: November 2024
|
Junior Member |
|
|
I agree with Andreas. We need a solution that fully agrees with the ontology we are reusing, without compromising too much readability. But we need very concrete rules to implement.
How does this sound :
- When an object property has only one intended domain (range) class, then the use of rdfs:domain (rdfs:range) is warranted
- When an object property may have more than one intended domain (range) classes, then the use of dcam:domainIncludes (dcam:rangeIncludes) is preferred
- If a property is widened during development, then we change from rdfs:domain (rdfs:range) to dcam:domainIncludes (dcam:rangeIncludes)
I know these rules are very simplistic, and they assume "good modeling" (try defining that ^^') as was demonstrated above ; but they could be a good rule of thumb for most cases.
[Updated on: Wed, 19 March 2025 09:47] Report message to a moderator |
|
|
|
Members
Search
Help
Login
Home
