opengeospatial / ogc-geosparql

Public Repository for the OGC GeoSPARQL Standards Working Group
71 stars 19 forks source link

Widen the scope to all spatial data #14

Open lvdbrink opened 4 years ago

lvdbrink commented 4 years ago

Official change request: OGC CR 594

GeoSPARQL's scope is geographic data, as the name says. Less explicit, GeoSPARQL is only about vector data. However, there is a need for a web ontology that can be used to work with all kinds of spatial data. GeoSPARQL seems to be the best candidate for realization of a domain independent ontology for spatial data.

A universal, or domain independent ontology for spatial data is needed because space is a phenomenon that exists everywhere and is present in many kinds of human endeavour. Traditionally, universal phenomena like time and space have been modelled in different domains, according to domain specific requirements. Linked Data and the semantic web now offer a way to share data with many different perspectives, in a domain independent way. A domain independent ontology for time already exists: 0 . The time has now come for space to have a similar ontology. Practically, this will greatly increase interoperability of spatial data. Not only on the web: offline systems (e.g storage systems and libraries) could also benefit from having a single root model to depend on.

GeoSPARQL is a good candidate for evolving into a general ontology for spatial data because: 1) The Semantic Web allows direct open and modular access to all definitions. 2) OGC has a large canon for spatial data modelling ready for re-use. Existing OGC models have sound mathematical foundations that are applicable outside the geography domain. 3) OGC has been broadening its scope. Broadening the scope of GeoSPARQL should fit in nicely with that development. Examples of domains that are using different ways of working with spatial data, but increasingly do need to interoperate with geographic data are building information modelling (BIM) and 3D visualization. 4) OGC is an esteemed authority for standard specifications (although further collaboration with W3C would be beneficial).

Widening the scope of GeoSPARQL would certainly mean the ontology becoming much bigger. Further modularization should prevent the ontology becoming unwieldy and users becoming overwhelmed with information which is not required for their purposes. Modularization can also be used to make distinctions between vector and coverage data, where required, but to share fundamentals too.

This subject has been discussed in the Spatial Data on the Web Working Group and is a project proposal in the Spatial Data on the Web Interest Group.

FransKnibbe commented 4 years ago

A correction: "A domain independent ontology for time already exists: 0" should read "A domain independent ontology for time already exists: https://www.w3.org/TR/owl-time/".

jabhay commented 3 years ago

MoSCoW poll created

situx commented 3 years ago

There is already some related work in the BIM area: https://github.com/BenzclyZhang/BimSPARQL

FransKnibbe commented 3 years ago

Perhaps a good way to start this, or a way to estimate the impact, is to mark the fragments in the current specification (once it has been imported in GitHub) that apply to geographic data only.

FransKnibbe commented 3 years ago

Other than the title "OGC GeoSPARQL – A Geographic Query Language for RDF Data" the GeoSPARQL ontology does not appear limited to geographical data only, when looking at the semantics.

nicholascar commented 2 years ago

Milestone changed to 1.2 as this work has missed the cut-off for new work in 1.1.

wouterbeek commented 10 months ago

As a supplier, I can confirm that users of GeoSPARQL often ask us how they should integrate BIM. Some users have converted BIM models to WKT, but the result is always a bit odd. The WKTs sometimes become very complex (e.g. a surface is built up out of thousands of small triangles), and there is not an off-the-shelf way to represent where a BIM model should be placed in geo space, and what its scale should be.

I notice that some of our users are very knowledgeable in BIM and geo (Cadastres, Directorates of Waterworks, Agency of Archeological Dig Sites, etc), but they still cannot make the connection between BIM and geo themselves (under time-pressure in a project or program).

The ecosystem would benefit from the BIM and geo communities laying down the basic connections that allow users in the field to utilize and extend that connection.