W3C home > Mailing lists > Public > public-sdw-wg@w3.org > June 2015

RE: Issue-10 unresolved in meeting today

From: Svensson, Lars <L.Svensson@dnb.de>
Date: Wed, 24 Jun 2015 16:18:40 +0000
To: Kerry Taylor <Kerry.Taylor@acm.org>, "public-sdw-wg@w3.org" <public-sdw-wg@w3.org>
Cc: Frans Knibbe <frans.knibbe@geodan.nl>, Alejandro Llaves <allaves@fi.upm.es>
Message-ID: <24637769D123E644A105A0AF0E1F92EF010D094BB1@dnbf-ex1.AD.DDB.DE>
Kerry,

On Wednesday, June 24, 2015 5:22 PM, Kerry Taylor wrote:

> I wonder whether I could explain my position expressed in the meeting today
> better in email. To me,
> 
> 1. It is a reasonable and much supported  requirement that CRSs need to be
> described (somehow,  and I leave this how open for the purpose of a
> requirement), and that a CRS can be referenced by a URI.  Hence Frans'
> proposal or something very similar works for me. That is,
> "There should be a best practice for publishing data about coordinate reference
> systems (CRS). It should be applicable to any 2D or 3D CRS, not only
> geographical reference systems. CRS descriptions should be referencable by
> HTTP URIs."
> We could take out the "by http URIs" I guess as that is a 'how' but that is so
> obvious I think it should be left in nevertheless. We could change "best
> practice" to "a way" or "a method"  and I am just as happy. For me, "data
> about" does not imply rdf, nor natural language text, nor any other form of
> description, but if it does to others,  I would be just as happy with "descriptions
> of" instead.

Works for me and I like the "descriptions of" since that is technology neutral. The important parts are description and referencability. I see this requirement as being related to but independent of 2. (below).

> 2. It is not so clear, and indeed hotly disputed, about whether spatial data on
> the web *must* reference a CRS. It might be that some CRS is assumed by
> default, but not
> explicitly referenced. It might be that the whole idea of a CRS is too difficult for
> non-experts and should be assumed away.

Well it *is* difficult for non-experts. I was lucky to get much help and support from some of the people on this list when I needed to understand how all the bits and pieces (ellipsoid, datum, axis order, ...) fit together and why they are important. OTOH I now know how important they are and given that we are not only talking about geographic CRSs but also custom ones (my computer is at (0,10): that is zero centimetres to the right and ten centimetres in front of me) at least in some cases the CRS must be specified for the data to make sense (or at least be interpreted properly).

> Number 1 above stands nevertheless
> for at least those cases where a CRS  *is* desired.  And we now have a
> separate requirement to discuss about whether it should be possible to
> implicitly refer to a default CRS ( issue-28).
> 
> My own opinion on 2 above, developed by watching the comments on this list
> and at Barcelona, is that we should try to make explicitly referencing a CRS
> both trivially easy and mandatory, so that it is explicit even if a beginner does
> not realise that it is there. This way we take advantage of the cultural copy-
> and-paste practice yet enable that culture to vary over time and space and
> application domain, ie getting it right most of the time for both publishers and
> consumers without even thinking about it.

Mandating an explicit reference does have the advantage that your data is not misinterpreted just because you omit the CRS (for whatever reason) and the consuming application reverts to the default CRS. This is a Good Thing (TM). OTOH it then really needs to be "trivially easy" to make that explicit and that might be really hard to achieve since you need to understand what a CRS is before you can specify which one you use (see above).

> Chris raised an interesting idea about using content negotiation to request a
> particular crs and getting whatever is asked for dynamically  ( I think that is
> what he meant). This sounds attractive to me ( but, not to get distracted, is in
> solution space, not requirement space, I think) and I would want to know that
> this is not going to be too much of a challenge for data publishers. But that is a
> topic for another day.

What would the requirement be?
> 
> Do you think we can resolve issue-10 next week?

We SHOULD try!

Best,

Lars
Received on Wednesday, 24 June 2015 16:19:10 UTC

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