RE: UCR issue: phrasing of CRS requirement(s)


On Thursday, May 21, 2015 4:23 PM 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.

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.

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



Received on Thursday, 21 May 2015 15:05:43 UTC