- 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>
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