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

RE: UCR issue: phrasing of CRS requirement(s)

From: <Kerry.Taylor@csiro.au>
Date: Thu, 21 May 2015 14:22:53 +0000
To: <L.Svensson@dnb.de>, <andrea.perego@jrc.ec.europa.eu>, <janowicz@ucsb.edu>
CC: <Simon.Cox@csiro.au>, <raphael.troncy@eurecom.fr>, <eparsons@google.com>, <public-sdw-wg@w3.org>
Message-ID: <3CD3C8BBF0D87B4D8154C3978732049C50EB608F@exmbx05-cdc.nexus.csiro.au>
RE axis order, 
I know there is a great deal of frustrated experience  and errors with this.
The thing is, with ontologies like Raphael's and with "linked data" (I mean RDF instance data in any of its forms, including JSON-LD),
normally ordering is irrelevant as a description for each value is provided (commonly called "self describing'). E.G.  Have a look at "geo" I pointed at before. http://www.w3.org/2003/01/geo/wgs84_pos



It would not be impossible for us to decide that we need to define a literal (string) encoding like WKT  that is not self-describing (and we would need a good reason to make up a new one, but perhaps this is the good reason).  From where I stand, I don't think we need to define a literal encoding.

But other than the latter case I really don't think we care about whether it's lat/long or long/lat at all.


Of course, I am assuming the principle  applies "While our primary goal is to develop 5-star linked spatial data, we hope that our solutions for dicoverability and linkability can also be applied to other spatial data on the Web. "  from https://www.w3.org/2015/spatial/wiki/BP_Principles . But we have not yet adequately addressed that question, IMHO.

Re CRS in general,

Having said that, there have been some cases made in this conversation for why an ontology like Raphael's is needed (possibly extended to work with several other systems evident in our use cases that (possibly, I have not checked) Raphael's cannot do). IMHO this
is a nice idea but well down the priority queue. I would be happier to go much simpler, but in a way that does not *prevent* an arbitrary CRS being specified with something like Raphael's ontology. We could show how it is done in our BP doc, use Raphael's good work as an example, but not actually do it -- ie not actually recommend any particular such CRS ontology nor CRS.

Meanwhile, I am totally convinced by the discussion on the list that we need to be able to explicitly refer to a CRS (mandatorily), but
that we *must* make it a trivial thing to do for both data publisher and data consumer. 

Kerry 


> -----Original Message-----
> From: Svensson, Lars [mailto:L.Svensson@dnb.de]
> Sent: Thursday, 21 May 2015 6:44 PM
> To: Andrea Perego; Krzysztof Janowicz
> Cc: Cox, Simon (L&W, Highett); Raphaël Troncy; Taylor, Kerry (Digital,
> Acton); Ed Parsons; SDW WG
> Subject: RE: UCR issue: phrasing of CRS requirement(s)
> 
> Andrea,
> 
> On Wednesday, May 20, 2015 6:09 PM Andrea Perego wrote:
> 
> > Probably I'm mistaken, but I don't think Raphaël and Lars were
> > necessarily asking for a "full" RDF/OWL description of a CRS, but
> > rather of pieces of information (as axis order) that are useful for a
> > number of use cases, and that need to be accessible /.queryable via
> > SPARQL or, in general, with tools / applications not able to process
> > geospatial formats. I think this is very much in line with the goal
> of
> > enabling re-use of spatial data across platforms.
> 
> Yes, that is what I was looking for.
> 
> > Another possible reason to have a (partial) RDF description of a CRS
> > is to provide links to the available representations (Proj4, GML,
> WKT,
> > GeoJSON, etc.). Something like what you can get (in a human readable
> > presentation) from Spatial Reference - see, e.g.:
> >
> > http://spatialreference.org/ref/epsg/4326/

