Re: Metadata: bounding boxes

Andrea,

The proposed update to GeoSPARQL does have some of the geometry roles that you mention as subproperties of hasGeometry, including hasEnvelope. ogeo:box is in the spirit of GeoRSS a shortcut property that expands to a hasGeometry property, although that relationship is not easy to specify in OWL. One could decide that ogeo:box refers to the hasEnvelope subproperty, or define a subproperty ogeo:bbox that does so. Eventually it makes sense, though to use the full form of a hasGeometry supbproperties to fully describe the role of a geometry in a feature. This allows, for example, alternative serializations such as asGML or asWKT.

Josh

> On Feb 21, 2017, at 8:49 AM, andrea.perego@ec.europa.eu wrote:
> 
> 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 <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 <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 <http://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 <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/ <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 <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 <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