- From: Maik Riechert <m.riechert@reading.ac.uk>
- Date: Tue, 9 Feb 2016 09:31:18 +0000
- To: Simon.Cox@csiro.au, janowicz@ucsb.edu, jlieberman@tumblingwalls.com
- Cc: bergi@axolotlfarm.org, public-sdw-comments@w3.org, joan.maso@uab.cat
- Message-ID: <56B9B1E6.50007@reading.ac.uk>
Personally I wouldn't care about roundtripping or conversion to RDF. I rather see the biggest advantage in being able to establish common meaning for GeoJSON feature metadata (= mostly "properties") so that I can interpret/display that in a robust way. And if you don't care about geometry (for RDF), then the whole issue gets a lot easier. Of course, that assumes the typical client-side way of just loading GeoJSON in a browser, understanding the format anyway, and in addition having a bit more semantics to play with. Cheers Maik Am 09.02.2016 um 04:55 schrieb 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. > > 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] > *Sent:* Tuesday, 9 February 2016 11:23 AM > *To:* Joshua Lieberman <jlieberman@tumblingwalls.com > <mailto:jlieberman@tumblingwalls.com>>; Maik Riechert > <m.riechert@reading.ac.uk <mailto:m.riechert@reading.ac.uk>> > *Cc:* bergi <bergi@axolotlfarm.org <mailto:bergi@axolotlfarm.org>>; > public-sdw-comments@w3.org <mailto:public-sdw-comments@w3.org>; Joan > Masó <joan.maso@uab.cat <mailto: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/ <http://geog.ucsb.edu/%7Ejano/> > Semantic Web Journal:http://www.semantic-web-journal.net
Received on Tuesday, 9 February 2016 09:31:54 UTC