use GeoSPARQL (WKT, GML) for geometries

[VladimirAlexiev]

@avillar @rob-metalinkage @peterrdf (and cc @nataschake)
I'll split this topic from #1 since it's crucial.

https://github.com/ogcincubator/chek-profiles/blob/master/cityjson/twobuildings.city.ttl shows geometries converted to triples (down to individual vertices and individual coordinates).

• I believe that's the wrong way to do geometry. A similar approach is used in IfcOwl (though using lists of blank nodes), and pretty much nobody uses it because it's too complicated.
• The right way is to use GeoSPARQL opaque literals
  • 1.0 supports WKT, GML. For CityGML (XML) source, the best way is to convert to geo:asGML "..."^^geo:gmlLiteral
  • 1.1 also supports KML, GeoJSON. For CityJSON source, the best way is to convert to geo:asGeoJSON "..."^^geo:geoJSONLiteral
• The benefit of GeoSPARQL literals is that semantic repositories handle them specially in geospatial indexes, so you can use fast "magic predicates" for the topological relations (eg sf:Within).

Looking at https://dataset-dl.liris.cnrs.fr/rdf-owl-urban-data-ontologies/Ontologies/CityGML/3.0/core,
I think that CityGML ties up into GeoSPARQL geometries, eg

• core:ImplicitGeometry.relativeGeometry has range gmlowl:AbstractGeometry
• https://schemas.opengis.net/gml/3.2.1/gml_32_geometries.rdf
  shows that gmlowl:AbstractGeometry rdfs:subClassOf geo:Geometry
  (http://www.opengis.net/ont/geosparql#Geometry)

Cheers!

[rob-metalinkage]

Hi

There are several aspects to this.. and its a topic we should discuss further and decide how to future proof our solution.

If we have CityJSON and we want to map it to a common model to make it explicit how it relates to any other information, we have several choices:

1. Don't - leave information in current silo-specific form and abandon ambitions to integrate it without custom software
2. Embed extra information inside every data packet to explain what it is (semantically annotate instance data) - this is unlikely to be achievable and there is no standard way available to do this.
3. Semantically annotate the schema using the JSON-LD standard
4. Use some other mapping approach - e.g. R2RML
5. Create an ad-hoc mapping approach

The challenge here is that the expressivity of JSON-LD as a mapping is insufficient to general complex microformats embedded in RDF - like WKT.

So in general we have a "semantic uplift" to an intermediate ontology, which can then be mapped with another standard (SHACL) to a target ontology.

Note that a future version of GeoSPARQL will probably define the granular entries needed, and entailment rules and functions to convert to and from other microformats - WKT, GML - and possibly the GeoJSON JSON schema - but will be unlikely to directly support CityGML's approach to vertex topology.

Note this is not intended as a run-time capability - but a way to specify the actual semantic mapping in a way which can be tested.

We expect to be able to test multiple approaches, and demonstrate equivalence - i.e. multiple input schemas or variations, and multiple mapping languages or software tools - and the goal of this repository is to test, demonstrate and share the resources necessary to validate appropriate profiles (subsets which we want to map to a target).

The CHEK profiles will be profiles of various sources to extract information needed to process validation rules. Sources could be CityJSON, INSPIRE, IFC etc and mappings will be partial, extensible and testable.

[VladimirAlexiev]

@rob-metalinkage I'm looking at this from a practical point of view: for geometries in semantic data to be workable, they have to be GeoSPARQL literals.

• what's the "CityGML approach to vertex topology"? I assumed that it's an application of GML so uses GML geometries.
• I've had some struggles to convert INSPIRE PLU and XPlanung GML to RDF with gmlLiteral geometries, and now I know how to do it with SPARQL Anything and XSPARQL.
• GeoSPARQL 1.1 supports GeoJSON.
• It is possible to capture JSON literals with a JSON-LD context, see https://w3c.github.io/json-ld-syntax/#json-literals. Despite the Warning, it works.
  • They are converted to "..."^^rdf:JSON and it's only a matter of retyping to geo:geoJSONLiteral. I posted how to "retype" rdf:JSON to geo:geoJSONLiteral? w3c/json-ld-syntax#425

an intermediate ontology, which can then be mapped with another standard (SHACL) to a target ontology.

Hmm, seems to me such conversion will be difficult.
And is unnecessary if we can capture the requisite pieces of XML/JSON as literals.