W3C home > Mailing lists > Public > public-linked-json@w3.org > September 2015

Cross-Context JSON-LD Integration

From: Robert Sanderson <azaroth42@gmail.com>
Date: Wed, 2 Sep 2015 16:30:06 -0700
Message-ID: <CABevsUHZTur6L5uakPSQ=zYayQa6RnVX4Ga9Xj9pUELeF1t6mA@mail.gmail.com>
To: "public-socialweb@w3.org" <public-socialweb@w3.org>, Web Annotation <public-annotation@w3.org>, Linked JSON <public-linked-json@w3.org>, Frederick Hirsch <w3c@fjhirsch.com>
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
Received on Wednesday, 2 September 2015 23:30:35 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:18:46 UTC