[Serialization] Integration and @id/@type

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