Coordinates to RDF doesn't work

pietercolpaert commented 8 years ago

Take for instance this example:

{
  "@context": {
    "geojson": "http://ld.geojson.org/vocab#",
    "Feature": "geojson:Feature", 
    "features": {
        "@id": "geojson:features", 
        "@container": "@set"
      }, 
      "title": "http://purl.org/dc/terms/title", 
      "coordinates": {
        "@id": "geojson:coordinates",
        "@container" : "@list"
      }, 
      "type": "@type", 
      "description": "http://purl.org/dc/terms/description",
      "properties": "geojson:properties", 
      "geometry": "geojson:geometry", 
      "FeatureCollection": "geojson:FeatureCollection", 
      "LineString": "geojson:LineString",
      "gtfs": "http://vocab.gtfs.org/terms#",
      "stop": {
          "@id": "gtfs:Stop",
          "@type": "@id"
      }
    },

    "@id" : "http://example.org/shapes/shape1",
    "type": "FeatureCollection", 
    "features": [
      {
        "type": "Feature",
        "properties": {
          "description": "Torhout - Lichtervelde",
          "stop": [ "http://irail.be/stations/NMBS/008891314","http://irail.be/stations/NMBS/008892205"]
        },
        "geometry": {
        "type": "LineString", 
        "coordinates": [
          [
            3.1057405471801753,
            51.064216229943476
          ],
          [
            3.1056976318359375,
            51.063434090307574
          ]
        ]
      }
    } 
  ]
}

Converted to RDF triples, this gives

<http://example.org/shapes/shape1> <http://ld.geojson.org/vocab#features> _:b0 .
<http://example.org/shapes/shape1> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://ld.geojson.org/vocab#FeatureCollection> .
_:b0 <http://ld.geojson.org/vocab#geometry> _:b1 .
_:b0 <http://ld.geojson.org/vocab#properties> _:b2 .
_:b0 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://ld.geojson.org/vocab#Feature> .
_:b1 <http://ld.geojson.org/vocab#coordinates> "3.105697631835938E0"^^<http://www.w3.org/2001/XMLSchema#double> .
_:b1 <http://ld.geojson.org/vocab#coordinates> "3.105740547180175E0"^^<http://www.w3.org/2001/XMLSchema#double> .
_:b1 <http://ld.geojson.org/vocab#coordinates> "5.106343409030757E1"^^<http://www.w3.org/2001/XMLSchema#double> .
_:b1 <http://ld.geojson.org/vocab#coordinates> "5.106421622994348E1"^^<http://www.w3.org/2001/XMLSchema#double> .
_:b1 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://ld.geojson.org/vocab#LineString> .
_:b2 <http://purl.org/dc/terms/description> "Torhout - Lichtervelde" .
_:b2 <http://vocab.gtfs.org/terms#Stop> <http://irail.be/stations/NMBS/008891314> .
_:b2 <http://vocab.gtfs.org/terms#Stop> <http://irail.be/stations/NMBS/008892205> .

These coordinates are not usable in this form as I have no idea which lon and lat has to be used together to form a coordinate

pietercolpaert commented 8 years ago

Read some closed issues and came across this earlier comment by @lanthaler: https://github.com/geojson/geojson-ld/issues/28#issuecomment-52029939

The problem consists of the @list not being able to be wrapped. The error thrown by the playground:

Error: JsonLdException
List of lists detected in property "coordinates" (near [[{"@value":3.1057405471802},{"@value":51.064216229943}],[3.1056976318359,51.063434090308]]).

sgillies commented 8 years ago

Yes, it's a known issue. RDF applications are going to have to treat the coordinates as a blob, like it was imagery or audio. I can't see any way around that. I also can't see any benefit to exploding a complex multipolygon into triples.

pietercolpaert commented 8 years ago

We'd really need to find a solution for this, otherwise, geojson-ld looks quite useless to me. How about asking the JSON-LD people to extend JSON-LD to deal with geojson:coordinates so that it becomes a WKT string in RDF automatically? We could introduce something in the context like:

  "@context" : { 
      "coordinates" : {
         "@id" : "geojson:coordinates",
         "@container" : "@coordinates"
      }
   }

