Re: Best Practice for encoding spatial coverage

Hi all,

professional usefulness and scalability are not upfront opposites. Setting up
geo services for millions of objects is state of the art today.
It is about finding concepts that are correct & complete enough _and_ easy to
use. For the creators of such standards this is not an easy task ("making it
simple is difficult"), it requires to first understand concepts and
ramifications deeply, and _then_ find a simple, staged approach. But the value
is a standard that is useful to and adopted by the community.

my 2 cents,
Peter


On 06/19/15 17:00, Krzysztof Janowicz 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 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

-- 
Dr. Peter Baumann
 - Professor of Computer Science, Jacobs University Bremen
   www.faculty.jacobs-university.de/pbaumann
   mail: p.baumann@jacobs-university.de
   tel: +49-421-200-3178, fax: +49-421-200-493178
 - Executive Director, rasdaman GmbH Bremen (HRB 26793)
   www.rasdaman.com, mail: baumann@rasdaman.com
   tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882
"Si forte in alienas manus oberraverit hec peregrina epistola incertis ventis dimissa, sed Deo commendata, precamur ut ei reddatur cui soli destinata, nec preripiat quisquam non sibi parata." (mail disclaimer, AD 1083)