RE: ACTION-249: Further work on BP8 (geometry)

Dear all,

Just an update on BP8 / ACTION-249 before today's call.

So far, I started drafting some examples to address the points outlined in BP8. They are very preliminary, and now under review by Linda, Jeremy and Payam. Anyway, if you would like to have a look at them, you can go here:

https://andrea-perego.github.io/sdw/bp/index.html#describe-geometry

The relevant examples are #19, #20 and #21. The added text is highlighted in yellow.

Meanwhile, I'm trying to come up with a possible revision to the BP8 text, to see if it is possible to provide some more precise guidance on how to do things.

Following the discussion during the last calls, as well as the London f2f (I was not there, but Jeremy kindly shared with me his "pub" notes), I thought to look at this from a slightly different perspective, and identify possible approaches based on the intended users, and how people are currently doing things.

Probably it is overly simplistic, but I'm keen to know if what follows makes any sense to you.

So, looking mainly at LD people and Web developers, I see three different approaches for publishing geometries on the Web, for which we have examples:

1. Use properties (as locn:geometry, geom:geometry, schema:point/polygon/box) allowing to specify directly geometries as literals (WKT, GML, GeoJSON, etc.)

2. Use geometry HTTP URIs, which can possibly return a more sophisticated (wrt #1) representation of the geometry - as in GeoSPARQL - and/or different geometry encodings

3. Use a more sophisticated (wrt #1) representation of the geometry, but without using URIs (i.e., using only blank nodes)

Option #1 is the most practical for Web developers (but probably also for LD people), it is easy to be implemented, and it can also be used for spatial queries. But to make this work, the geometry needs to be small.

Option #2 is fine for LD people (maybe less for Web developers). It can be used for geometries of any size, it allows the geometry to be linked to / re-used by other spatial things, and it does not require the geometry to be maintained in the same "place" of the data (Bill's use case). It may also be used to provide access to the geometry in different representations / encodings (e.g., via conneg or other mechanisms). On the other hand, implementing this solution requires expertise and resources.

Option #3 is frequently used (for sure more than #2) by LD people, but I'm not sure it is popular among Web developers. Implementing it is less difficult that option #2, but it is overly complex from a Web developer perspective, and makes the geometry less re-usable. 


Do you think this outline could be useful to structure the text of BP8?

Thanks!

Andrea

----
Andrea Perego, Ph.D.
Scientific / Technical Project Officer
European Commission DG JRC
Directorate B - Growth and Innovation
Unit B6 - Digital Economy
Via E. Fermi, 2749 - TP 262
21027 Ispra VA, Italy

https://ec.europa.eu/jrc/

----
The views expressed are purely those of the writer and may
not in any circumstances be regarded as stating an official
position of the European Commission.


________________________________________
From: Andrea Perego [andrea.perego@jrc.ec.europa.eu]
Sent: 18 January 2017 12:17
To: Ed Parsons
Cc: Linda van den Brink; W3C SDW WG - Public; Andreas Harth; Joshua Lieberman
Subject: Re: ACTION-249: Further work on BP8 (geometry)

Many thanks, Ed.

About point (3), I think one of the question is whether it would be
anyway useful to provide examples of existing approaches and the
relevant use cases.

For instance, for bboxes, we can show how this is done with schema:box
in Web pages and locn:geometry for GeoDCAT-AP metadata. GeoDCAT-AP
offers also an example of how to publish geometries in multiple formats
(WKT, GML, GeoJSON) along with the relevant dataset (so, not as
independent resources).

About the information to be included in the RDF representation of
geometries, we already have a number of examples.

For instance, Ordnance Survey basically includes just the geometry -
see, e.g.:

http://data.ordnancesurvey.co.uk/doc/geometry/37256-10

whereas GADM-RDF provides also a description of the available
serialisations:

http://gadm.geovocab.org/id/0/60/geometry

I think this is a useful information: by retrieving the RDF
representation I know whether my preferred serialisation format is
supported and how I can retrieve it.

I'm just thinking aloud, but other possible options may be:
- include the CRS, bbox, centroid, etc.
- provide an RDF description including the most used vocabularies to
facilitate re-use.

I'm actually not aware of any operational system doing the latter, but I
have been experimenting this in a prototype. The resulting RDF
representation of a point geometry is shown here:

https://github.com/andrea-perego/geoiri/blob/master/examples/point(0_0).rdf

This basically includes:
- links to and descriptions of the available serialisations
- the point represented with GeoSPARQL (WKT+GML), Basic Geo, Schema.org,
geo URI scheme and GeoHash, all connected with owl:sameAs to the main
geometry URI

Taking the example above, my understanding is that publishing RDF
representations of geometries includes, but it is not limited to,
filling the gaps / inconsistencies in existing RDF vocabularies, and may
require approaches to promote re-usability analogous to the idea of
providing geometries in multiple serialisations.

Cheers,

Andrea


On 18/01/2017 10:46, Ed Parsons wrote:
> Andrea,
>
> Thanks for your thoughts very useful, where you do suggest approaches in
> 1 and 2 I'm +1 As for 3 where we are less mature in our thinking and
> available approaches we need to just explain the situation and likely
> developments to resolve the issues e.g. Josh's work in the near future...
>
> Ed
>
>
> On Wed, 18 Jan 2017 at 10:22 Andrea Perego
> <andrea.perego@jrc.ec.europa.eu <mailto:andrea.perego@jrc.ec.europa.eu>>
> wrote:
>
>     Dear Linda, all,
>
>     In view of the relevant agenda item of today's call [1], I provide below
>     a summary of the discussions we had so far on how to publish geometries
>     on the Web. Apologies in advance for the long email.
>
>     @All, I kindly ask you to check if what reported here is correct. Any
>     comments & revisions are more than welcome.
>
>
>     1. Preferred geometry format(s)
>
>     BP8 includes already some guidelines, but based on some discussion
>     during the last f2f [2,3], it seems that more explicit recommendations
>     would be desirable. What follows is a tentative contribution based on
>     what I recall from our discussions.
>
>     The reference BP here is the general DWBP B14 principle of providing
>     data in multiple formats: https://www.w3.org/TR/dwbp/#MultipleFormats
>
>     Applied to geometries, this should ideally imply providing geometries in
>     the most used serialisations. However, this may not be always feasible,
>     so it is important to identify one or more preferred geometry
>     serialisations. One of the requirements here is that such serialisations
>     should be preferably Web-friendly. More importantly, we don't want to be
>     prescriptive and prevent people from publishing geometries in their
>     preferred serialisations. So, the recommendation should sound like:
>
>     "Publish geometries in any serialisation you like, but for re-usability
>     it is important that you make them available in format X [, Y, Z, ...]."
>
>     Most on the discussions we had on "preferred format(s)" were about two
>     possible candidates: WKT and GeoJSON. Both are widely used and
>     supported. GeoJSON is the most webby one, but also WKT is supported by
>     popular Web libraries (as OpenLayers and Leaflet). Moreover, WKT is also
>     supported by most triple stores - even those not supporting GeoSPARQL.
>
>     The main drawbacks with GeoJSON seem to be related to the fact that in
>     its current version it supports only one CRS - namely, CRS84 (i.e.,
>     WGS84, with lon/lat axis order) - see:
>     https://tools.ietf.org/html/rfc7946#section-4
>
>     WKT doesn't have this problem, and has other advantages - it's a very
>     compact literal form compared to GeoJSON (as well as other geometry
>     serialisations), it's case insensitive, and it has a corresponding
>     binary encoding (WKB).
>
>     There are however a number of issues:
>     - WKT is available in a number of flavours - e.g., the original WKT
>     format, the extended variant supported in PostGIS (EWKT) [2], the
>     GeoSPARQL variant
>     - The axis order is implemented inconsistently. For instance, in
>     PostGIS, by default it's lon/lat, irrespective of the CRS, whereas
>     GeoSPARQL requires the use of the axis order specified in the CRS
>
>     It has been pointed out that GML does not have the issues above, since
>     both CRS and axis order can be explicitly specified. However, my
>     understanding of the relevant discussion is that GML is not considered
>     webby enough, and it has limited support in Web / LD applications, tools
>     and platforms.
>
>     Trying to come to a conclusion, this is my personal understanding:
>
>     (a) We cannot avoid recommending GeoJSON as (one of) the preferred
>     geometry serialisation(s), because of its widespread use and support on
>     the Web. But with the caveat that it may not be suitable for all use
>     cases, due to the CRS issue.
>
>     (b) We need also a geometry serialisation not having the GeoJSON issues.
>     Between WKT and GML, the former seems to be definitely more suitable for
>     Web and LD applications. But in this case we need to decide which
>     variant should be recommended, and the rule about the axis order.
>
>
>     2. How to publish geometries on the Web
>
>     This point is of course related to the principle of "publishing
>     geometries for Web use", but also to the idea of making geometries a
>     "first-class citizen" on the Web.
>
>     I think that issue here boils done to whether geometries should be
>     published along with the relevant spatial things, or independently.
>
>     There was some discussion in the last f2f [2,3] about the two options of
>     denoting geometries with blank nodes or URIs. Linda provided an example
>     from Ireland, where the rationale about using blank nodes is that the
>     data provider would like people to link to their spatial things, and not
>     to the geometries.
>
>      From this perspective, using URIs for geometries should be based on use
>     cases where people would like to link instead to the geometry itself.
>     Which, I think, is basically related to the question whether / in which
>     cases a geometry is "re-usable".
>
>     A possible use case is when you need to link to some "authoritative"
>     geometry - e.g., an administrative boundary maintained by an
>     institutional agency. Using the relevant URI would ensure not only that
>     I'm referring always to the official and up to date version of the
>     geometry, but I implicitly provide provenance information.
>
>     This is not different from linking to and re-using data maintained by
>     external organisations - e.g., as in the work illustrated by Bart in
>     Lisbon, where fire depts. re-use cadastral data not by copying them
>     locally, but linking to them.
>
>     So, IMO, in BP8 we should mention both approaches, clarifying the
>     different use cases they are addressing. And we can also mention that,
>     depending on the solution used, the publication of geometries in
>     multiple serialisations is different - e.g., for geometry URIs, HTTP
>     conneg can be used.
>
>
>     3. Geometries in RDF
>
>     The main points of discussion seem have been focussed on the following
>     topics:
>
>     (a) Recommended vocabularies and/or best practices for using them
>
>     (b) Which information should be included in the RDF representation of a
>     geometry
>
>     In general, both relate to Josh's work on the revision of GeoSPARQL.
>     However, as far as existing vocabularies are concerned, my understanding
>     is that the only consolidated agreement we have is the use of Basic Geo
>     for point geometries. For other geometry types, bboxes, centroids, etc.
>     we suggest a number of options. The question is whether this is enough,
>     or we should instead provide some more specific recommendations. I can
>     try to collect a number of examples from the reference vocabularies, if
>     this may be helpful.
>
>     About point (b), there was some discussion during the last f2f [2,3],
>     but I'm not sure an agreement was reached. One point quite controversial
>     from the very beginning is whether the RDF representation should include
>     the CRS separately from the geometry specification (this can be very
>     much dependent on how a geometry is modelled). Another issue was about
>     linking a geometry to related geometries (which seems to imply the use
>     of URIs for geometries).
>
>     I think here it would be crucial to have real-world examples as a
>     starting point, and possibly suggest how the can be improved.
>
>
>     Thanks, and sorry again for the long mail.
>
>     Meet you later
>
>     Andrea
>
>     ----
>     [1]https://lists.w3.org/Archives/Public/public-sdw-wg/2017Jan/0067.html
>     [2]https://www.w3.org/2016/12/15-sdw-minutes
>     [3]https://www.w3.org/2016/12/16-sdw-minutes
>     [4]http://postgis.net/docs/ST_GeomFromEWKT.html
>
>     --
>     Andrea Perego, Ph.D.
>     Scientific / Technical Project Officer
>     European Commission DG JRC
>     Directorate B - Growth and Innovation
>     Unit B6 - Digital Economy
>     Via E. Fermi, 2749 - TP 262
>     21027 Ispra VA, Italy
>
>     https://ec.europa.eu/jrc/
>
>     ----
>     The views expressed are purely those of the writer and may
>     not in any circumstances be regarded as stating an official
>     position of the European Commission.
>
> --
>
> *Ed Parsons *FRGS
> Geospatial Technologist, Google
>
> Google Voice +44 (0)20 7881 4501 <tel:%2B44%20%280%2920%207881%204501>
> www.edparsons.com <http://www.edparsons.com/> @edparsons
>

--
Andrea Perego, Ph.D.
Scientific / Technical Project Officer
European Commission DG JRC
Directorate B - Growth and Innovation
Unit B6 - Digital Economy
Via E. Fermi, 2749 - TP 262
21027 Ispra VA, Italy

https://ec.europa.eu/jrc/

----
The views expressed are purely those of the writer and may
not in any circumstances be regarded as stating an official
position of the European Commission.

Received on Wednesday, 15 February 2017 15:19:48 UTC