Re: Best Practice for encoding spatial coverage

2015-06-19 17:00 GMT+02:00 Krzysztof Janowicz <janowicz@ucsb.edu>:

>  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.
>
>  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
>

I hope and believe that making choices on good design principles (such as
separation of concerns and polymorphism) will help us in making
recommendations. Although it might appear that the need for simplicity on
one hand and sound theoretical underpinnings on the other are conflicting,
I think that taking them both into full account will reward us with the
best solutions and prevent reinvention of wheels.

In a sense, this also relates to a subject we discussed in the last
meeting: What is the intended audience of the BP deliverable? Is it data
providers only or data consumers too? A suggestion was to focus on data
providers. I am afraid that if data consumers are left out of scope too
much the best practices will not be as solid as they could be.

Greetings,
Frans



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


-- 
Frans Knibbe
Geodan
President Kennedylaan 1
1079 MB Amsterdam (NL)

T +31 (0)20 - 5711 347
E frans.knibbe@geodan.nl
www.geodan.nl
disclaimer <http://www.geodan.nl/disclaimer>