Re: Metadata: bounding boxes

Great discussion - this really illustrates the BP challenge for
interoperabilty. From my perspective, the technical merits of the solution
need to be matched against the consensus position of both the SDW group,
and the wider community.  So I'll encourage this to get to a plenary vote
on agreed best practice and consistent usage,

Rob


On Wed, 22 Feb 2017 at 03:46 Joshua Lieberman <jlieberman@tumblingwalls.com>
wrote:

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