Re: Cross-Context JSON-LD Integration

Early on with AS2 I attempted to make the same optimization but quickly
reverted back to using @id and @type. It's inconvenient, yes, but has the
least amount of friction.
On Sep 2, 2015 4:31 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` 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
>