Re: Issue-10 unresolved in meeting today

So the next proposal could be

"There should be a best practice for referencing a CRS with a HTTP URI, and
to get useful information about the CRS when that URI is dereferenced."?

With the 'best practice' bit subject to replacement by whatever comes out
of the discussion in the "Use of the word 'standard' in the UCR document"
thread.

Regards,
Frans





2015-06-25 10:19 GMT+02:00 Svensson, Lars <L.Svensson@dnb.de>:

> +1 from me, too, also to http URIs
>
> /Lars
>
> *** Lesen. Hören. Wissen. Deutsche Nationalbibliothek ***
> --
> Dr. Lars G. Svensson
> Deutsche Nationalbibliothek
> Informationsinfrastruktur und Bestanderhaltung
> Adickesallee 1
> D-60322 Frankfurt am Main
> Telefon: +49-69-1525-1752
> Telefax: +49-69-1525-1799
> mailto:l.svensson@dnb.de
> http://www.dnb.de
>
>
> > -----Original Message-----
> > From: Andrea Perego [mailto:andrea.perego@jrc.ec.europa.eu]
> > Sent: Thursday, June 25, 2015 9:58 AM
> > To: Peter Baumann
> > Cc: Linda van den Brink; Svensson, Lars; Kerry Taylor;
> public-sdw-wg@w3.org;
> > Frans Knibbe; Alejandro Llaves
> > Subject: Re: Issue-10 unresolved in meeting today
> >
> > +1 also from me.
> >
> > Moreover, I would suggest we refer explicitly to "HTTP URIs".
> >
> > Andrea
> >
> > On Thu, Jun 25, 2015 at 9:42 AM, 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)
> > >
> > >
> > >
> >
> >
> >
> > --
> > Andrea Perego, Ph.D.
> > Scientific / Technical Project Officer
> > European Commission DG JRC
> > Institute for Environment & Sustainability
> > Unit H06 - Digital Earth & Reference Data
> > Via E. Fermi, 2749 - TP 262
> > 21027 Ispra VA, Italy
> >
> > https://ec.europa.eu/jrc/
> >
> > ----
> > The views expressed are purely those of the writer and may
> > not in any circumstances be regarded as stating an official
> > position of the European Commission.
>



-- 
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 <http://www.geodan.nl/disclaimer>

Received on Thursday, 25 June 2015 09:35:44 UTC