RE: Metadata: bounding boxes

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


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