Re: Content negotiation of spatial linked data

Josh, all,

My comments inline.

On 23/09/2016 20:25, Joshua Lieberman wrote:
> Hi Frans,
>
> If only! There is no one standard for a list of numbers. Each language
> does it a little differently, and each runtime library is full of
> details for encoding types of numbers for particular hardware / firmware
> architectures.
>
> Beyond this, though, geometry is not just a list of numbers. The numbers
> are actually parameters for a geometric model of a real world feature.
> This is true for other aspects of reality, to be sure, but specific or
> even unique models are also required to connect numbers to each of those
> aspects (e.g. sensor models!). So there is a great deal of agreement on
> how to exchange the coordinates of a geometry, but each style of usage
> encodes the aspects of the model in a different language, paradigm or
> platform. They may also mangle the agreement, to be fair. GeoJSON is
> close but not identical to WKT. KML and GML also make changes (e.g.
> coordinate order). GeoSPARQL has an asWKT property which is not actually
> WKT but EWKT (including the CRS). This is easier to ingest into PostGIS
> directly but messes up discovery and managing first class geometry
> entities. Then there are times when a text string is appropriate, other
> when binary is better (WKT vs WKB). And by the way, ISO 8601 is not
> always sufficient to standardize time coordinate representation.

+1. I see the issue of geometry encoding as analogous to the CRS's one 
(and to the more general one of "providing data in multiple formats"). 
So, likewise, we shouldn't prevent people from using their own geometry 
encoding(s). What we could at most do, is to recommend they publish also 
in an encoding (to be decided) facilitating a wide re-use of geometry 
data (i.e., the equivalent, if any, of WGS84/CRS84 for CRSs).

Actually, we had to address this issue in the GeoDCAT-AP WG, as I 
explained in an earlier email 
(https://lists.w3.org/Archives/Public/public-sdw-wg/2015Jun/0167.html). 
We were not able to come up with 1 recommended encoding. Eventually, we 
decided for 2 equally recommended, namely, WKT and GML, whereas GeoJSON 
ranked 2nd.

Not great for interoperability, but I think this gives an idea of the 
difficulty to find an agreement on the encoding that (quoting Ed) "rules 
'em all".

A probably more reasonable approach is to recommend different encodings 
based on the use case - e.g.:
- will your geometry data be used in Web applications? Provide also GeoJSON
- will your geometry data be used in triple stores? Provide also WKT 
(AFAIK, triple stores have been supporting WKT for quite a while now, 
but not GeoJSON).

> It would be nice to encourage a strict  and correct asWKT serialization,
> but you know that the horses such as GeoJSON keep leaving the barn, so
> we’ll have to settle for clear and precise conversions. That leaves the
> possibility of content negotiation. It seems dangerous to me to
> negotiate not only the format of a response document but also the
> formats of components within that document as a separate media-type. So
> my preference is to stick with something like application/rdf+xml for
> overall documents and define an accept-extension for coordinate format,
> e.g. application/rdf+xml; geom=wkt
>
> I don’t think it would be a good idea to count on fetching raw
> coordinate strings by URL and managing them around the Web. We would be
> extending things enough to make geometries first-class entities that can
> be linked to by features, but also have a minimal set of other
> properties besides the coordinate string that identify the model the
> coordinates for which the coordinates are parametes and allow some
> discovery.

I see your point, Josh, but, considering the current situation, 
supporting HTTP conneg for geometry encodings (WKT, GeoJSON, GML, KML, 
etc.) would be already a great step, IMO, towards a wider re-use of 
geometry data. And the advantage is that this can be implemented without 
extending the current HTTP header specifications.

Of course, this does not solve the issue about the different flavours of 
WKT ("plain" WKT, PostGIS's EWKT, GeoSPARQL WKT) or GML (i.e., CRS 
specified with a URN or an HTTP URI - as in GeoSPARQL), unless we think 
of specific media types for each of them. Or, alternatively, the use of 
the already mentioned proposal for "profile-based" content negotiation, 
where the profile URI denotes the variant defined in a given spec (e.g., 
GeoSPARQL).

About geometry encoding in RDF graphs, instead of choosing the encoding 
to be used, it is probably better to include more than one. E.g., 
GeoSPARQL has :asWKT and :asGML: so why not using both? Of course, 
there's always the alternative of using geometry URIs instead, as 
Andreas pointed out earlier in this thread 
(https://lists.w3.org/Archives/Public/public-sdw-wg/2016Sep/0188.html).

Cheers,

-Andrea


> —Josh
>
>> On Sep 23, 2016, at 10:40 AM, Frans Knibbe <frans.knibbe@geodan.nl
>> <mailto:frans.knibbe@geodan.nl>> wrote:
>>
>> Hello Josh, all,
>>
>> Aren't geometry serializations relics of the past, when domain
>> standards were used to exchange spatial data? What if there is
>> agreement on a simple datatype for an array of coordinates? Then we
>> could use content negotiation for the entire document/dataset, not for
>> a part of it.
>>
>> I think a basic problem with serializations like GeoJSON, KML and GML
>> is that they are geography-centric constructs. In reality, spatialness
>> is just one aspect of reality, and geometry, like time, is just one of
>> the things you can encounter in a dataset.
>>
>> It seems to me that an commonly agreed datatype for geometry should be
>> our holy grail. Then we could use that in XML, JSON, CSV, HTML, or
>> whatever format happens to be in fashion.
>>
>> Regards,
>> Frans
>>
>> On 20 July 2016 at 17:54, Joshua Lieberman
>> <jlieberman@tumblingwalls.com <mailto:jlieberman@tumblingwalls.com>>
>> wrote:
>>
>>     I’ve added a comment to the wiki about geometry serialization
>>     negotiation:
>>
>>     https://www.w3.org/2015/spatial/wiki/Further_development_of_GeoSPARQL#Negotiate_geometry_serializations
>>     <https://www.w3.org/2015/spatial/wiki/Further_development_of_GeoSPARQL#Negotiate_geometry_serializations>
>>
>>     It seems the best idea may be to define a content type parameter
>>     for the available / desired serialization, but that would
>>     presumably need to be added to a linked spatial data API best
>>     practice.
>>
>>     —Josh
>>
>>
>

-- 
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 Monday, 26 September 2016 11:20:06 UTC