Re: Metadata: bounding boxes

Andrea,

Yes - if the literal range of ogeo:box can be typed, then different types could be supported. With GeoRSS, we tried for maximal simplicity in this shortcut formulation, so only allowed the one literal type.

Josh

> On Feb 21, 2017, at 11:29 AM, <andrea.perego@ec.europa.eu> <andrea.perego@ec.europa.eu> wrote:
> 
> Thanks, Josh.
> 
> If I understand correctly, :hasGeometry and its subproperties can be used to specify a geometry via the :Geometry class (and its subclasses) - basically, as it is done in GeoSPARQL. 
> 
> However, I wonder whether properties as ogeo:box can be used directly with WKT/GML/GeoJSON, or only with the syntax used in georss:box. 
> 
> In the former case, ogeo:box could be a kind of "shortcut" property, such as
> 
> a:SpatialThing :box "wkt string"^^gsp:wktLiteral .
> 
> is equivalent to
> 
> a:SpatialThing :hasEnvelope [ a :Envelope ; gsp:asWKT "wkt string"^^gsp:wktLiteral ] .
> 
> Cheers,
> 
> Andrea
> 
> ----
> 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: Joshua Lieberman [jlieberman@tumblingwalls.com]
> Sent: 21 February 2017 15:46
> To: PEREGO Andrea (JRC-ISPRA)
> Cc: rob@metalinkage.com.au; public-sdw-wg@w3.org
> Subject: 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 <mailto: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 <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