Re: Best Practice for encoding spatial coverage

This immediately raises a larger issue that we should discuss in the next call. There is clearly a common if implicit concept of a geographic bounding box that is expressed in a number of more or less different representations and encodings according to a range of authorities. The least formal authorities may have an aura of community mandate and accessibility, but they also rely if only implicitly, on the more formal definitions. For example, schema:box says nothing about the actual CRS that the included point coordinates assume, nor does it define handed-ness, nor how to treat crossing international date line and ambiguities deriving from that about which bounding box to assume from a pair of points. On the other side, the gml and iso bounding box / envelope definitions go into great detail to resolve these ambiguities and are also likely to remain stable definitions for far longer than the comparatively free-wheeling and reference-less schema.org <http://schema.org/> contributions. 

The question is be considered is whether the Best Practices principle will be to select more or less authoritative, formal, and stable versions of common concepts, if available. The question recognizes that there is a real tendency in the linked data vocabulary arena to prefer re-invented wheels that look "sui generis" but often simply mask their dependence on the definition of existing wheels. Case in point: GeoShape properties are almost identical to georss:simple properties that themselves are an exact and explicit encoding of gml geometries defined in terms of ISO geometries, yet there is no explicit evidence of this at schema.org <http://schema.org/>.

I suggest that we want to avoid this tendency. 

Josh

> On Jun 19, 2015, at 7:41 AM, Raphaël Troncy <raphael.troncy@eurecom.fr> wrote:
> 
> Dear all,
> 
>> ex:myDataset
>> dcterms:spatial ex:myExtent .
>> 
>> ex:myExtent
>> a dcterms:Location ;
>> schema:box "50 4 52 6" .
> 
> This solution is indeed simple and I personally like it (although I would prefer the comma separated syntactic version.
> 
> Note, however, that the property https://schema.org/box is still very weakly adopted by the community (range of 10-100 domains) which means that this property is at risk (in future developments of schema.org). There is also the related issue #113 that I encourage you to watch: https://github.com/schemaorg/schemaorg/issues/113
> 
> I think that it is also worth to list in the BP document the pointer provided by Andrea, the GeoDCAT-AP profile, https://joinup.ec.europa.eu/node/139283/ and the 3 possible values of the locn:geometry property (geosparql wktLiteral POLYGON, gml envelope encoded in XML, geojson)
> Best regards.
> 
>  Raphaël
> 
> -- 
> Raphaël Troncy
> EURECOM, Campus SophiaTech
> Multimedia Communications Department
> 450 route des Chappes, 06410 Biot, France.
> e-mail: raphael.troncy@eurecom.fr & raphael.troncy@gmail.com
> Tel: +33 (0)4 - 9300 8242
> Fax: +33 (0)4 - 9000 8200
> Web: http://www.eurecom.fr/~troncy/
>