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

Issue-10 unresolved in meeting today

From: Kerry Taylor <Kerry.Taylor@acm.org>
Date: Thu, 25 Jun 2015 01:21:37 +1000
Message-Id: <18939F57-8998-4465-9D07-CAAC2A591D5A@acm.org>
Cc: Frans Knibbe <frans.knibbe@geodan.nl>, Alejandro Llaves <allaves@fi.upm.es>
To: "public-sdw-wg@w3.org" <public-sdw-wg@w3.org>

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.

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

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.

Do you think we can resolve issue-10 next week?

Kerry

> On 24 Jun 2015, at 10:47 pm, Frans Knibbe <frans.knibbe@geodan.nl> wrote:
> 
> 
> 
> 2015-06-24 13:57 GMT+02:00 <chaals@yandex-team.ru>:
>> Regrets...
>>  
>> FWIW, I think it must be possible to add a URL identifying CRS. It would be nice to have a machine-readable formalism in which to express them, failing which, several, but that isn't as urgent a requirement, and we can expect them to evolve...
>>  
>> For example, being able to identify e.g. "cartesian", "polar", "lat/long", "altitude", "time", underlying topology (sphere, spheroid, apartment block, shopping centre, railway network, planetary system), etc are things that might be in a first version, or we might only discover we need after 3 years of wrestling unsuccessfully with hacks on top of a system we thought was good enough, or might prove unnecessary.
> 
> Does this mean you can live with the currently proposed phrasing of the requirement? Note that the requirement says there should be a standard for publishing CRS data, but it does not say those data should be complete descriptions of the CRS. This leaves open the option for a best practice of supplying only a few key elements of the CRS, and for evolution on consensus on what those key elements might be. 
> 
> Regards,
> Frans
> 
>>  
>> A skeleton for best practices looks reasonable enough to start filling in and checking whether it is in fact what we needed.
>>  
>> cheers
>>  
>> 23.06.2015, 14:22, "Kerry Taylor" <kerry.taylor@acm.org>:
>>> SDWWG participants,
>>> The next meeting of the Spatial Data on the Web Working Group will be held 
>>> 24 June 2015 13:00 GMT
>>>  
>>> Main Agenda:
>>> (Please follow the links below in preparation for the meeting)
>>> Use Cases and Requirements ISSUE-10 Best phrasing for CRS requirements
>>> Best Practices Skeleton (see wiki)
>>>  
>>> Dialin instructions and further details are given here:https://www.w3.org/2015/spatial/wiki/Meetings:Telecon20150624
>>>  
>>> —Kerry & Ed (Chairs)
>>>  
>>  
>>  
>> --
>> Charles McCathie Nevile - web standards - CTO Office, Yandex
>> chaals@yandex-team.ru - - - Find more at http://yandex.com
>>  
> 
> 
> 
> -- 
> Frans Knibbe
> Geodan
> President Kennedylaan 1
> 1079 MB Amsterdam (NL)
> 
> T +31 (0)20 - 5711 347
> E frans.knibbe@geodan.nl
> www.geodan.nl
> disclaimer
> 
Received on Wednesday, 24 June 2015 15:22:13 UTC

This archive was generated by hypermail 2.3.1 : Friday, 2 September 2016 12:03:03 UTC