Re: Best Practice for encoding spatial coverage

There is an element in that balance of choosing the appropriate relationships in order to be “referential”. Inheritance may be too strict a constraint in many cases. Classification or provenance can sometimes prove more useful, leveraging existing work and yet retaining simplicity. 

Josh

> On Jun 19, 2015, at 11:00 AM, Krzysztof Janowicz <janowicz@ucsb.edu> wrote:
> 
> Hi Josh,
> 
>> 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.
> 
> You are making an interesting point here and I agree with your observation of said tendency. IMHO, the challenge is to strike the right balance between models that can address the needs and flexibility needed by domain experts, critical applications, and so forth, and the need to scale semantic annotations to millions of webpages. I hope that the use cases will help us finding a measure for what that 'right' balance is.
> 
> Best,
> Krzysztof
> 
> P.s. really sorry that I can barely contribute to the group due to the current meeting time.  
> 
> On 06/19/2015 06:13 AM, Joshua Lieberman wrote:
>> 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 <mailto: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 <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 <http://schema.org/>). There is also the related issue #113 that I encourage you to watch: https://github.com/schemaorg/schemaorg/issues/113 <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/ <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 <mailto:raphael.troncy@eurecom.fr> & raphael.troncy@gmail.com <mailto:raphael.troncy@gmail.com>
>>> Tel: +33 (0)4 - 9300 8242
>>> Fax: +33 (0)4 - 9000 8200
>>> Web: http://www.eurecom.fr/~troncy/ <http://www.eurecom.fr/%7Etroncy/>
>>> 
>> 
> 
> 
> -- 
> Krzysztof Janowicz
> 
> Geography Department, University of California, Santa Barbara 
> 4830 Ellison Hall, Santa Barbara, CA 93106-4060 
> 
> Email: jano@geog.ucsb.edu <mailto:jano@geog.ucsb.edu>
> Webpage: http://geog.ucsb.edu/~jano/ <http://geog.ucsb.edu/~jano/>
> Semantic Web Journal: http://www.semantic-web-journal.net <http://www.semantic-web-journal.net/>