W3C home > Mailing lists > Public > public-sdw-wg@w3.org > February 2017

Re: Metadata: bounding boxes

From: Joshua Lieberman <jlieberman@tumblingwalls.com>
Date: Mon, 20 Feb 2017 22:48:55 -0500
Message-Id: <608B92D8-83CF-4BEE-88DA-2A4FE0396EC8@tumblingwalls.com>
Cc: SDW WG Public List <public-sdw-wg@w3.org>
To: Rob Atkinson <rob@metalinkage.com.au>
Rob,

As soon as I can get a BP draft posted to OGC pending, an OGC namespace will be able to be assigned, something like
https://bp.schemas.opengeospatial.org/17-045/1.0/ <https://bp.schemas.opengeospatial.org/17-045/1.0/> 

> On Feb 20, 2017, at 10:40 PM, Rob Atkinson <rob@metalinkage.com.au> wrote:
> 
> 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
>> 
>> 
> 
Received on Tuesday, 21 February 2017 03:49:30 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 21 February 2017 03:49:31 UTC