Re: Cross-Context JSON-LD Integration

> On Sep 7, 2015, at 12:18 AM, Ivan Herman <ivan@w3.org> wrote:
> 
> (Explicitly cc-ing Gregg, who knows JSON-LD better than many…)
>> On 03 Sep 2015, at 01:30 , Robert Sanderson <azaroth42@gmail.com <mailto: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 <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.
> 
> Actually… is this correct? 
> 
> My understanding is that setting the alias in a @context for "id" only means a one-directional mapping, ie, that all "id" properties will be mapped onto "@id". However, it does not (should not…) affect any explicit usage of "@id", which can be used unchanged and with no semantics changed. In other words, if an AS user continues to use "@id", AS systems will consume that as is. Of course it is true that AS systems may fail to understand "id" unless they process all @context-s, but that is probably true anyway if the AS system wants to use directly OA statements without turning the whole graph into a fully integrated RDF through conversion measures.

Yes, this is true for JSON-LD interpretation, however if clients depend on a particular serialization, and ‘id’ is used in some places, and ‘@id’ in others, they may not get what they expect at a surface level. Clients that care about this may choose to re-compact the JSON-LD to make it consistent. Always compacting transmitted JSON-LD with the context used will also prevent these issues.

> Bottom line is: I am not convinced we do have a problem. The only problem we may have is AS uses the term "id" for a different purpose. We would then have term collision, but that is not restricted to "id": it is a danger for *any* prefix-less terms; the only safe way of managing graph integration with JSON-LD without knowing the respective vocabularies is to use prefix-ed terms only. This is a general problem.
> 
> Gregg, do I miss something here?

I commented on this earlier in this thread, although it may not get through to all lists, unless someone specifically allows the message through. The “danger” comes if multiple contexts are put together, and some us the “@“ convention while others don’t. This is easily remedied through re-compaction, but that is probably not a practical issue. Contexts intended to document a particular vocabulary probably shouldn’t use such aliases, those intended for end-users may decide to do so, because of the convenience.

The main motivation for using “@“ keywords is to not tromp on the namespace when existing JSON is interpreted as JSON-LD, but for a virgin application, this may not be an issue. Are social web and AS contexts intended to be mixed together with other JSON and other contexts?

>> 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?  
> 
> The same holds as for "id'/"@id", actually.

This is a separate issue from the use of “@“. Note that including “type”/“@type” can significantly aid JSON-LD framing when the type of a property is ambiguous. I personally prefer to type entities, but in some cases it is excessively redundant. It’s really no different for JSON-LD than for RDF in general.

Gregg

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