Re: [ExternalEmail] RE: Represent spatial data as Linked Data & easy to consume in the web stack

2016-02-09 5:55 GMT+01:00 <Simon.Cox@csiro.au>:

> To clarify what I meant here:
>
> 1.      Don’t encode geometry as triples in RDF – it isn’t used for
> reasoning. Yes, spatial computations are needed, but this isn’t an RDF
> task. So geometry in RDF should be carried in some embedded encoded
> literals that your spatial engine understands.
>
> 2.      OTOH, it is fine to encode geometry using JSON native support for
> arrays.
>
I agree with the first statement, but I have some doubts about this second.

While it is true that JSON is very popular nowadays, I think we should be
careful with recommending that geometry encodings should be JSON based for
all eternity. A while ago, XML was all the craze, which is why GML is XML
based. Current thinking is that JSON is better than XML (much to the
chagrin of some geodata providers, who have just about finished their
efforts of making their data available as XML). But can we be sure
somewhere in the future a new format won't be invented that is better than
JSON and that everyone will want? Somehow it feels better to me not to base
standards on fashions too much. I think everyone agrees that it makes sense
to regard geometry as an ordered collection of coordinates in some
reference system. Would it be possible to standardise such a definition as
something more fundamental than an encoding in XML or JSON? Would it be
possible to agree on a datatype for geometry?

Viewing geometry as a basic datatype was discussed at the face to face
meetings in Amersfoort, but it did not reach much of a conclusion. What I
mean with datatype is a common definition that is highly interoperable
between data formats and programming languages. Numbers (-12.777) or text
strings ("Banana") are very general and interoperable data types and in
fact they are some sort of arrays too. Can geometry be like that? In
relational database systems and triple stores, geographic geometry has more
or less standard datatypes too, based on WKT. Geometric data are typically
stored in a column that has 'geometry' as a data type. Can we try do have
something similar on the web?

If an agreed upon datatype definition for geometry exists, it could
eventually find its way into Javascript and JSON by that route. And into
all the great formats and languages that humankind has not invented yet...

Regards,
Frans




> 3.      When lifting data from JSON to RDF, or round-tripping between
> JSON & RDF, don’t just naïvely annotate JSON to turn it into JSON-LD
> because you must treat the geometry (at least) separately.
>
> Simon
>
>
>
> *From:* Simon.Cox@csiro.au [mailto:Simon.Cox@csiro.au]
> *Sent:* Tuesday, 9 February 2016 11:55 AM
> *To:* janowicz@ucsb.edu; jlieberman@tumblingwalls.com;
> m.riechert@reading.ac.uk
> *Cc:* bergi@axolotlfarm.org; public-sdw-comments@w3.org; joan.maso@uab.cat
> *Subject:* [ExternalEmail] RE: Represent spatial data as Linked Data &
> easy to consume in the web stack
>
>
>
> While I agree with this in the RDF layer, JSON has native support for
> (nested) arrays, which is what GeoJSON and GeoJSON applications quite
> reasonably take advantage of. It would be silly not to encourage this.
>
>
>
> The problem comes in applying a single transformation rule to lift all
> JSON data into RDF. The boundary between what makes sense natively, and
> what should use an embedded microformat, occurs in different places in the
> different data models.
>
>
>
> Simon
>
>
>
> *From:* Krzysztof Janowicz [mailto:janowicz@ucsb.edu <janowicz@ucsb.edu>]
> *Sent:* Tuesday, 9 February 2016 11:23 AM
> *To:* Joshua Lieberman <jlieberman@tumblingwalls.com>; Maik Riechert <
> m.riechert@reading.ac.uk>
> *Cc:* bergi <bergi@axolotlfarm.org>; public-sdw-comments@w3.org; Joan
> Masó <joan.maso@uab.cat>
> *Subject:* Re: Represent spatial data as Linked Data & easy to consume in
> the web stack
>
>
>
> Much more sensible to keep the coordinate data in a literal such as WKT,
> which is the GeoSPARQL approach and also the one that Joan came up with.
>
>
>
>
> Yes, I strongly agree.
>
>
>
> On 02/08/2016 06:56 AM, Joshua Lieberman wrote:
>
> You might take a look at the report here
> <https://portal.opengeospatial.org/files/?artifact_id=64595> by Joan
> Maso. It seems the basic problem is that taking the JSON structure of
> GeoJSON and translating it directly into JSON-LD and hence into RDF leads
> to the same problem that GeoSPARQL dealt with — that representing
> individual coordinate numbers in RDF doesn’t make much sense. Much more
> sensible to keep the coordinate data in a literal such as WKT, which is the
> GeoSPARQL approach and also the one that Joan came up with.
>
>
>
> Josh
>
>
>
> On Feb 8, 2016, at 9:01 AM, Maik Riechert <m.riechert@reading.ac.uk>
> wrote:
>
>
>
> Ok that makes more sense, but I still don't understand how the "@geometry"
> thing is supposed to work. It's again a custom solution that would have to
> be supported by implementations, right? But I guess that's the point you're
> making, namely that linked data should be added to GeoJSON in a defined and
> constrained way and that a GeoJSON document should not be forced to
> suddenly become a full JSON-LD document. It will be hard to convince
> everyone that "properties" is the right container for all linked data, but
> the more ideas the better.
>
> Cheers
> Maik
>
> On 08/02/2016 13:36, bergi wrote:
>
> Hi Maik,
>
> The Leaflet example uses the proposed GeoJSON structure:
>
>
> https://raw.githubusercontent.com/zazukoians/geojson-ld/gh-pages/us-states.json
>
> The info box up right shows the N-Triples of the current state, but the
> example contains only data for Alabama.
>
> But you are right, I should add this to the description page. I was a
> little bit in a hurry, to publish this document in time for the group
> meeting.
>
> Best,
> bergi
>
> On 08.02.2016 13:35, Maik Riechert wrote:
>
> Hi,
>
> I don't really understand what you're doing there. I think it would help
> if you could add some actual GeoJSON examples in your description page.
>
> Thanks
> Maik
>
> Dear all,
>
> We are currently looking for ways to represent spatial data as Linked
> Data and at the same time make sure that it's easy to consume in the web
> stack. After some discussions I've come up with a proposal to embed
> JSON-LD in GeoJSON and vice versa.
>
> Seehttp://zazukoians.github.io/geojson-ld/  for description and example
> code. If you have any comments post it here or create an issue on
> Github:https://github.com/zazukoians/geojson-ld
>
> Best,
> bergi
>
>
>
>
>
>
>
>
>
> --
>
> 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
>
>