separate @context to include when processing AS1.0 documents

[elf-pavlik]

We could try to create separate context to add when processing AS1.0 documents. It would provide graceful degradation requiring some additional post processing (seeAlso #14)

• as:Verb & as:verb possibly not needed #23 redefine as:verb
• Activity Streams 1.0 Terms

[jasnell]

This is reasonable. We just need to have that @context defined. I believe @dret is working on an initial take.

[dret]

yes i am, and that context probably would become part of the AS1-in-AS2 processing model. it would be limited, though because certain legal AS1 constructs (GeoJSON is one example) cannot be mapped via JSON-LD. this means that the processing model and the context would need to say how to interpret those legal AS1 documents as AS2.
in the end, if AS2 becomes a pure RDF model (that just happens to limit itself to a JSON-based serialization of RDF), there is quite a bit of metamodel impedance between AS1 and AS2, and any attempt at mapping between the two will have to address that impredance.

[elf-pavlik]

@dret for GeoJSON, maybe https://github.com/geojson/geojson-ld could come handy?

[jasnell]

That doesn't help too much. The fundamental problem with geojson is that it uses an array of arrays for complex geometries. JSON-LD simply does not support arrays of arrays as values. Having a @context for geojson doesn't fix that problem. Geojson simply cannot be used in JSON-LD 1.0 formats without data loss.

[dret]

that's the point i wanted to make. AS1 is native JSON and people can do whatever JSON allows them to do. the "AS1 infoset" is based on JSON's expressivity. AS2 probably will turn out to be RDF (in a JSON syntax) and thus allows people to do whatever RDF (in this JSON syntax) allows them to do. the "AS2 infoset" is based on RDF's expressivity. any spec language talking about AS1/AS2 will have to take that into account, and might end up saying that for certain cases, a reasonable mapping is not possible. i think that's ok and as good as it gets, it's the price you have to pay when switching metamodels in flight when a format evolves.

[jasnell]

FWIW, as part of the AS1->AS2 processing model, we can define limited pre-processing steps to catch these kinds of incompatibilities. So far, geojson's use of array-of-arrays is the only practical one I've come across. For geojson specifically, there are a couple of options:

1. We can look for geojson specifically and convert it into a compatible representation (such as GeoSparql's wktLiteral.
2. We can handle lists-of-lists generically and convert to a rather cumbersome but workable generalized model, like so:

{
  "coordinates": [[5,4,3],[2,1]]
}

becomes something like:

{
  "coordinates": {
    "@list": [
      {"coordinates": { "@list": [5,4,3] }},
      {"coordinates": { "@list": [2,1] }}
    ]
  }
}

The obvious challenge with this type of expansion is that it requires us to pre-process and modify the document before applying the JSON-LD algorithms, which is obviously less than ideal. The key issue, however, is that just having the AS 1.0 @context document is not going to solve all the possible translation issues here. We'll need to address the JSON -> JSON-LD gaps as well.

[dret]

we can have a very specific model that says what to do with one specific JSON that doesn't map. but that does not address the problem that there can be any other number of JSON structures that run into the same limitations of JSON-LD. how to handle these (after maybe first applying the rules that handle special and well-known cases such as GeoJSON)? silently drop them? generically map them and thereby attempt to solve a problem that JSON-LD consciously stepped away from because RDF simply doesn't have a good way how to represent these structures? i would be very careful to have compatibility rules that hardcode mappings for very specific formats, but that's just my opinion.

[jasnell]

The real question is: outside of lists-of-lists, are there any other existing JSON mechanisms that are not supported in JSON-LD? The only other one that I'm aware of is that, by default, JSON arrays are treated as sets within JSON-LD, which means while order and duplicates are preserved through JSON-LD expansion, those are lost in further normalization. Since we have no way of knowing if order is significant in arrays used within arbitrary extensions, we have to treat all extension arrays as @lists, which will requires additional pre-processing.

[dret]

we were just discussing this general JSON-LD problem over at https://twitter.com/alexmilowski/status/529679007147507712, and in the end, it's not even a JSON-LD problem, it's simply the mismatch between metamodels that you're experiencing every time you start mapping between them. so having a general list of "doesn't work (that well) in RDF and thus has been left out or only partially addressed in JSON-LD" would be a necessary starting point. and maybe the JSON-LD community would benefit as a whole if such a list existed. once we have that, then we have to decide what to do: (a) discard stuff, (b) selectively map some stuff that we know of and want to preserve and map somehow (such as GeoJSON), or (c) write generic mapping rules that were left out of JSON-LD, but now we're adding them. personally, i am scared of (c).

[jasnell]

Let's start with (b). At this point we already know that lists are a problem; they're also the only problem we've been able to identify so far. So let's deal with those specifically as part of the AS1->AS2 processing model and iterate as necessary from there.

[dret]

we can certainly start with (b), but eventually we'll still have to decide what to do with anything that's not on the (b) list: go the (a) or the (c) route...

[jasnell]

We already have a clear path defined. AS 1.0 established a "Must Ignore" unsupported exceptions rule that is carried over to AS 2.0. We can do (b) in limited cases, default to (a) for the rest but allow implementations to do (c) if they want.

[dret]

#48 is probably related, where you're saying that ignoring is ok, but preserving as well. is that really something that we want to leave undefined? if i want predictable behavior from an AS2 implementation i am picking, wouldn't i want to know when they do (a) or (c), because that means i end up seeing different things?

[akuckartz]

Currently I tend to agree with #30 (comment) Those who want to have more automatic RDF-support then will need to move to AS 2.0.

BUT also take note of this unresolved discussion regarding WKT, JSON-LD and GeoJSON: geojson/geojson-ld#28 (see also: schemaorg/schemaorg#113). Converting GeoJSON to WKT might be something to be considered.