Re: Content negotiation of spatial linked data

Hello Josh,

Please see my response inline...

On 23 September 2016 at 20:25, Joshua Lieberman <
jlieberman@tumblingwalls.com> 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.
>

But is there a reason there could not be such a standard?

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

Sometimes geometry can just be a list of numbers, and only that list can
have use and meaning. But in most cases additional data are needed. Which
goes for text strings too. In their naked from, they are ordered arrays of
characters. But for many applications it is good to know things like the
language and the script too. However, content negotiation is not used to
select particular types of text. Neither is it used to choose between, say,
different ways of expressing a temperature, a date.time or a monetary
value. It seems to me that the mechanism of content negotiation applies to
a data set or document in its entirety. Geometry typically is only a part
of a data set or document.


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

Is one horse leaving the barn sufficient reason to give up on trying to
agree on a basic datatype for geometry? Perhaps the horses would return if
there is a demonstrably good data type that is supported by both geospatial
and web communities?


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

That could be comparable to language negotiation for text strings. But I
wonder if it is really necessary. That many languages exist is a fact of
life which can not be changed. I hope the existence of several geometry
formats is something that *can* be changed. It would be a natural
consequence of hitherto isolated domains growing, meeting and adapting on
the shared information system that is the web.

Regards,
Frans

>
> 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.
>
> —Josh
>
> On Sep 23, 2016, at 10:40 AM, Frans Knibbe <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>
> 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
>>
>> 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
>>
>
>
>