Re: Cross-Context JSON-LD Integration

Howdy!

On 09/07/2015 09:18 AM, Ivan Herman wrote:
> (Explicitly cc-ing Gregg, who knows JSON-LD better than many…)
>> On 03 Sep 2015, at 01:30 , Robert Sanderson <azaroth42@gmail.com> wrote:
...
>> However, if we include very low level aliases for @id and @type, it seems like we would end up with unanticipated behavior.  If the same JSON-LD document had both contexts, then regardless of the order of the two contexts, all of the '@id' and '@type' keys would end up as 'id' and 'type', regardless of whether they were part of the ActivityStreams part or the Annotation part.  AS based systems would then potentially fail, as they would be checking for different keys than the output produced.  The same seems like it would be true for other integrating systems as well.
> 
> Actually… is this correct?
> 
> My understanding is that setting the alias in a @context for "id" only means a one-directional mapping, ie, that all "id" properties will be mapped onto "@id". However, it does not (should not…) affect any explicit usage of "@id", which can be used unchanged and with no semantics changed. In other words, if an AS user continues to use "@id", AS systems will consume that as is. Of course it is true that AS systems may fail to understand "id" unless they process all @context-s, but that is probably true anyway if the AS system wants to use directly OA statements without turning the whole graph into a fully integrated RDF through conversion measures.
> 
> Bottom line is: I am not convinced we do have a problem. The only problem we may have is AS uses the term "id" for a different purpose. We would then have term collision, but that is not restricted to "id": it is a danger for *any* prefix-less terms; the only safe way of managing graph integration with JSON-LD without knowing the respective vocabularies is to use prefix-ed terms only. This is a general problem.
Related to prefix-less / prefix-ed terms

In Social WG I have old pending action to clarify if we will need
version numbers in JSON-LD context URIs as well as requirement of
freezing included terms after publishing it.
* Document why some of json-ld authors use v1 etc. in context uris -
https://www.w3.org/Social/track/actions/65

Current AS2.0 WD states in Serialization Notes section[1]
"Implementations may augment the provided @context with additional
@context definitions but must not override or change the normative
context. Implementations may also include in the serialized JSON
document additional properties and values not defined in the JSON-LD
@context with the understanding that any such properties will likely be
unsupported and ignored by consuming implementations that use the
standard JSON-LD algorithms. See the Extensibility section for more
information on handling extensions within Activity Streams 2.0 documents."

This allows people to use not mapped to any URI properties like for
example *foo* and still conform to the spec. Given that, it seems that
we need to freeze normative context, implied by
application/activity+json media type, since adding to it mapping for any
of such *foo* properties would change meaning of already published data!

Related github issues:
* require explicit @vocab or define prefix if custom terms used, to
remove current "@vocab": "_:" hack -
https://github.com/jasnell/w3c-socialwg-activitystreams/issues/134
* can media type specify default JSON-LD context? -
https://github.com/jasnell/w3c-socialwg-activitystreams/issues/132

I also cc Web Schemas group and Dan Brickley who mentioned while ago
some interesting findings in leveraging JSON-LD context for
interoperability - https://twitter.com/danbri/status/574255292256509952

Cheers!

[1]
http://www.w3.org/TR/2015/WD-activitystreams-core-20150722/#syntaxconventions