Remove JSON-LD from time.md

[sgillies]

GeoJSON-LD is currently blocked where the multidimensional coordinates array runs up against lack of support in RDF and JSON-LD for N-D arrays. To unblock the temporal extension, let's remove JSON-LD from it and move on using type in the not-LD sense.

[sgillies]

Comments very welcome!

[dret]

could you elaborate a little? it seems to me that the fundamental problem is that GeoJSON-LD is based on the JSON-LD model of model mapping from JSON to RDF. what you're referring to is a fundamental misalignment of the two metamodels being mapped and the mapping tech (JSON-LD) not having a way of addressing this misalignment. i am not quite understanding how we can ignore this problem without questioning the very foundation that GeoJSON-LD is built on.

[sgillies]

@dret I am questioning the foundation of GeoJSON-LD and want to separate the temporal extension from GeoJSON-LD so that we can ship it soon.

GeoJSON-LD is, frankly, stuck. And I don't see how to get it unstuck.

[letmaik]

To resolve the @type issue, you could cheat a little:

{
  "@context": {
    "type": {"@id": "http://www.w3.org/1999/02/22-rdf-syntax-ns#type", "@type": "@id" }
  },
  "type": "foo:bar",
  "@type": "bar:foo"
}

Then you can use @type together with type. A work-around until https://github.com/json-ld/json-ld.org/issues/402 is fixed.

[letmaik]

Actually, that's a pretty neat solution, it not only produces the correct RDF triples, it also works the other way around and recreates these "type" and "@type" fields on compaction.

[dret]

@dret https://github.com/dret I /am/ questioning the foundation of GeoJSON-LD and want to separate the temporal extension from GeoJSON-LD so that we can ship it soon.

it's about time (sorry, i couldn't resist...). i think that the general extension model should be discussed at https://github.com/geojson/draft-geojson/issues/59 (and whatever is associated with that), and i would hope that the GeoJSON extension model is in no way bound to GeoJSON-LD.

what i want to say is that if you want to move forward with specific extensions to GeoJSON, or with the general extension model of GeoJSON, then i think that's more of a GeoJSON issue, than one of GeoJSON-LD.

[sgillies]

Agreed, @dret.

[dret]

am i correct to assume that while this would not allow you to add coordinate-level timestamps (as in https://github.com/dret/GeoJSON-X/blob/master/examples/dret.json), but this would only allow to express the start and end time of such an activity? i guess mostly i am wondering how this ends up in the "GeoJSON-LD" repo at all. if that's about extending GeoJSON, then it shouldn't be in here, right? it should either be

• part of core GeoJSON,
• a specific extension of GeoJSON (something like "GeoJSON-Time", hopefully highlighting how to use the yet-to-be-defined extension model of GeoJSON in a proper way), or
• part of some general extension framework such as https://github.com/dret/GeoJSON-X, which currently focuses on per-coordinate information, but could be extended to cover what's discussed here as well.

[sgillies]

@dret the time work ended up here because it was originally based on JSON-LD. I think moving it to its own repository and using it to drive discussion of GeoJSON extension is the right thing to do.

[dret]

so do you prefer option 2 or option 3 listed above?

[sgillies]

@dret sorry I didn't make myself clear. Option 2 is my preference.

[dret]

ok then, should this become its own draft? this could become a bit of a blueprint for the yet-to-be-nailed-down extension story https://github.com/geojson/draft-geojson/issues/59 and how an extension could/should go about fitting itself into the extension model. alternatively, if not a draft, where else would you see this going? it should definitely be removed from GeoJSON-LD if the goal is to not make it dependent on GeoJSON-LD at all, right?

[sgillies]

Closing. Continuing at https://github.com/sgillies/geojson-events.