- From: Krzysztof Janowicz <janowicz@ucsb.edu>
- Date: Tue, 9 Feb 2016 07:20:10 -0800
- To: bergi <bergi@axolotlfarm.org>, Joshua Lieberman <jlieberman@tumblingwalls.com>, Maik Riechert <m.riechert@reading.ac.uk>
- Cc: public-sdw-comments@w3.org, Joan Masó <joan.maso@uab.cat>
> Yes, it doesn't make sense to represent the individual coordinate > numbers in RDF. And it also does not scale, e.g., if you would like to run a SPARQL endpoint. On 02/09/2016 02:33 AM, bergi wrote: > Thanks for the link. I will have a closer look at it later. > > Yes, it doesn't make sense to represent the individual coordinate > numbers in RDF. Using the @geometry property to map the geometry into > a literal like WKT or a stringified GeoJSON should be GeoSPARQL > compatible. > > Best, > bergi > > On 08.02.2016 15:56, 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 Webpage: http://geog.ucsb.edu/~jano/ Semantic Web Journal: http://www.semantic-web-journal.net
Received on Tuesday, 9 February 2016 15:20:44 UTC