Re: Metadata: bounding boxes

Simon,

You're right, of course. I just looked quickly at the namespaces used by previous bp's. The question it raises though is what OGC should use for ontology namespaces and whether it should be the same as for other schemes. OAB will talk a bit about this today although it won't work for you timezone-wise unfortunately. Topic for Location Powers?

Josh

> On Feb 21, 2017, at 00:55, <Simon.Cox@csiro.au> <Simon.Cox@csiro.au> wrote:
> 
> Josh –
>  
> You may recall that the issue of namespaces came up in the OAB.
> I raised it specifically to address the lurking issue here, which is use of a temporary namespace for things that really need persistent identifiers, particularly where they refer to schema or ontology components and are likely to appear in data documents. I think I recall that the OAB agreed that we could use ‘permanent’ URIs prior to the actual documentation reaching the standards phase. Wearing my OGC-NA hat I would certainly recommend that.
>  
> So even if the URL for the RDF artefact is https://bp.schemas.opengeospatial.org/17-045/1.0/ the URIs inside it should start http://www.opengis.net/ont/ogeo or similar.
>  
> Simon
>  
> From: Joshua Lieberman [mailto:jlieberman@tumblingwalls.com] 
> Sent: Tuesday, 21 February, 2017 14:49
> To: Rob Atkinson <rob@metalinkage.com.au>
> Cc: SDW WG Public List <public-sdw-wg@w3.org>
> Subject: Re: Metadata: bounding boxes
>  
> 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/ 
>  
> 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> 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> 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]. 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 "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
>  
>  
>  
>