Which makes it clear to each JSON-LD parser that it needs to parse what's in there differently.

What do you think?

dret commented 8 years ago

being a graph model with no built-in ordering, RDF is weak at representing anything that needs order. that's because you always need explicit structure (triples) to represent the order that ordered models would give you as a native feature. of course it can be done, but it's bulky, and more importantly, RDF languages/tools then cannot natively support the order (such as simply saying "give me the next thing after the current one"). personally, i am wondering how much sense it makes to call something *-LD if some of the core information is not reflected into a usable RDF model, but i guess that's a different question.

pietercolpaert commented 8 years ago

@dret I follow you completely, yet GIS people looking for a pragmatic solution to leverage the semantic interoperability within their geojson structures, are going to keep looking at GeoJSON-LD and this repository. I thus want a very pragmatic solution to bridge the gap between geojson and RDF, and I think adding a keyword @coordinates to the JSON-LD is the perfect solution for this:

 A JSON-LD parser should convert the JSON structure of an object with key `"coordinates"` towards 1 RDF literal (a WKT string)

What do you think?

dret commented 8 years ago

On 2015-08-27 10:39 , Pieter Colpaert wrote:

@dret https://github.com/dret I follow you completely, yet GIS people looking for a pragmatic solution to leverage the semantic interoperability within their geojson structures, are going to keep looking at GeoJSON-LD and this repository.

one of the key questions is: will people just/mainly be interested to get access to the "upper GeoJSON structures" (features/collections), in which case just reflecting those into RDF would be sufficient, or will they also want to work with the geometries, in which case not reflecting that information might be an issue.

I thus want a very pragmatic solution to bridge the gap between geojson and RDF, and I think adding a keyword |@coordinates| to the JSON-LD is the perfect solution for this: | A JSON-LD parser should convert the JSON structure of an object with key "coordinates" towards 1 RDF literal (a WKT string)

i think there is precedent for "hacking RDF" in this way where people choose to serialize sequences into RDF strings, because RDF's missing support for sequences.

however, this is a bit tricky. it essentially means that now people have to parse two levels: first the RDF itself, and then the structure embedded in the string (the "WKT string"). in the case of GeoJSON, this gets particularly tricky because of GeoJSON's extensibility: coordinates can have more than just lat/long values. would those additional values get dropped?

if no, this means all implementations would need to make sure that they correctly implement the string parsing to accommodate GeoJSON's extension model.
if yes, then this means GeoJSON-LD is effectively dropping information from GeoJSON and thus is not as expressive as GeoJSON itself.

personally, i think this is where JSON-LD (and any data binding techs in general) show their limitations and potential problems. it's usually not that hard to solve this kind of mapping between metamodels in tightly coupled settings where all parts of the data model are known in advance, but when you look at the bigger picture of extensibility and openness in decentralized settings, things get tricky pretty fast.

i cannot think of a simple good solution here, but i would recommend to carefully think about all possible uses of GeoJSON, including all extension points, before making a decision.

pietercolpaert commented 8 years ago

+1... How could we speed up the process to get to a solution? My own knowledge about geojson is limited at this moment.

sgillies commented 8 years ago

@pietercolpaert the @coordinates container idea is very intriguing! I'm game to help you pursue this. I have a couple questions. Do you know of a listing of standard containers? Have other projects defined new containers or would @coordinates be unprecedented?

pietercolpaert commented 8 years ago

@sgillies do you mean such as in chapter 3.3 of http://www.w3.org/TR/json-ld/? I think for third party containers, geojsonld would be the first one. /cc @lanthaler

dret commented 8 years ago

On 2015-08-27 11:37 , Pieter Colpaert wrote:

+1... How could we speed up the process to get to a solution? My own knowledge about geojson is limited at this moment.

i guess the best answer to that is that it depends on how you define "a solution". i know this is not the most helpful answer, but i do believe that the current state of affairs doesn't allow anything better. we have two main issues:

