Re: Issue-10 unresolved in meeting today

+1 to Linda's phrasing ..

Ed

On Thu, 25 Jun 2015 08:43 Peter Baumann <p.baumann@jacobs-university.de>
wrote:

> +1 as it is more technically motivated.
> -Peter
>
> On 06/25/15 09:23, Linda van den Brink 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
>
> --
> Dr. Peter Baumann
>  - Professor of Computer Science, Jacobs University Bremen
>    www.faculty.jacobs-university.de/pbaumann
>    mail: p.baumann@jacobs-university.de
>    tel: +49-421-200-3178, fax: +49-421-200-493178
>  - Executive Director, rasdaman GmbH Bremen (HRB 26793)
>    www.rasdaman.com, mail: baumann@rasdaman.com
>    tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882
> "Si forte in alienas manus oberraverit hec peregrina epistola incertis
> ventis dimissa, sed Deo commendata, precamur ut ei reddatur cui soli
> destinata, nec preripiat quisquam non sibi parata." (mail disclaimer, AD
> 1083)
>
>
>
> --

Ed Parsons
Geospatial Technologist, Google

Mobile +44 (0)7825 382263
www.edparsons.com @edparsons