Re: Cross-Context JSON-LD Integration

My view has been that aliasing keywords should be left to an end user, and not a part of generally used contexts, for precisely this reason. If a particular application wants to use aliases, they can always re-compact the document with a new context that creates such aliases, as they’re the ones who will benefit from the aliases. Otherwise, as you note, unfortunate interactions when several contexts are used can get in the way.

Really, any dependency for a JSON programmer that keys will have expected meanings when several contexts are used can be problematic. In the case of AS and Social Web you may coordinate so that a term such as “resource” will not be defined in each context, but to be generically reliable, make sure that data which is intermixed is expanded, and then compact using the set of contexts.

Typically, using multiple contexts where you expect the resulting compact JSON-LD to reliably use terms needs to be done with knowledge of what is in the contexts being used.

Gregg Kellogg
gregg@greggkellogg.net

> On Sep 2, 2015, at 4:30 PM, 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.
> 
> 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?  
> 
> 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