RE: [Serialization] Integration and @id/@type

Got it. Too bad.

-----Original Message-----
From: Ivan Herman [mailto:ivan@w3.org] 
Sent: Thursday, September 03, 2015 10:36 AM
To: Tim Cole <t-cole3@illinois.edu>
Cc: Robert Sanderson <azaroth42@gmail.com>; W3C Public Annotation List <public-annotation@w3.org>
Subject: Re: [Serialization] Integration and @id/@type


> On 03 Sep 2015, at 17:15 , Timothy Cole <t-cole3@illinois.edu> wrote:
> 
> We've had some discussions on this list about the lack of serialization uniformity that implementers are certain to encounter when consuming annotations from multiple local implementations.  There's was mention of using json-ld framing to help normalize serialization.  Framing can be used to insert missing types, namespace keys and I think add back in the @ for id and type.  Would it be feasible/reasonable for this group to provide a sufficiently generic framing document (as we currently provide a context to be used with what looks like plain JSON serializations) and a separate, additional context document  to be referenced post-framing to facilitate sharing of annotations in a form compatible with other json-ld systems.  Or is unrealistic to make such a framing document sufficiently general and/or expect a framing step when integrating annotations with other json-ld systems. (I also haven't thought yet about going the other way, i.e., from a namespaced with @id/@type json-ld serialization to a  serialization that looks as much like plain JSON as possible.)

Unfortunately, I have to put on my W3C admin's hat on:-(

Framing has never been completed as a standard. And I believe the reason is that some details have not been finalized; it may be finalized at some point but we do not know. Ie, it is, or at least may become, a moving target. Which also means that we should not have any normative dependency on it…

In other words, while the @context document is (at least for the time being) reproduced in the document and would probably be considered as normative, framing could not be...

Quickly putting down the W3C admin's off...

> 
> -Tim Cole
> 
> -----Original Message-----
> From: Ivan Herman [mailto:ivan@w3.org]
> Sent: Thursday, September 03, 2015 12:00 AM
> To: Robert Sanderson <azaroth42@gmail.com>
> Cc: W3C Public Annotation List <public-annotation@w3.org>
> Subject: Re: [Serialization] Integration and @id/@type
> 
> Rob,
> 
> first of all, thanks for reaching out to the social web wg. It is good to do that.
> 
> For the essence: I wonder whether this is not a more general problem that I am not sure how we would avoid. The good and bad thing of the @context mechanism in JSON-LD is that it makes namespaces disappear, mainly because (alas! I would say) the concept of namespaces have become anathema in many circles. The practical consequence is that if there is a term in AS that is identical to OA (in the sense of the 'local' name!), and those are both mapped via the respective contexts to the full URI of the terms, we would have a clash when reading those files through some JSON-LD/SW aware tool. Isn't it the same issue, albeit more general, than what you refer to?
> 
> And, honestly, I am not sure what to do about it:-(
> 
> Ivan
> 
> 
>> On 02 Sep 2015, at 21:33 , Robert Sanderson <azaroth42@gmail.com> wrote:
>> 
>> 
>> A concern I have with the current proposed change to the JSON-LD context is the mapping of @id and @type to id and type, respectively.
>> 
>> Given just a single annotation, this poses no significant problem.  When compacting data according to the JSON-LD algorithm, it respects the id and type definitions as expected.
>> 
>> However, when we come to integrate annotations within other JSON-LD systems, we run into potential issues.  Notably, if we want to reuse the Collections class [1] from ActivityStreams in the Social Web WG work, and both contexts are provided, it will generate unexpected results.  The same would apply to any other use of our context in systems that did not also make the mapping from @id to id.... or worse used id or type for something other than the URI of the resource.
>> 
>> [1] http://www.w3.org/TR/activitystreams-core/#collections
>> 
>> For example, we have a requirement for collections of Annotations.  In order to use AS Collections, we would add our context document along with theirs and expect to produce something like:
>> 
>> {
>>  "@context": ["http://www.w3.org/ns/activitystreams", "http://www.w3.org/ns/oa.jsonld"],
>>  "@id": "http://example.org/collection1",
>>  "@type": "OrderedCollection",
>>  "totalItems": 1000,
>>  "orderedItems": [
>>    {
>>      "id": "http://example.org/anno1",
>>      "type": "Annotation",
>>      "body": "Some comment",
>>      "target": "http://www.example.com/index.html"
>>    }, ...
>>  ]
>> }
>> 
>> But /actually/ our context would override the activitystreams context, and the serialization would use "id" and "type" at the top level as well, where JSON based AS consumers would not expect those keys.
>> 
>> The context can be added at the Annotation level, however there is a known issue that when compacting / expanding, the context will disappear. See this thread:
>>    https://lists.w3.org/Archives/Public/public-linked-json/2014Jul/0011.html
>> 
>> My proposal is to discuss this issue with the Social Web WG and the Linked JSON Community Group, and see what the community at large thinks.  And that we should go with the broader consensus of what is best practice, rather than potentially making a cosmetic change that has the unintended side effect of limiting integration.
>> 
>> I'm happy to start that conversation if you all think it would be valuable?
>> 
>> Rob
>> 
>> --
>> Rob Sanderson
>> Information Standards Advocate
>> Digital Library Systems and Services
>> Stanford, CA 94305
> 
> 
> ----
> Ivan Herman, W3C
> Digital Publishing Lead
> Home: http://www.w3.org/People/Ivan/
> mobile: +31-641044153
> ORCID ID: http://orcid.org/0000-0003-0782-2704
> 
> 
> 
> 
> 
> 


----
Ivan Herman, W3C
Digital Publishing Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
ORCID ID: http://orcid.org/0000-0003-0782-2704

Received on Thursday, 3 September 2015 17:04:54 UTC