RE: Content negotiation of spatial linked data

Hi Josh and Andrea,

On Wednesday, July 20, 2016 7:00 PM, Joshua Lieberman [] 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 <>
> wrote:
> >
> > On 20/07/2016 17:54, Joshua Lieberman wrote:
> >> I’ve added a comment to the wiki about geometry serialization negotiation:
> >>
> >>

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

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

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