W3C home > Mailing lists > Public > public-sdw-wg@w3.org > June 2015

Re: Best Practice for encoding spatial coverage

From: Krzysztof Janowicz <janowicz@ucsb.edu>
Date: Fri, 19 Jun 2015 08:00:48 -0700
Message-ID: <55842EA0.4090600@ucsb.edu>
To: <public-sdw-wg@w3.org>
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 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
>>
>> 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 <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
Webpage: http://geog.ucsb.edu/~jano/
Semantic Web Journal: http://www.semantic-web-journal.net
Received on Friday, 19 June 2015 15:01:24 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:31:17 UTC