|
I would like to use GeoSPARQL via the uSeekm library. According to this page: https://dev.opensahara.com/projects/useekm/wiki/OGC_GeoSPARQL it's better to not wrap geospatial literals inside the geosparql classes ontology. That would also simplify my dataset. However I'm unsure whether just using geometry literals will work with any geosparql implementation, or if support for this is specific to useekm? |
|
Disclaimer: I wrote the suggestion you are linking to. During the comment phase of the GeoSPARQL process, one of my suggestions was to make it more clear whether implementers should support your use-case. Regretfully, the committee decided to ignore that suggestion. My interpretation of the actual standard document is that implementers must allow the use geometry literals outside the geo:SpatialThing class-hierarchy, and that all functions that work on geometry literals must be able to work on such literals. However, due to how the standard is presented, it's not unlikely that other implementations base the indexes they build for geometries on geo:Geometry objects, instead of literals. In which case all your queries may still work, but they will not perform, due to not being able to use indexes for the geometry filter functions. So, although functionally possible to switch to another OGC GeoSPARQL implementation, you might run into performance issues with specific implementations if you do that. That's all guess-work though. AFAIK there are lyon three products that support (parts of) GeoSPARQL. You might want to ask the vendors/communities of these products how they interpret this. Please note that uSeekM does allow the use of the GeoSPARQL class hierarchy, including all functional properties on Geometry classes. The note you link to describes why we think it's a bad idea this ended up in the standard in it's current form. It's still supported though. |
