Re: Cross-Context JSON-LD Integration

(Explicitly cc-ing Gregg, who knows JSON-LD better than many…)
> On 03 Sep 2015, at 01:30 , Robert Sanderson <azaroth42@gmail.com> wrote:
> 
> 
> Dear Linked JSON, Social and Annotation groups,
> 
> One of the recent proposals in the Annotation WG regarding the JSON-LD context for the specifications, was that @id and @type should be aliased to id and type.
> 
> The rationale was that this is more familiar to native JSON / javascript developers, and allowed the dot notation to access the information.  For example `annotation.body.id <http://annotation.body.id/>` is more natural than `annotation.body['@id']` which is required due to the @ symbol.  The @ symbols were seen as a slight barrier to adoption, and if there were no harmful effects, they could be disposed of.
> 
> And within just a single context, there does indeed seem to be no harmful effects.  The tools all happily compact to id and type as expected.
> 
> One of our strong commitments is to build across working groups so as to avoid re-invention or co-invention of the same pieces of infrastructure.  An example structure that looks very appropriate to re-use is the ActivityStreams 2.0 work taking place in the Social Web WG, and the Collection construct would very neatly fulfill several requirements around paged searches, paged annotation lists and so forth.
> 
> 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.

Gregg, do I miss something here?

> 
> Secondly, a similar proposal was to omit @type/type statements, as unnecessary boilerplate when the rest of the keys would make the class clear.  Through the same integration lens, is this still true or would systems with a broader scope really benefit from the statements?

The same holds as for "id'/"@id", actually.

Ivan

> 
> So we're seeking feedback on the proposals in the broader community, with an eye towards best practices in JSON-LD context definition and use.  With ongoing efforts in several WGs at the moment, is this an opportunity to coalesce some best practices based on usage and implementation experience?
> 
> Please feel free to forwards on to other groups, as appropriate.
> 
> Many thanks for your thoughts on this topic!
> 
> Rob Sanderson, Frederick Hirsch
> [Chairs of the Web Annotation WG]
> 
> --
> Rob Sanderson
> Information Standards Advocate
> Digital Library Systems and Services
> Stanford, CA 94305


----
Ivan Herman, W3C
Digital Publishing Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
ORCID ID: http://orcid.org/0000-0003-0782-2704