support @values for describing multidimensional containers

[gkellogg]

Allows a term definition to include an @values block to describe structured values, such as for GeoJSON

Example

{
  "@context": {
     "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"}
           ]
        }
     }
  },
  "@graph" : [{
   "@id" : "ex:LineString1",
    "coordinates" : [
          [
            3.1057405471801753,
            51.064216229943476
          ],
          [
            3.1056976318359375,
            51.063434090307574
          ]
    ]
  }]
}

Would transform to (and vice versa):

ex:LineString1 geojson:coordinates _:b0 .
_:b0 rdf:first _:b1 .
_:b1 a geojson:Coordinate ;
      geo:longitude "3.105740547180175E0"^^xsd:double ;
      geo:latitude "5.106421622994348E1"^^xsd:double .
_:b0 rdf:rest _:b2 .
_:b2 rdf:first a geojson:Coordinate ;
      geo:longitude "3.1056976318359375"^^xsd:double ;
      geo:latitude "51.063434090307574"^^xsd:double .
_:b2 rdf:rest rdf:nil .

Original issue is JSON-LD 1.1 Feature Request: support @values for describing multidimensional containers (list of lists) #397

[pietercolpaert]

Appologies -- Wrongly assumed opening this issue meant it was going to be adopted in JSON-LD 1.1 - https://twitter.com/pietercolpaert/status/1013100062879178754

Would love this proposal to be taken into account for the 1.1 spec though!

[p1d1d1]

Any thoughts how this could map to GeoSPARQL?

[Fak3]

refs json-ld/json-ld.org#52

[azaroth42]

+1 to the issue, we should discuss the proposed solution.

[azaroth42]

Actually, in re-reading, re-thinking I'm 👎 to the issue as it doesn't round trip back to the right structure. Lists of Lists is the critical one for GeoJSON-LD (and others), not being able to insert predicates into the structure. I think this one crosses the line into data transformation, which is not the point of a JSON-LD context.

[azaroth42]

Following discussion on WG call 2018-08-31, the current thinking is to close wontfix. This is the transformation of data, rather than the serialization of it, as it creates new triples. It would be a lot of work, for limited situations where it adds value, and not be able to be round-tripped back to the original format.

Please weigh in by 2018-09-07.

[mitar]

I think it would be very sad if one could not use JSON-LD together with GeoJSON. It means that GeoJSON-LD community would have to fork JSON-LD and create its own dialect, just to support that.

Please see some comments in the original issue and the original discussion.

[akuckartz]

According to json-ld/json-ld.org#397 (comment) that issue was closed in favor of this issue and now the declared intention is to also close this issue?

My experience is that the importance of geo-data is increasing significantly. JSON-LD should provide the necessary features to bridge the gap to GeoJSON - and vice versa.

[msporny]

JSON-LD should provide the necessary features to bridge the gap to GeoJSON - and vice versa.

This is one of the reasons that I proposed #33. We need to find a way for communities to sub-dialect JSON-LD in extensible ways that we know will never become mainstream JSON-LD. We need to provide a mechanism so that the GeoJSON community can use JSON-LD without impacting processors that don't want to support that particular feature. Without this, we're slamming the door in their face.

The only alternative I can think of is to create pre and post processing libraries for this specific use case to demonstrate that it is possible to trivially write .toGeoJSONLD() and .fromGeoJSONLD() functions. So, the other proposal is to enable pipelining in JSON-LD processors where you can inject a series of functions that are called before/after compaction/expansion.

[mitar]

@msporny I think you would get into interoperability hell in this way. The whole idea of standardization is to get to a common standard.

It is also not that GeoJSON requires many additions to JSON-LD. Community has identified one and proposed a solution. Maybe some other solution could also be found if this one is not desirable?

[kgeographer]

See for example the developing Linked Places format spec [1], which is intended to be both valid JSON-LD and valid GeoJSON. It will be used for contributions to two aggregating systems for historical geodata, Pelagios/Peripleo and World-Historical Gazetteer.

At this point we have to tell users that coordinates are okay for Points, but for polygons and lines, to supply Well-Known Text (WKT). If they do, the data is no longer valid GeoJSON. We've gone ahead with this on a presumption that the JSON-LD community would find a fix - sure hope that's the case.

[1] latest "v3" draft example and context here: https://github.com/LinkedPasts/linked-places/tree/master/new

[azaroth42]

@kgeographer I think you're confusing the (accepted) list-of-lists issue with the ability to associate predicates with arbitrary data structures (this issue). Users in 1.1 would absolutely be able to represent the polygons and lines with the regular GeoJSON construction of a list of lists. What they would not be able to do is generate new information that the inner list is an instance of the class geojson:Coordinate that has two properties geojson:longitude and geojson:latitude which are the values of the list in that order.

