- From: Svensson, Lars <L.Svensson@dnb.de>
- Date: Thu, 21 May 2015 15:05:12 +0000
- To: "Kerry.Taylor@csiro.au" <Kerry.Taylor@csiro.au>, "andrea.perego@jrc.ec.europa.eu" <andrea.perego@jrc.ec.europa.eu>, "janowicz@ucsb.edu" <janowicz@ucsb.edu>
- Cc: "Simon.Cox@csiro.au" <Simon.Cox@csiro.au>, "raphael.troncy@eurecom.fr" <raphael.troncy@eurecom.fr>, "eparsons@google.com" <eparsons@google.com>, "public-sdw-wg@w3.org" <public-sdw-wg@w3.org>
Kerry, On Thursday, May 21, 2015 4:23 PM Kerry.Taylor@csiro.au wrote: > RE axis order, > I know there is a great deal of frustrated experience and errors with this. > The thing is, with ontologies like Raphael's and with "linked data" (I mean RDF > instance data in any of its forms, including JSON-LD), > normally ordering is irrelevant as a description for each value is provided > (commonly called "self describing'). E.G. Have a look at "geo" I pointed at > before. http://www.w3.org/2003/01/geo/wgs84_pos wgs84_pos et al. are fine as long as you just deal with point coordinates. As soon as you start talking about bounding boxes etc. it turns _way_ more complicated. Even in simple settings we need to describe more than points. > It would not be impossible for us to decide that we need to define a literal > (string) encoding like WKT that is not self-describing (and we would need a > good reason to make up a new one, but perhaps this is the good reason). From > where I stand, I don't think we need to define a literal encoding. Once I got used to it, WKT is really great. One issue I had though, is that the BNF they give in the specification is really underspecified. E. g. it doesn't mention whitespace. I tried to create a validator from that BNF and gave up about half-way through... > But other than the latter case I really don't think we care about whether it's > lat/long or long/lat at all. Yes. > Of course, I am assuming the principle applies "While our primary goal is to > develop 5-star linked spatial data, we hope that our solutions for dicoverability > and linkability can also be applied to other spatial data on the Web. " from > https://www.w3.org/2015/spatial/wiki/BP_Principles . But we have not yet > adequately addressed that question, IMHO. > > Re CRS in general, > > Having said that, there have been some cases made in this conversation for > why an ontology like Raphael's is needed (possibly extended to work with > several other systems evident in our use cases that (possibly, I have not > checked) Raphael's cannot do). IMHO this > is a nice idea but well down the priority queue. I would be happier to go much > simpler, but in a way that does not *prevent* an arbitrary CRS being specified > with something like Raphael's ontology. We could show how it is done in our BP > doc, use Raphael's good work as an example, but not actually do it -- ie not > actually recommend any particular such CRS ontology nor CRS. > > Meanwhile, I am totally convinced by the discussion on the list that we need to > be able to explicitly refer to a CRS (mandatorily), but > that we *must* make it a trivial thing to do for both data publisher and data > consumer. +1 Lars
Received on Thursday, 21 May 2015 15:05:43 UTC