Home » railML newsgroups » railml.common » [Ontology v0.6] IntrinsicCoordinate & GeometricCoordinate vs GeoSPARQL (Should we make IntrinsicCoordinate a subclass of gsp:Feature?)
[Ontology v0.6] IntrinsicCoordinate & GeometricCoordinate vs GeoSPARQL [message #3523] Mon, 24 March 2025 12:33 Go to next message
Mathias Vanden Auweele is currently offline  Mathias Vanden Auweele
Messages: 40
Registered: February 2025
Location: Brussels
Member
Should we make IntrinsicCoordinate a subclass of gsp:Feature?

The result will be that IntrinsicCoordinate will inherit the property hasGeometry and thus the ability to position using geometric coordinates. The following classes and properties will no longer be necesary:

https://ontology.railml.org/#http://ontology.railml.org/rail topomodel#hasGeometricCoordinate
(including begin/end)

https://ontology.railml.org/#http://ontology.railml.org/rail topomodel#hasGeometricCoordinate
-> replaced with hasGeometry

https://ontology.railml.org/#http://ontology.railml.org/rail topomodel#GeometricPositioningSystem
-> The definition is included in one of the datatype properties of the instance that hasGeometry refers to

https://ontology.railml.org/#http://ontology.railml.org/rail topomodel#hasGeometricCoordinate


Mathias Vanden Auweele
Railway data freelancer
https://matdata.eu
Brussels, Belgium
Re: [Ontology v0.6] IntrinsicCoordinate & GeometricCoordinate vs GeoSPARQL [message #3524 is a reply to message #3523] Mon, 24 March 2025 12:37 Go to previous messageGo to next message
Mathias Vanden Auweele is currently offline  Mathias Vanden Auweele
Messages: 40
Registered: February 2025
Location: Brussels
Member
A similar analysis can be made for the screen coordinates. These are very similar to gsp:Geometry.

Instead of making the IntrinsicCoordinate a subclass of gsm:Feature, an alternative could be to make both GeometricCoordinate and ScreenCoordinate a subclass of gsp:Geometry


Mathias Vanden Auweele
Railway data freelancer
https://matdata.eu
Brussels, Belgium
Re: [Ontology v0.6] IntrinsicCoordinate & GeometricCoordinate vs GeoSPARQL [message #3601 is a reply to message #3524] Tue, 29 April 2025 22:38 Go to previous messageGo to next message
Larissa Zhuchyi is currently offline  Larissa Zhuchyi
Messages: 69
Registered: November 2022
Member
Dear Mathias

I agree with you that reusing established ontologies is a best practice in ontology development even though currently not much in use in published at https://ontology.railml.org/ railML ontology v0.6.

Could you please provide small examples of:

1) schema definition combining GeoSPARQL ontology and published at https://ontology.railml.org/ railML ontology v0.6

2) data populating schema from point 1)

3) GeoSPARQL query to be used with 1) and 2) with expected result?

Sincerely,


Larissa Zhuchyi – Ontology Researcher
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: [Ontology v0.6] IntrinsicCoordinate & GeometricCoordinate vs GeoSPARQL [message #3604 is a reply to message #3601] Tue, 29 April 2025 23:29 Go to previous messageGo to next message
Mathias Vanden Auweele is currently offline  Mathias Vanden Auweele
Messages: 40
Registered: February 2025
Location: Brussels
Member
Ok, I will make time for this later this week.

Mathias Vanden Auweele
Railway data freelancer
https://matdata.eu
Brussels, Belgium
Re: [Ontology v0.6] IntrinsicCoordinate & GeometricCoordinate vs GeoSPARQL [message #3608 is a reply to message #3601] Wed, 30 April 2025 11:51 Go to previous message
Mathias Vanden Auweele is currently offline  Mathias Vanden Auweele
Messages: 40
Registered: February 2025
Location: Brussels
Member
So there are several ways to do this. I'm going to focus on the geometric coordinate. But the same can be done for the screen coordinates.

Currently, this would be a data sample using the current ontology:

bnd:_gps01 a rtm:GeometricPositioningSystem ;
    rdfs:label "EPSG:25832 - ETRS89 / UTM zone 32N"@en ;
    railml3:hasCrsDefinition "EPSG:25832" ;
    time:hasBeginning bnd:_timeinstant_2000-01-01 ;
    time:hasEnd bnd:_timeinstant_9999-01-01 .

bnd:_spotlocation_1 a rtm:SpotLocation 
    rtm:onNetElement bnd:_netelement_1 ;
    rtm:hasApplicationDirection "reverse" ;
    rtm:hasIntrinsicCoordinate 0.1 ;
    rtm:hasGeometricCoordinate bnd:_geometric_coordinate_1 .

bnd:_coordinate_1 a rtm:GeometricCoordinate ;
    rtm:hasXCoordinate 111111 ;
    rtm:hasYCoordinate 222222 ;
    rtm:hasZCoordinate 333333 ;
    rtm:refersToPositioningSystem bnd:_gps01 .

If we define in the ontology:

rtm:SpotLocation rdf:type owl:Class ;
	rdfs:subClassOf [...], gsp:Feature
	[...] .

rtm:hasGeometricCoordinate rdf:type owl:ObjectProperty ;
  rdfs:subPropertyOf gsp:hasGeometry, [...] ;
  [...] .
(and remove the rtm.GeometricCoordinate)

We can use geosparql in our knowledge graph like this:

bnd:_spotlocation_1 a rtm:SpotLocation 
    rtm:onNetElement bnd:_netelement_1 ;
    rtm:hasApplicationDirection "reverse" ;
    rtm:hasIntrinsicCoordinate 0.1 ;
    rtm:hasGeometricCoordinate bnd:_geometric_coordinate_1 .

bnd:_geometric_coordinate_1 a gsp:Geometry ;
    gsp:hasSerialization "<http://www.opengis.net/def/crs/EPSG/0/25832> POINT(111111, 222222, 333333)^^geo:wktLiteral";

But it also opens up all the properties related to geosparql that would enhance the information available on the coordinate, such as defining SpatialAccuracy.

The advantages:
- integration with standardized and industry state of the art ontology
- geometric functions are immediately available to work with the coordinates in most SPARQL implementations
- geosparql geometries are by standard implemented in viewers such as Yasgui https://yasgui.triply.cc/
- less ontology to maintain


Mathias Vanden Auweele
Railway data freelancer
https://matdata.eu
Brussels, Belgium
Previous Topic: [Ontology v0.6] Missing properties for intrinsicCoordBegin/End
Next Topic: [Ontology v0.6] Validity
Goto Forum:
  


Current Time: Sun Jun 22 05:19:36 CEST 2025