The rabbit hole would then be that any arbitrary structure could have contexts inject arbitrary information into instances that would be invisible to the instance until expanded with the context, and not round trip back to the same format when it is compacted.

[gkellogg]

There are other cases where there might be special "template" processing for array members, such as #15, but these are fundamentally much different than existing JSON-LD behavior.

We might, at some time, consider a spec for "JSON-LD Templating", that would allow these to be treated using the same mechanism, so that templates could be applied to successive (possibly repeating) array values to perform different transformations, but I would not like to see this as part of the core API. This might also provide a mechanism for another group (such as the JSON-LD CG) to foster such a specification. Simply seeing otherwise illegal constructs in a context definition is probably sufficient to key in the extension; the "@version": 1.1 is really necessary because JSON-LD 1.0 was not strict enough in processing context/term definitions, so things like this could be missed.

[iherman]

(Admin comment) I think there are several issues around that refer to GeoJSON. I think that it would be more fruitful to give these a rest and have these issues discussed on a dedicated session at the F2F at TPAC.

[BigBlueHat]

(Admin comment) I think there are several issues around that refer to GeoJSON. I think that it would be more fruitful to give these a rest and have these issues discussed on a dedicated session at the F2F at TPAC.

Only if we'll have GeoJSON folks on hand. Otherwise, we'll be flying blind on the topic...

Perhaps we can at least create a list (pre-TPAC) of GeoJSON related needs/wants with the help of @kgeographer and others, so that we can have some targets to hit (or not hit) when the time comes.

Additionally, we might consider inviting a few of the GeoJSON-LD and LinkedPasts folks to a call (or two) to help us understand their use cases better.

[ajs6f]

Huge 👍 s to getting some f2f or 'phone time with GeoJSON folks. Perhaps we can reach out and see if anyone from that community will be at TPAC and available to talk?

[iherman]

Only if we'll have GeoJSON folks on hand. Otherwise, we'll be flying blind on the topic...

Obviously, that would be the ideal. But even if they cannot be around, we seem to

1. have a number of issues that are all around GeoJSON
2. have some people in the group may have knowledge on GeoJSON that can help others (like me…) to make informed decision

A F2F meeting seems to be a good place to concentrate on this.

[BigBlueHat]

@iherman agreed that a F2F meeting will help us cover this ground faster/better. I was mostly reacting to "give these [GeoJSON topics] a rest." If there's interest from that community (as there seems to be) in mapping GeoJSON into JSON-LD, then we have a quality JSON-first set of use cases to help us define JSON-LD features. It seems like a valuable thing to put on hold.

In fact, I'd like many more such scenarios/formats to help us confirm or deny our approach(es). JSON-LD is a bridge between the worlds, after all. 😃

[kgeographer]

@azaroth42 I was not aware 1.1 accommodates lists of lists; I presumed wrongly that the Dev Playground reflected 1.1 as it it stands. At the moment, the Playground won't validate them. Very glad to know accommodating GeoJSON matters to a number of people. For all matters related to interactions between JSON-LD and GeoJSON-LD I defer to @sgillies.

[azaroth42]

Taking into account the comments above, the resolution of the WG on 2018-09-07 was to close this issue and refer it to the JSON-LD Community Group for further exploration. This has been done in issue 677

The rationale for this decision is as follows:

• The transformation of data has not been incubated in the CG and was not part of the draft provided as input to the WG. While there isn't an absolute requirement to incubate features in a CG environment first, data transformation rather than simple mapping of names is a significant piece of work that is not declared in the WG charter.
• We don't have sufficient use cases to work on a generalized data transformation engine at this time. Referring to the CG to gather those use cases and requirements allows forward momentum.
• The scope of the current WG is defined as JSON-LD 1.1. It was the unanimous opinion of the WG that data transformation would warrant a 2.0 version. As such we are not chartered to do the work, nor would it be politically viable in the current environment.
• It was agreed that neither JSON-LD contexts nor frames would be the right vehicle for this functionality.
• Given that the surface syntax of GeoJSON (e.g. Features expressed as list of lists) can be accommodated in 1.1, the use case that is within scope for JSON-LD 1.1 for that community is solved.
• This additional requirement of creating non-round-tripping extra information via context definitions introduces significant attack vectors, where data could be added to the graph post-factum via context expansion that was not present in the original.

[sgillies]

@azaroth42 thanks for the closing note! It seems like there was just a bit of confusion here earlier. I'm looking forward to removing the outstanding issues note in http://geojson.org/geojson-ld/.