GeoJSON itself is extensible in the sense that you can add things to it. but this also makes it challenging for GeoJSON consumers to know what to expect, if they want to support openness and extensibility. this is a known issue (https://github.com/geojson/draft-geojson/issues/59) but one that will take time to resolve, and it is not clear by now if and how it will be resolved.
in order for GeoJSON-LD to be robust, i'd assume it should also be able to deal with GeoJSON that contains extensions. but since the extension model is a bit fuzzy, the first problem is that GeoJSON makes it hard to predict what kind of extensions to expect, and the second problem is to figure out how to support those in a way that produces RDF without losing information.

one solution could be to say that extensions are not supported, and simply ignore them in GeoJSON-LD. i wouldn't say that's a good solution, but it is a possible one. anything else, like i said before, will get tricky, because you're getting into the realm of (semi-)generic mappings from JSON to RDF, and like any data binding method, these mappings often are either complicated, or produce hard-to-use results, or both.

— Reply to this email directly or view it on GitHub https://github.com/geojson/geojson-ld/issues/32#issuecomment-135517745.

sgillies commented 8 years ago

Hey, I really don't enjoy deleting off-topic comments, but I will. This is complicated stuff and noise only makes it harder.

sgillies commented 8 years ago

@pietercolpaert it would be good to generalize the container we're talking about as much as possible (but no further). I think @ndarray (multi-dimensional array, the name comes from Numpy) would be more general than @coordinates.

dret commented 8 years ago

whatever exactly the container choice will be, it should be aligned with the (yet to be defined) extension model for GeoJSON coordinates: https://github.com/geojson/draft-geojson/issues/57

pietercolpaert commented 8 years ago

@dret - I think it's a good idea to add a different container model: it's a generic solution which still enables you to map extensions of geojsonld through the @context

@sgillies Can you give me an example of how this @ndarray would be configured? How can we make this as extensible as possible?

I think we should link this to an RDF vocabulary, which doesn't exist for @ndarray to the best of my knowledge. Maybe the datacube vocabulary is a good idea? http://www.w3.org/TR/vocab-data-cube/. I'm unsure about what that would look like as well...

akuckartz commented 8 years ago

Can this issue be reopened please? If not then I would suggest to discuss this issue elsewhere.

lanthaler commented 8 years ago

The easiest solution would be to transform the value of geometry in the initial example to "LINESTRING(3.1057405471801753 51.064216229943476, 3.1056976318359375 51.063434090307574)" JSON-LD's data model is not able to support such structures (it serializes labeled, directed graphs) without a vocabulary. Making JSON-LD depend on a vocabulary would be a really hard sell.

sgillies commented 8 years ago

@lanthaler yes, a conversion of GeoJSON geometry to a WKT literal or a JSON literal (why not?) for RDF makes sense. But how should we signal to a JSON-LD processor that it is to do this? That's the question. @pietercolpaert and I are trying to figure out if a new container type could be the signal.

dret commented 8 years ago

sorry for being a broken record, but: whatever the mechanism is, it should be capable of mapping whatever GeoJSON's extension model may throw at it.

sgillies commented 8 years ago

@dret I don't follow. Are you referring to extensions that would introduce strings or objects into the GeoJSON coordinates array? I really hope we can discourage that kind of extension. It would enormously complicate this issue here.

dret commented 8 years ago

according to https://github.com/geojson/draft-geojson/issues/57, the current model is not perfect (because extensions can only be added when elevation values are present), and a little fuzzy. but it seems to allow an arbitrary number of added values, as long as there is an elevation, and as long as these values are numbers. what i am saying is that GeoJSON-LD should say what happens with these extensions as a result of the mapping process. iff GeoJSON changes this model, then GeoJSON-LD should adapt accordingly.

danbri commented 8 years ago

What is the status of this issue? Waiting for https://github.com/geojson/geojson-ld/issues/34 to be resolved? Do we have to wait for JSON-LD v2 for this?

sgillies commented 8 years ago

@danbri yes, waiting on #34. I think the last comment on that one is just trolling, I'm not trying to mobilize a JSON-LD v2.

danbri commented 8 years ago

So the expectation is that people working on triples/graphs downstream from JSON-LD v1.0 parsers would need to get their parsers patched especially for Geo-JSON-LD?

dret commented 8 years ago

On 2015-10-27 07:32, Dan Brickley wrote:

So the expectation is that people working on triples/graphs downstream from JSON-LD v1.0 parsers would need to get their parsers patched especially for Geo-JSON-LD?

afaict, there is no way around this, either way.

if there is some special mapping of coordinates into RDF structures (beyond what JSON-LD 1.0 can do out of the box), then this mapping will need to be added to a generic parser.
if coordinates get mapped to some string-based representation in RDF literals, then those strings need to get parsed, and that takes some specific code as well.

danbri commented 8 years ago

@dret - yes, it is an awkward set of tradeoffs. I lean towards microsyntax for the reason that in some settings it is not always an easy option to rewire the parser if you're working downstream on the emitted triples.

dret commented 8 years ago

On 2015-10-27 09:28, Dan Brickley wrote:

@dret https://github.com/dret - yes, it is an awkward set of tradeoffs. I lean towards microsyntax for the reason that in some settings it is not always an easy option to rewire the parser if you're working downstream on the emitted triples.

i am fine with the microsyntax approach, but being the broken record that i am, in that case it is important to clearly specify what happens when the GeoJSON coordinates contain extensions. one "extension" (or rather, an optional value) being elevation data, and then (at least that's what allowed currently allowed) any number of numeric values following the optional elevation.

akuckartz commented 8 years ago

As I suggested some time ago: avoid designing a new (micro-)syntax: use WKT.

sgillies commented 8 years ago

@danbri @dret I don't get what you mean by microsyntax here. It's my understanding that microsyntaxes were eliminated from JSON-LD on the way to 1.0 and that @list and @set and (maybe) @ndarray are keywords, and not the kind of microsyntax that kept JSON-LD from being parsed as ordinary JSON.

I'm trying to figure out if a new keyword, @ndarray, can help parsers get a grip on the multidimensional array that is a GeoJSON geometry's coordinates and provide a basis for implementations.

danbri commented 8 years ago

I don't understand whatever sense you're using of 'microsyntax' :) My meaning was roughly "something that shows up in the host language as a simple string, but which has substantive and predictable internal structure which can be exploited elsewhere"...

dr-shorthair commented 8 years ago

e.g. nest a WKT value in a JSON string

danbri commented 8 years ago

Yes, exactly that kind of thing.

dinizime commented 8 years ago

About the @ndarray, the thing is we will not find a solution for any multidimensional array (and we dont even want that), so in my view seems a wrong approach.

What is missing in my opinion in a key word that tells the conventional JSON-LD parser to ignore that processing of specific things (in the idea of jsonld:JsonData #28 Comment). And then a way to give custom functions to the JSON-LD processor deal with those keywords.

"coordinates": "[[102.0, 0.0], [103.0, 1.0], [104.0, 0.0], [105.0, 1.0]]"

But instead of giving type "jsonld:JsonData, we give type "jsonld:GeoJsonCoords". The RDF for the JSON-LD processor becomes:

<> geo:coordinates "[[102.0, 0.0], [103.0, 1.0], [104.0, 0.0], [105.0, 1.0]]"^^jsonld:GeoJsonCoords.

But also the JSON-LD processor can advertise the unresolved custom types.

jsonld.customFormats();
\\returns ["jsonld:GeoJsonCoords"]

And you can register a custom function to parse the type to WKT for example.

jsonld.registerFormat("jsonld:GeoJsonCoords", function(..){....});

In this way if you have a GeoJSON extension, like @dret mentioned, you register an appropriate function. If the user don't care about that will be just ignored by the JSON-LD processor.

Make the custom formats dereferenceable URI and autonomous clients that are GeoJSON-LD aware will know what to look for, and based on their needs will have an appropriate function (that can be WKT or whatever they need).

The solution would work for anything that can't be mapped to RDF in the straightforward way, and its more suit to the users needs.

sgillies commented 8 years ago

@dinizime you've convinced me that @ndarray is too general. @pietercolpaert do you concur? If so, I'll mark issues related to that keyword as closed.

Is it okay if I restate a couple things? The GeoJSON format's coordinates array can not be converted into pure (for lack of a better term) RDF. The GeoJSON format is not going to change to use WKT for its geometry representation.

However, values of geojson:geometry do convert readily to and from WKT. Software to do the conversion is readily available to developers of JSON-LD parsers. What's lacking is a way to direct the parsers to make the conversion we can make round trips between (say) http://www.opengis.net/ont/geosparql:wktLiteral and {"coordinates": [[[[...]]]]}.

@jasnell suggested (if I interpreted him correctly) at https://github.com/geojson/geojson-ld/issues/28#issuecomment-64133121 that we do this:

"@context": {
  "coordinates": {
    "@id": "geojson:coordinates",
    "@type": "http://www.opengis.net/ont/geosparql:wktLiteral"
  }  
}

The GeoJSON to wktLiteral coercion isn't built in to JSON parsers, but the @id and @type in the context could serve as keys to look up a registered function (as suggested above by @dinizime) that could coerce the GeoJSON array to WKT, yes? Can someone who understands JSON-LD type coercion let me know if this is a reasonable approach? Do we still need a keyword to tell parsers to perform the lookup?

That bit of context doesn't help in the conversion of RDF back to GeoJSON because it doesn't specify the natural JSON type of geojson:coordinates. And if it led to the creation of JSON documents with {"geometry": "POLYGON((...))"}, that would not be a good thing. But if we're okay with type coercion being a one-way street, referencing the GeoSPARQL data type appears to meet the needs that RDF users have expressed here.

dret commented 8 years ago

On 2015-10-28 22:18, Sean Gillies wrote:

Is it okay if I restate a couple things? The GeoJSON format's coordinates array can not be converted into pure (for lack of a better term) RDF.

i don't think anybody said it like this. it's just that any mapping that would (a) cover all of GeoJSON's structure and extensibility, and (b) would map all of this losslessly into RDF, would very likely be a rather awkward and bulky RDF model to work with. plus, we cannot have this right out of the JSON-LD 1.0 box.

The GeoJSON format is not going to change to use WKT for its geometry representation.

i don't think anybody asked for it to change that way. afaict, what people suggested was to use WKT for representing GeoJSON structure in the RDF mapping, so that a GeoJSON geometry would be represented as a "WKT literal" in RDF.

That bit of context doesn't help in the conversion of RDF back to GeoJSON because it doesn't specify the natural JSON type of geojson:coordinates. And if it led to the creation of JSON documents with |{"geometry": "POLYGON((...))"}|, that would not be a good thing.

very good point, we should always keep in mind that any model mapping does need to be bidirectional.

But if we're okay with type coercion being a one-way street, I'm okay with referencing a GeoSPARQL data type.

wouldn't any mapping of GeoJSON do a different metamodel have to be directional, so that it is clear how a GeoJSON instance in that different metamodel has to be mapped to GeoJSON? if there's no such specification, wouldn't we run the risk of different people doing it i different ways, and then any sequence of steps that would have some RDF-based step in the middle might be affected by how a specific implementation serializes the "RDF GeoJSON" back into actual GeoJSON?

pietercolpaert commented 8 years ago

@sgillies My gut feeling (giving my current experience, this may be horribly wrong) that multidimensional arrays is the one thing missing from JSON-LD to also bridge the gap to other JSON formats ( @lanthaler: opinion wanted), and also give a generic solution to geojson-ld extensions (@dret's record ;) ). I would not find it a bad idea to create a JSON-LD 2.0, if this immediately avoids a lot of discussions in the future. A clear drawback however is that JSON-LD contexts for these multidimensional arrays will get quite complex, but on the other hand, for things like geojson-ld, these contexts will be reusable.

@dinizime I understood that you are in favor of introducing jsonld-parser extensions. To me, this sounds like the beginning of a plethora of JSON-LD dialects. With any standard, dialects are the worst thing that can happen. Meetings will take place on which kind of JSON-LD should be implemented. It also opens the door to "proprietary extensions" and I'm pretty sure we don't want to get down that road.

letmaik commented 8 years ago

What's so bad about the ^^jsonld:JsonData idea from @msporny? This seems to work for many cases where fine-grained triples aren't suitable and it's generic enough.

You could extend JSON-LD with @json such that the context would be:

"coordinates": {"@id": "geojson:coordinates", "@json": true}

And this would result in "[[1,2],[3,4]]"^^jsonld:JsonData. In RDF land, you'd have to understand jsonld:JsonData. And converting that back to GeoJSON/JSON-LD would work as well since you would use the GeoJSON context above for that which knows that it should be converted into an actual JSON structure.

The main question is: Is it acceptable to promote JSON as a standard format for such non-RDF-suitable things? After all, JSON-LD is just one of many RDF formats. So why not "<arr><row><col>1</col><col>2</col></row<row><col>3</col><col>4</col></row></arr>"^^rdf:xmldata or similar? Ideally, there should be a neutral JSON-like "data" format at RDF level into and from which JSON-LD can transform. I'd say JSON is a pretty natural fit, but then the type shouldn't be jsonld:jsonData but rather something like http://www.iana.org/assignments/media-types/application/json.

pietercolpaert commented 8 years ago

@neothemachine ^^jsonld:JsonData does not solve the problem at all and introduces complex post-processing if you want your script to understand the data inside. Everyone will start writing their own non standard way of understanding a jsonld:JsonData field. JSON-LD should be more ambitious and should explain the semantics of values/objects within a multidimensional array.

letmaik commented 8 years ago

Well, ok, but then the first step would be to write an ontology for such multidimensional arrays including a specification of the literal values, and that has to be published somewhere. Only then you can start thinking about including a thing like @ndarray into JSON-LD, which may or may not support only some subtypes of all the types of multidimensional arrays defined in such ontology. The tricky part is also that there are multiple ways to reconstruct such an array into JSON. For example, one format could be the GeoJSON one with nested arrays. Another format where the array is regular could be simply {shape: [2,4], values: [1,2,3,4,5,6,7,8]}. I would be happy if such an ontology exists and JSON-LD would make use of it. It's clearly the better solution, it just needs way more work.

pietercolpaert commented 8 years ago

Why do we need an ontology exactly? I'd rather not make the JSON-LD spec depend on an external ontology.

The JSON-LD @context could become something like this, for example, by introducing @values to specify precise mappings of things within a set or list:

"@context": {
    "geojson": "http://ld.geojson.org/vocab#",
     ...
     "coordinates": {
        "@id": "geojson:coordinates",
        "@container" : "@list",
        "@values" : { 
           "@type" : "geojson:Coordinate",
           "@container" : "@set"
           "@values" : [
               {"@type" : "xsd:double", "@id":"geo:longitude"},
               {"@type" : "xsd:double", "@id":"geo:latitude"}
           ]
        }
     }
}

You make JSON-LD specify the structure of the array in the context and attach URIs to the specific array elements.

letmaik commented 8 years ago

How would you convert that to RDF and back to JSON-LD without an ontology?

I couldn't find anything in the spec that links JSON-LD's @list to the RDF collections but this is what comes out when transforming to RDF.

Input:

{
  "@id": "http://example.org/people#joebob",
  "foaf:nick":
  {
    "@list": [ "joe", "bob", "jaybee" ]
  }
}

N-Quads (from JSON-LD playground):

<http://example.org/people#joebob> <foaf:nick> _:b0 .
_:b0 <http://www.w3.org/1999/02/22-rdf-syntax-ns#first> "joe" .
_:b0 <http://www.w3.org/1999/02/22-rdf-syntax-ns#rest> _:b1 .
_:b1 <http://www.w3.org/1999/02/22-rdf-syntax-ns#first> "bob" .
_:b1 <http://www.w3.org/1999/02/22-rdf-syntax-ns#rest> _:b2 .
_:b2 <http://www.w3.org/1999/02/22-rdf-syntax-ns#first> "jaybee" .
_:b2 <http://www.w3.org/1999/02/22-rdf-syntax-ns#rest> <http://www.w3.org/1999/02/22-rdf-syntax-ns#nil> .

Converted back to JSON-LD:

{
  "@context": {
    "rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
    "rdfs": "http://www.w3.org/2000/01/rdf-schema#",
    "xsd": "http://www.w3.org/2001/XMLSchema#"
  },
  "@id": "http://example.org/people#joebob",
  "foaf:nick": {
    "@list": [
      "joe",
      "bob",
      "jaybee"
    ]
  }
}

and compaction would remove the context again.

Any idea where this transformation using this collection vocabulary is defined?

pietercolpaert commented 8 years ago

@neothemachine I think it's implicit: rdf:List is how ordered lists in RDF work...

dinizime commented 8 years ago

@pietercolpaert I agree with such description, but still you have an open problem of how to deserialize the coordinates object to RDF. I really cannot see how exploding coordinates into triples can generate something useful for geoprocessing in RDF, but maybe for some other application domain the explosion of a @ndarray is desirable.

Since RDF cannot really do something good with multidimensional array we should map to something else, this means a custom parser or to natively embed geojson in JSON-LD (not the case).

pietercolpaert commented 8 years ago

@dinizime You're re-raising the point whether we should go directly towards a "microsyntax" (e.g., json string or wkt-string) instead of going to an RDF graph which may become pretty big. I believe however we should have the choice. If the context indicates something is a list of geojsonld:Coordinates, then you can still decide that you want to compact this into one WKT string. Parsers which are oblivious about geo-data however, will still get sensible mapping results.

dinizime commented 8 years ago

@pietercolpaert Exactly, that is why in my post I defended that the vanilla JSON-LD should not do anything with the @ndarray. We can describe the coordinates in the way you suggested and add a keyword to make the JSON-LD deserializer don't do anything with it (in the idea of jsondata). Then the user has the choice of postprocessing and exploding in something like NeoGeo vocabulary, or compact into WKT, or anything he wants. The maximum that we can do is to provide in the GeoJSON-LD specification a custom parser for deserializing and serializing geojson geometries, providing a standard representation of the geometry in RDF (which can be WKT or something else). But again this is a custom parser and everything that you mentioned before applies ( plethora of JSON-LD dialects).

pietercolpaert commented 8 years ago

@dinizime Indeed, this is the only solution that will work in a short enough term. We must however safeguard that JSON-LD may give us the right tools somewhere in the future to be fully compliant.

ktk commented 8 years ago

This issue is also referenced in the proposal by @bergos here https://zazukoians.github.io/geojson-ld/

It was also posted to the W3C Spatial Data on the Web list https://lists.w3.org/Archives/Public/public-sdw-comments/2016Feb/0019.html

retog commented 8 years ago

There was this proposal to get tabular data more easily into JsonLD: https://github.com/json-ld/json-ld.org/issues/146. The ideas is to assign the right property based on the position in the array.

sgillies commented 8 years ago

We seem to be at an impasse. Closing.

mitar commented 5 years ago

For anyone following this, current plan in the JSON-LD working group is to close a proposed solution as "won't fix", so please give any feedback about this here: https://github.com/w3c/json-ld-syntax/issues/7

BigBlueHat commented 5 years ago

Thanks for connecting these dots @mitar!

@sgillies et al, your inputs would be helpful as we discuss JSON-LD 1.1--which is intended to reach W3C Recommendation status and replace (afaik) existing JSON-LD 1.0 plumbing/syntax/etc.

To that end, we'd love your input and feedback on https://github.com/w3c/json-ld-syntax/issues/7 specifically, but also anything you find in https://github.com/w3c/json-ld-syntax/ and https://github.com/w3c/json-ld-api/ that seems GeoJSON-LD related or could help solve for your goals.

Granted, we're trying to overlap a lot of Venn Diagram pieces to find the core feature set, but your input would be valuable in knowing we're on the right track (or not)!

Cheers! 🎩

geojson / geojson-ld

Coordinates to RDF doesn't work #32