Alternative vision: Creation of an Geometry Ontology and add all geometrical information and embedded semantics in RDF / RDFS / OWL

[peterrdf]

Although many experts mention / think geometry and Linked Data / Semantic Web are not a happy marriage I am convinced this does not has to be the case. As with non-geometrical data, also geometrical data contains a lot of semantics and if modelled correctly I would even say very often the amount of original data points in real-life data sets is small enough to be handled by modern triple stores.

Open standards that can handle such semantically rich geometry like IFC and STEP AP242 have class / entity counts for the semantics in geometry concepts of far above 200 where WKT as used for current (2D) GeoSPARQL count less than 10.

In my perception it would be great to create an ontology representing such semantically rich geometry with the same level of detail as IFC or AP242. Of course ifcOWL implicitly does, however being a direct conversion from EXPRESS it has some illogical structures from Linked Data / Semantic Web point-of-view. Our own GEOM ontology (https://rdf.bg/gkdoc/NURBSSurface/CP64.html) is another attempt with its own limitations. Still as a proposal I would like to add the view that introducing an ontology for semantically rich geometry as a base for 3D GeoSPARQL would introduce two major benefits:

• as all geometrical data is available as RDF data integration with other (non-geometrical) ontologies and direct services within the triple stores are more natural from a data architecture point-of-view

• as design intent is part of the data use-cases that require design intent (or derived data like topology for example) can make use of this data; enabling more use-cases

Maybe the biggest change within this proposal is that geometry, like all other data, can be stored in the triple store (semantically, not as a string) and is not defined in an external non-related formats like WKT, glTF, OBJ, OpenUSD, etc.

Creation of such an ontology for geometry can be time-consuming and complex, however we have good data models available that have proven to work. Also we don't need to solve the complete world at once, just I propose to store geometry semantically rich where possible and as RDF data, i.e. in the same manner as all other non-geometrical data is stored in the world where SPARQL and SHACL live.

[FransKnibbe]

I agree with the idea that it should be possible to encode geometry in RDF. Not as a replacement for the non-RDF serialisations, but as another option. Issue 42 essentially is about this.
@peterrdf, why do you think a separate ontology is needed? I think GeoSPARQL is already well suited to have an extension that allows expressing geometry in RDF. It could start with using the Simple Features model, but that does not have to exclude other ways of modelling geometry.

[peterrdf]

Dear @FransKnibbe, good to add this comment so I can try to rephrase the differences here. In my perception what is there in WKT or GeoSPARQL is a technical capability to define meshed / segmented content in 0D (points), 1D (lines, edges), 2D (surfaces) and maybe even in 3D. What in my perception is missing is the semantical richness of the geometry, think about Advanced Faces (BREP's), all kind of formula base edges and surfaces (like higher order Spirals, Pcurves, Conical, Cylindrical, Place, (Degenerate) Toroidal, Spherical, BSpline, NIURBS surfaces, Surfaces of Linear Extrusion / Revolution) or Sweeps and Blends but also Clipping, 2D / 3D Boolean operations and many, many more. In the area of geometry there are many ways to represent geometry in a semantical manner other than the technical mesh / segmented approach. Maybe my understanding of GeoSPARQL is incorrect here but it would be great if we could represent 3D really in a semantical manner as an ontology. Not saying this is where we have to end up, with a fully complete ontology for 3D semantics; just saying this is a potential direction and in my perception often incorrectly seen as an impossibility.

[FransKnibbe]

Hi @peterrdf, I agree that it would be very nice to have multiple ways of defining geometry, and that an ontology for that would be welcome. It could be good for interoperability between different spatial knowledge domains. I just wonder why a separate ontology should be needed. Is there anything in GeoSPARQL that precludes extending the semantics of geometry?

[peterrdf]

Hi @FransKnibbe , maybe my misunderstanding of GeoSPARQL, but how could I define for example a simple Cylinder? I mean really semantically, not the approximation.

[FransKnibbe]

@peterrdf, defining a cylinder is currently not possible. At the same time, I don't think it is impossible to extend GeoSPARQL to have support for defining cylinders. That is my point: I agree that more semantics for geometry very welcome, but I think it would be easier to do that within the GeoSPARQL standard, than to devise a completely new ontology. GeoSPARQL seems like a good starting point to me.

[peterrdf]

I agree it would be possible to add Cylinders; my expectation is however that the more is added, the more we actually would describe implicitely an ontology and find reuse of properties, multiple inheritance and implicitely creating an ontology (in IFC and AP242 for example there are 200+ individual classes on this with strong interdependencies, compared to the 5-10 I currently count in WKT). I don't say this is the way to go, I just think creating an ontology for geometry in the same technology we use non-geometrical content queried by SPARQL would be a possible road. Also I think it is a conceptually different approach from extending the current capabilities in geometry, again not to say this is the way to go, just a possibility I see (and personally for me a very attractive and logical step forward :-) ).