Re: Metadata: bounding boxes

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> 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
> 
>