Property coordinates

[dvh]

I think we might want to support different coordinate notations. Imagine we have the following GeoJSON in our non-LD response:

geom: {
  geoJson: {
    type: "MultiPolygon",
      coordinates: [...]

A non-schema LD response could be:

ogcgs:hasGeometry: {
   ogcgs:asWKT: "..."

Where geom has become ogcgs:hasGeometry and as there is no geoJson property anymore, it only supports a ogcgs:asWKT string. Perhaps we could do the same for the schema.org extension, for example:

sgeo:hasLocation: {
  sgeo:coordinates: {
    sgeo:asWKT: "...",
    sgeo:asGeoJSON: [...],
    sgeo:asWGS84: [...],
    sgeo:asEPSG28992: [...]

So you could support multiple coordinate systems/notations on a single location.

Any thoughts on this?

[liekeverhelst]

Hi @dvh, thanks, yes this makes sense for the developers. So you need a construction that allows you to say more about the format of the coordinates. The snippet above creates a blank node, and this we should avoid if possible. The alternative is to create a class for the coordinates, and attach properties to that. This is exactly what is done in GeoSparql (class Geometry), and if we want to do it "right" we could copy that. I hesitate a bit, do we really need it in the schema.org exension..? This data will not be used by the SE (search engines) for sure. Could you not better mark up with pieces of GeoSparql in addition to the schema.org stuff that is strictly meant for the SE? More generally spoken: what data model should we absolutely give to the SE in order to make them crawl and index the info correctly?

[cportele]

I have concerns about this, at least the CRS-related parts.

asWKT and asGML in GeoSPARQL are about the format. In both asWKT and asGML you can already specify the CRS, so you could already use that to express coordinates in multiple CRS for a location.

asWGS84 and asRDnew are about the CRS. But what would the format be? WKT, GeoJSON, GML, etc? And what if the information in the WKT specifies a different CRS then the asXXX suggests?

I.e., if we want to propose support for two orthogonal dimensions (CRS, representation) then we would need to take this into account in the design, but not use asWKT and asRDnew which only specify one dimension but are mute about the other dimension.

Conclusion: There are formats that already support explicity stating the CRS (WKT, GML) and there are formats that only support a single CRS (GeoJSON, KML). I would avoid including CRS names in property names.

[dvh]

@liekeverhelst, @cportele agree. I think WKT is the nicest solution then. So, this also means we can serialize the value of the WKT to generate an URI for it? That seems like an easy solution to ignore blank nodes :-)

And perhaps, as WKT is a string value, it's easier for schema.org and search engines to provide backwards compatibility (like we might end up that the schema itself doesn't change, but the current location could also contain WKT). But that's up to the community of course.

[liekeverhelst]

@dvh yes you can generate a URI based on the value of the WKT! @cportele I will change hasLocation into " location". Thanks for the comments so far! The JSON-LD implementation of all this is here.

[dirkx]

I think this approach is useful. However at some point developers may find it easier (as the complexity rises) to meddle with the URL -- i.e. treat one path element, query string or path-fragment as a 'parameter' and expect http://foo/bar/1234 to exist in parallel to http://foo/bar/1234/asWGS84, etc, etc./