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]
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<mailto: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<http://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<mailto:jano@geog.ucsb.edu>

Webpage: http://geog.ucsb.edu/~jano/


Semantic Web Journal: http://www.semantic-web-journal.net