W3C home > Mailing lists > Public > public-sdw-wg@w3.org > September 2016

RE: Content negotiation of spatial linked data

From: Svensson, Lars <L.Svensson@dnb.de>
Date: Thu, 22 Sep 2016 17:32:23 +0000
To: Joshua Lieberman <jlieberman@tumblingwalls.com>, Andrea Perego <andrea.perego@jrc.ec.europa.eu>
CC: SDW WG Public List <public-sdw-wg@w3.org>, Andreas Harth <harth@kit.edu>
Message-ID: <24637769D123E644A105A0AF0E1F92EF010D284BDA@dnbf-ex1.AD.DDB.DE>
Hi Josh and Andrea,

On Wednesday, July 20, 2016 7:00 PM, Joshua Lieberman [mailto:jlieberman@tumblingwalls.com] wrote:

Sorry for arriving so late to this discussion...

> I’m not sure one has to choose. Sdwgeo geometries are intended to have URI’s and
> can be requested along with features or separately in a SPARQL request.

Yes, assuming that there is a SPARQL endpoint available.

> Particular
> serializations of both the feature and geometry data can be negotiated either way, I
> think. If one request a feature with contentType application/rdf+xml;
> geomdata=“WKTLiteral”, then the geometry if requested / returned should include an
> asWKT.

While I agree that this would be very handy indeed, I don't think http allows that kind of syntax in the Accept-header, at least not for all media types and certainly not for application/rdf+xml.

> If it isn’t returned, then no harm done, and a further request can be made on
> one or more of the geometry properties of the feature, requesting the same
> contentType.

This I don't understand. Could you provide an http request-response  sequence that shows how that should work?

> So I think this will work as long as providers of linked spatial data support it and we
> agree the best practice is to use this ontology or at least the serialization part of it for
> spatial data in RDF.
> It is another, but also significant issue how a linked spatial data API should work —
> whether it should have a provision for returning features with or without geometries
> when one makes a request to the feature URL.

I fully agree, but think that we need another mechanism to handle that. To me, this is an example of why we need application profiles (identified by URIs!) and a mechanism to perform content negotiation on profiles. And I'm glad to see that this will be a topic for the workshop in Amsterdam in November this year.



> > On Jul 20, 2016, at 12:44 PM, Andrea Perego <andrea.perego@jrc.ec.europa.eu>
> wrote:
> >
> > On 20/07/2016 17:54, Joshua Lieberman 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.
> >
> > Thanks, Josh. I wonder whether this is another case where profile-based content
> negotiation can play a role.
> >
> > On the other hand, there might be an alternative solution to deal with this issue,
> e.g., by using URIs for geometries. In such a case, you fetch the RDF, and then apply
> content negotiation on the geometry URI to get WKT, GML, KML, GeoJSON, etc. So,
> basically, you get to the geometry in two steps.
> >
> > This relates to the WG discussion on "geometries as first-class citizens", and count
> some implementations - as those I outlined in an earlier email [1]. It may be worth
> assessing them wrt to the general issue of serving spatial (linked) data in multiple
> formats.
> >
> > Cheers,
> >
> > Andrea
> >
> > ----
> > [1]https://lists.w3.org/Archives/Public/public-sdw-wg/2016May/0099.html

> >
> >>
> >> —Josh
> >

Received on Thursday, 22 September 2016 17:32:59 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:31:26 UTC