> 
> Hmm, yes sort of. Interesting to see that the axis order is not
> mentioned on that page. I keep coming back to that since I struggled a
> bit with axis order when converting the coordinates in our linked data
> service to WKT...
> 
> > This would enable software agents to know which are the available
> > formats, and to retrieve the one(s) they are able to consume.
> 
> Best,
> 
> Lars
> >
> >
> > On Wed, May 20, 2015 at 8:17 AM, Krzysztof Janowicz
> > <janowicz@ucsb.edu>
> > wrote:
> > > I agree with Simon here. There will always be Linked Data 'leaf
> > > nodes' that will not (and do not have to) be triplified. If I
> recall
> > > correctly, the GeoSPARQL group had similar discussions. In almost
> > > all cases (I can think of), for instance, having a full RDF
> > > serialization of a complex polyline feature does not add any value
> > > (compared to WKT). This is even not about Linked Data versus
> > > Semantic Web reasoning, it is simply about the added value (or the
> lack of it).
> > >
> > > Best,
> > > Krzysztof
> > >
> > >
> > > On 05/19/2015 10:30 PM, Simon.Cox@csiro.au wrote:
> > >>
> > >> Raphaël: how is 'semanticizing' the description of CRS helpful? As
> > >> Peter and I have shown there are existing XML-based services that
> > >> deliver the entire EPSG CRS dataset in fully structured form
> (which
> > >> covers the lat/lon vs lon/lat issue Lars). Given that these
> > >> services have reliable URIs (based on the EPSG identifiers),
> > >> contain links (to the component elements like CS, Datum, Axis,
> > >> etc), and are in an open format (GML/XML), we are already up
> > to
> > >> about 4 1/2-star linked data.
> > >>
> > >> I'm a big fan of RDF and OWL, partly because of the scalability
> and
> > >> flexibility, and tool support. But there are some boundaries over
> > >> which the value add of RDF is vanishingly small, particularly if
> some 'linked data'
> > >> that is already available. I question whether effort is wisely
> > >> spent here, compared with some other parts of the puzzle which are
> > >> much less evolved right now.
> > >>
> > >> Kerry raised the issue of scope, and suggested that the goal
> should
> > >> be n-star linked spatial data. I agree, but we need to be clear
> > >> that "linked data" != "semantic web with full reasoning", so need
> > >> to be careful about balance here.
> > >>
> > >> -----Original Message-----
> > >> From: Svensson, Lars [mailto:L.Svensson@dnb.de]
> > >> Sent: Tuesday, 19 May 2015 9:51 PM
> > >> To: Raphaël Troncy; Cox, Simon (L&W, Highett); Taylor, Kerry
> > >> (Digital, Acton); eparsons@google.com; janowicz@ucsb.edu
> > >> Cc: public-sdw-wg@w3.org
> > >> Subject: RE: UCR issue: phrasing of CRS requirement(s)
> > >>
> > >> On Tuesday, May 19, 2015 10:09 AM Raphaël Troncy wrote:
> > >>
> > >>>>   Thanks Kerry - that's essentially the way I see it, if by
> > >>>> "linked data representation" you are implying RDF. I would like
> > >>>> to ask those people advocating a new CRS encoding in RDF, what
> > >>>> this would be useful for?
> > >>>
> > >>> Well of course, this is a very "niche" usage, but typical use
> > >>> cases are for getting an explicit semantic description of how a
> > >>> CRS has been built so that you can, for example, query for all
> > >>> CRSs that use a specific Datum, or, more simply, ask for the EPSG
> > >>> identifier corresponding to the URI of a CRS, etc.
> > >>
> > >> Another case would be to get information about lat/long vs.
> long/lat.
> > >>
> > >> Best,
> > >>
> > >> Lars
> > >
> > >
> > >
> > > --
> > > Krzysztof Janowicz
> > >
> > > Geography Department, University of California, Santa Barbara
> > > 4830 Ellison Hall, Santa Barbara, CA 93106-4060
> > >
> > > Email: jano@geog.ucsb.edu
> > > Webpage: http://geog.ucsb.edu/~jano/ Semantic Web Journal:
> > > http://www.semantic-web-journal.net

> > >
> > >
> >
> >
> >
> > --
> > 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.
Received on Thursday, 21 May 2015 14:23:57 UTC

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