Re: Issue-10 unresolved in meeting today

I wasn’t present in the discussions yesterday, but a requirement as worded by Linda makes a lot of sense to me.

Clemens

> On 25 Jun 2015, at 09:23, Linda van den Brink <l.vandenbrink@geonovum.nl> wrote:
> 
> Hi all, 
> 
> What if we turn the phrasing around a bit. (as I suggested yesterday in the IRC channel, but this may have been missed)
> 
> Then, the requirement is: to be able to reference a CRS with a URI, and to get useful information about the CRS when you dereference that URI.
> 
> This implies a method for describing CRSs. 
> 
> I believe this phrasing is closer to Ed's point, at least as I understood it yesterday. 
> 
> Linda
> 
> -----Oorspronkelijk bericht-----
> Van: Svensson, Lars [mailto:L.Svensson@dnb.de] 
> Verzonden: woensdag 24 juni 2015 18:19
> Aan: Kerry Taylor; public-sdw-wg@w3.org
> CC: Frans Knibbe; Alejandro Llaves
> Onderwerp: RE: Issue-10 unresolved in meeting today
> 
> 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 Thursday, 25 June 2015 08:13:17 UTC