RE: Metadata: bounding boxes

Hi, Rob.

Your reference to GeoDCAT-AP reflects the initial solution, which does not correspond exactly to the final one, which I summarised here:

https://lists.w3.org/Archives/Public/public-sdw-wg/2015Jun/0167.html


As I mentioned, the adopted solution highlighted the lack of an agreed way in RDF of specifying that a geometry is a bounding box (or a centroid, etc.). And it doesn't seem things have changed at the moment.

I stumbled (again) upon this issue while drafting examples for BP8 (ACTION-249) I shared last week [1], and now available on my fork of the sdw repo:

https://andrea-perego.github.io/sdw/bp/index.html#describe-geometry


E.g., in Example 20, I tried to provide an example of a feature (a building) associated with a detailed geometry, along with its bbox and centroid. I used schema:box for the bbox, whereas for the centroid I was not able to find anything better than geo:lat / geo:long.

I think it would be beneficial to at least align how we use the existing properties, based on the contexts of use.

For instance, for specific properties for bboxes we have two candidates, schema:box and georss:box, whereas other more generic properties, as locn:geometry, geo:geometry and georss:where, are able to say that the geometry is actually a bbox only when using a GML literal. A (possible) drawback of schema:box and georss:box is that they do not supported geometry encodings as WKT/GML, so their re-use in spatial queries may be limited (but I may be wrong).

About centroids, no smart idea.

Just thinking aloud, but I wonder whether this can be a way forward for bboxes:

-          We use schema:box in schema.org-based examples

-          We use georss:box for RDF-based examples, possibly complementing it with WKT/GML if the example requires it

Cheers,

Andrea

---
[1] https://lists.w3.org/Archives/Public/public-sdw-wg/2017Feb/0376.html


----
Andrea Perego, Ph.D.
Scientific / Technical Project Officer
European Commission DG JRC
Directorate B - Growth and Innovation
Unit B6 - Digital Economy
Via E. Fermi, 2749 - TP 262
21027 Ispra VA, Italy

https://ec.europa.eu/jrc/


----
The views expressed are purely those of the writer and may
not in any circumstances be regarded as stating an official
position of the European Commission.

From: Rob Atkinson [mailto:rob@metalinkage.com.au]
Sent: Tuesday, February 21, 2017 4:41 AM
To: Joshua Lieberman; Rob Atkinson
Cc: SDW WG Public List
Subject: Re: Metadata: bounding boxes

Thanks Josh

that looks sensible - and is more explicit than the POLYGON WKT examples.

what is the canonical ogeo namespace and what status does it have?

Is the ^^xsd:string datatype required, and useful?

And, are we going to use this consistently in all the SDW outputs?

rob

On Tue, 21 Feb 2017 at 14:21 Joshua Lieberman <jlieberman@tumblingwalls.com<mailto:jlieberman@tumblingwalls.com>> wrote:
Use georss simple — <georss:box>42.943 -71.032 43.039 -69.856</georss:box>
which is equivalent to

<georss:where>

      <gml:Envelope>

         <gml:lowerCorner>42.943 -71.032</gml:lowerCorner>
         <gml:upperCorner>43.039 -69.856</gml:upperCorner>
      </gml:Envelope>

</georss:where>
and is the same in ogeo (core geosparql2)

ogeo:box  “”"42.943, -71.032, 43.039, -69.856”””^^xsd:string

—Josh

On Feb 20, 2017, at 9:57 PM, Rob Atkinson <rob@metalinkage.com.au<mailto:rob@metalinkage.com.au>> wrote:

Hi

trying to deal with an open issue re BP, in an example in QB4ST

https://www.w3.org/2015/spatial/track/issues/132


been reviewing practices, including BP, w.r.t. defining an bounding spatial envelope

BP points to geoDCAT - which is kind of loose on the subject:
https://joinup.ec.europa.eu/node/141755


but the issue does suggest:
The provisional proposal is to represent the geometry as a GML literal (gml:Envelope), as specified in [GEOSPARQL<http://www.opengeospatial.org/standards/geosparql>]. However, this is an issue that requires further investigation, both in the framework of the INSPIRE MIG and in relevant standardisation activities.

the only example in the  BP document uses schema.org<http://schema.org/> "box"

for all these microformats, then using rules to entail equivalent alternative forms from a given choice is going to be ugly...

NB My own preference is for ttl not json-ld in examples - its far easier to read, and i think JSON-LD is unlikely to be easily readable by either JSON or RDF communities - maybe a ttl equivalent should be provided for each example- which would reinforce the message that using RDF data model makes sense even if you want to pass data around using json serialisation.

Rob A