Fix Location JSON Schema #76
Description
Name: James Brown
Affiliation: GSA/data.gov
Type of issue: Schema - Location class
Issue: The Location JSON Schema references string IRI's for the main fields (bbox, centroid, and geometry). This is wrong. These need to be actual values. The descriptions themselves seem to have been placeholders. The documentation can be seen here.
Recommended change(s):
The geometry field contains this detail:
Definition: Associates a spatial thing [SDW-BP] with a corresponding geometry.
The range of this property (locn:Geometry) allows for any type of geometry specification.
E.g., the geometry could be encoded by a literal, as WKT (geosparql:wktLiteral [GeoSPARQL]),
or represented by a class, as geosparql:Geometry (or any of its subclasses) [GeoSPARQL].
That is a lot of options. Too many to be handled well and implemented in mapping tools by data.gov.
However, in order to allow data to pass through in current and future standards, I propose the following schema standard:
- Allow any string; micromanaging the WKT and GML standards is a losing battle. Document clearly in data.gov examples, and denote that an invalid spatial information represented in a string will not result in rejection, just lack of spatial representation (searching and map view).
- Allow any JSON: this will continue to support GeoJSON format, which isn't spelled out in the standard but is mentioned in the SHACL schema. This also supports backwards compatibility.