GeoJSON literals for GeoSPARQL

[situx]

I have extended the Geometry Extension section of the GeoSPARQL specification to include a definition for a GeoJSON literal.
The ontology has also been extended by a geo:asGeoJSON property and a geo:geoJSONLiteral.

I had the following considerations:

• I chose to represent GeoJSON using a GeoJSON literal and not using the rdf:json relation because other serializations of geometries in JSON exist, for example ESRIJSON, TopoJSON, or even pure JSON files with lat/lon geocoordinates attached. Whether or not to leave it this way is a matter of discussion
• GeoJSON literals do not allow the definition of a CRS in the literal as opposed to WKT and GML as the GeoJSON standard only allows one CRS (WGS84) to be used
• GeoJSON literals are defined by the Geometry Object of the GeoJSON specification, e.g. {"type":"Point","coordinates":[-83.38,33.95]}
• An empty literal is equivalent to the statement {"geometry":null}
  However, how do we define equivalences for POINT(EMPTY), POLYGON(EMPTY) etc.? Is this necessary?
  Should we define an empty Point as {"type":"Point","coordinates":[]} a.s.o. ?
• Requirement definitions currently do not contain a number as we might modify the numbering later on

I was not sure whether it is needed to extend the RDFS Entailment section.
In my opinion, we could just reuse the Geometry class definitions of SimpleFeatures which were used for defining the WKTLiterals.
But I am open to any other suggestions.

[dr-shorthair]

Fixes #1

[FransKnibbe]

It seems funny to me that the GeoJSON serialisation is only applicable to geometries that happen to use CRS84. OK, it is mentioned in the documentation. But the ontology itself does not prohibit erroneous usage.
One solution I can think of is to add a subclass of geometry that has CRS84 as a fixed CRS, e.g. geo:Crs84Geometry, and make the serialisation applicable to only that class.

Secondly, shouldn't there be a reference to the GeoJSON specification that should be used (ideally a URI) and the exact version of that specification?

[situx]

Hi Frans,

the reference given in the specification is [RFC 7946] https://tools.ietf.org/html/rfc7946
Do you mean to add this reference to the ontology specification?
Whether to add a new class which enforces CRS84, I would leave that open for discussion.
I currently cannot think of an optimal solution.

[FransKnibbe]

Hi Timo,

Yes, I think it is a good idea to add a reference to the applicable specification to the ontology. Perhaps rdfs:seeAlso is an appropriate property to use if we want to do that?

[nicholascar]

1. please could the proposed datatype geo:geoJSONLiteral be a subPropertyOf the new rdf:JSON datatype, as proposed in JSON-LD 1.1?

2. I wonder about all this WGS84 stuff. I'm no fan of locking in a single CRS and thus I have problems with GeoJSON. Perhaps we should provide both a JSON format with CRS unspecified and GeoJSON that is CRS locked. If we don't indicate how to generalise these things in GeoSPARQL, who else will?

[dr-shorthair]

It seems funny to me that the GeoJSON serialisation is only applicable to geometries that happen to use CRS84. OK, it is mentioned in the documentation.

I'm afraid that is a feature of GeoJSON.

There was proposal to allow CRS to be indicated in GeoJSON , but the developers were strongly of the opinion that it was best to limit it to the common case seen in most web-mapping applications and platforms, which were exploding in popularity at the time GeoJSON was designed. It was targeted at a distinct market that was judged to be unable and unwilling to go into the details of CRS, and not at professional geographers or cartographers or geodesists. It is all history now - GeoJSON is what it is.

Other JSON encodings might be developed which don't have those limitations, potentially as supersets of GeoJSON, but those should not be called 'GeoJSON'.

[nicholascar]

Other JSON encodings might be developed which don't have those limitations, potentially as supersets of GeoJSON, but those should not be called 'GeoJSON'.

Yes, what to do for a GeoJSON-like encoding of data within OGC APIs that use CRSes other than WGS84? I've used a GeoJSON-like format in my DGGs APIs and made up a "crs" property...

[FransKnibbe]

Frankly, I am not a fan of GeoJSON either. I have a hard time imagining why anyone would want to use it. Sure, JSON is a very handy format to use on web pages. But JSON-LD seems much more useful. I think JSON-LD could be even more useful for use with spatial data if GeoSPARQL were to have a proper full geometry model (see issue 42)

As it stands, I don´t think we can speak of a GeoJSON serialisation of a GeoSPARQL geometry. It can only serialize a subset of geometries. Hence the suggestion to actually define that subset. But in order to do that it would be good to have a separate CRS property for geometry (see issue 31).

[nicholascar]

I don´t think we can speak of a GeoJSON serialisation of a GeoSPARQL geometry.

I think we can, as long as there's a description of how the data is "downscaled" into the lesser content format of GeoJSON. So, the representation a. only works for WGS84 geometries and b. looses semantics of properties so that any properties defined in RDF just become key/value pairs in the GeoJSON with no property definitions, no explicit datatypes etc.

I think we should provide this downscaling mapping at the very least to indicate what you loose when you use GeoJSON.

In my OGC API implementations, I apparently must use GeoJSON but I have semantic content in the DB so I have to do this downscaling!

[FransKnibbe]

@nicholascar: good to point out the possible loss of information when RDF data are exported to GeoJSON. If GeoJSON support is added to GeoSPARQL, the reverse should also be well thought out: What happens when GeoJSON literals are imported into an RDF storage system / graph store? GeoSPARQL implementers will have to try to make sense of geometry properties in GeoJSON, and loss of information can be incurred in that direction too.

It seems to me that GeoJSON support could place a heavy burden on implementers, with a danger of different implementers choosing different solutions. This in turn makes me wonder if we can't place GeoJSON support in a separate module, so that supporting it becomes more optional.

