- 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>
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. Best, Lars > > 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