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

Re: Cross-Context JSON-LD Integration

From: Sarven Capadisli <info@csarven.ca>
Date: Fri, 4 Sep 2015 10:29:12 +0200
To: "public-socialweb@w3.org" <public-socialweb@w3.org>, Web Annotation <public-annotation@w3.org>, Linked JSON <public-linked-json@w3.org>
Cc: Robert Sanderson <azaroth42@gmail.com>, Frederick Hirsch <w3c@fjhirsch.com>
Message-ID: <55E95658.1060906@csarven.ca>
On 2015-09-03 01:30, Robert Sanderson 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


Robert suggested that I should mention the following Activity Streams 
pull request:

https://github.com/jasnell/w3c-socialwg-activitystreams/pull/204

It is an "example with a series of activities using multiple 
vocabularies": AS, OA, PROV-O.

The example is far from exhaustive, but rather focuses in one area where 
the terms are remixed, and to highlight some overlapping. It tries to 
represent the following activities:

* Eric writes a short note to be shared with his followers.
* After posting the note, he notices a spelling error. He edits the note 
and re-posts it.
* Later, Eric decides that the information in the note is incorrect. He 
deletes the note.

The @context sets base to AS, leaving OA and PROV-O as shorthand.

-Sarven
http://csarven.ca/#i
Received on Friday, 4 September 2015 08:29:45 UTC

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