I think my main concern with support for GeoJSON literals is that it might impede further development (extension) of the geometry class in GeoSPARQL.

[nicholascar]

What happens when GeoJSON literals are imported into an RDF storage system / graph store?

Well there are currently no GeoSPARQL rules about how to handle any of the GeoSPARQL literals (WKT or GML). There are no ontology conversion functions specified in ontology code. Any functions doing things with the literals, like spatial indexing, are implementation-specific i.e. StarDog perhaps performs some sort of GDAL indexing of WKT & GML literals. So I don't think we - ontology designers - have to worry about this. We just state that GeoJSON literals are a microformat in GeoSPARQL and any handling is implementation specific.

If someone wanted to mapp GeoJSON literals to semantic content then that would be a matter for application node, not GeoSPARQL ontology rules.

I will be doing something similar with DGGS literals: the ontology doesn't know anything about the DGGS literal content: handling those is also a job for application code, even if they have GeoSPARQL functions specified for them.

--

We have plenty of lossy literals in Semantic Web for precedence here. Essentially any microformat that isn't understood by an ontology. This would include custom identifier properties that contain structured information as recommended for use in SKOS. So SKOS doesn't know anything about the internals of the identifier literals...

[situx]

I have a question especially concerning OGC API Features.
In the CRS Extension of OGC API Features (http://docs.opengeospatial.org/DRAFTS/18-058.html#crs-query) we face a similar problem.
It is stated in section 6.3.3.2. Features and Feature resources:
"GeoJSON normatively supports WGS 84 (without height: CRS84; with height: CRS84h), but the "prior arrangement" provision allows other coordinate systems to be used."
What is this prior arrangement provision and may we do a similar approach here?

[nicholascar]

Approved for this to be added to the ontology as long as this and other literal types can also be added to a register of literals

[situx]

I changed the RDFS Entailment section to use classes of the GeoJSON vocabulary which is used in GeoJSON-LD (https://geojson.org/geojson-ld/)
However, this vocabulary does not define a Geometry class, only classes for {Multi}Point,{Multi}LineString,{Multi}Polygon.
I would suggest to use the GeoJSON vocabulary but to set all Geometry classes of the GeoJSON vocabulary as subclasses of sf:Geometry.
I am not sure if this is a perfect solution, but it might do.

[situx]

After today's discussion I removed the RDFS entailment section part and checked the empty geometry literal which is now defined only as {"geometry":null}.
In my view the change request is therefore ready to be merged and I am looking forward to a second reviewer.

[dr-shorthair]

It should be

:geoJSONLiteral rdfs:subClassOf rdf:JSON .

:geoJSONLiteral and rdf:JSON are rdfs:Datatype; they are not owl:DatatypeProperty.
There is no rdf:json property, so you can't say :asGeoJSON rdfs:subPropertyOf rdf:json .

https://www.w3.org/TR/json-ld11/#the-rdf-json-datatype

[situx]

Thanks @dr-shorthair it is now corrected

[mperry455]

Are we sure that :geoJSONLiteral should be subclass of rdf:JSON?
rdf:JSON has some rules about canonical representation (no extra whitespace, keys ordered lexicographically, etc.)
https://www.w3.org/TR/json-ld/#the-rdf-json-datatype
I don't know if we want to require geoJSON strings to match these rules.

[situx]

Good point. Even though the literal would just include two keys, in my opinion key ordering is not necessary. But I wonder how others think about it?

[mperry455]

I suggest that we remove rdfs:subClassOf rdf:JSON to avoid the canonicalization requirements of rdf:JSON. gmlLiteral is not a subClassOf rdf:XMLLiteral for this same reason.

[situx]

I removed the subclass relation for now. If this needs further discussion then we may still do so tomorrow

[mperry455]

Thanks Timo. Looks good.

[nicholascar]

Good pickups Simon & Matt: I had assumed we would want :geoJSONLiteral rdfs:subClassOf rdf:JSON . but if you foresee issues there, we don't have to. I guess the spirit of GeoSPARQL is that information about those literal microformats is elsewhere so users will just have to know all about GeoJSON (and not necisarily rdf:JSON) as discussed in the last teleconference.

[andrea-perego]

This is just to report that the adoption of this newly defined datatype is being considered in GeoDCAT-AP (see SEMICeu/GeoDCAT-AP#4).

Actually, the only concern we have is that the GeoJSON datatype may be dropped or changed in the final version of GeoSPARQL - we are going to release the new version of GeoDCAT-AP shortly, so we cannot wait until then.

About the context:

GeoDCAT-AP is a profile of the W3C DCAT vocabulary used across Europe to support a DCAT-compliant representation of INSPIRE / ISO 19115 metadata. Some more details are also available in the GeoDCAT-AP OGC Discussion Paper: http://www.opengis.net/doc/dp/GeoDCAT-AP

[nicholascar]

the only concern we have is that the GeoJSON datatype may be dropped or changed in the final version of GeoSPARQL

It won't be. Everyone wants it included so the only issues are around the datatype formalisms like the conversation above re alignment with rdf:JSON etc. So use it with confidence

[mathib]

note/question: is it legal to define subdatatypes in domain ontologies used for reasoning? I always imagined that it is not allowed as there's no rdfs:subDatatypeOf relation... I used the OWL profilechecker which renders errors when using rdfs:subClassOf on datatypes "Datatype IRI also used as Class IRI"). My guess is that it's theoretically allowed (e.g. as done in the RDF file describing RDF terminology for rdf:JSON rdfs:subClassOf rdfs:Literal), but not encouraged in domain ontologies as that might confuse reasoning engines (similar as users are not encouraged to directly feed the RDF files describing RDFS, RDF, OWL, etc. to a reasoning engine).