Re: Cross-Context JSON-LD Integration

Hi, folks–

Isn't part of the problem that we're trying to reuse generic JSON-LD 
names like "@id" and "@type"? If we had keywords that are more specific 
to the Web Annotation Data Model (or whatever spec), and mapped them in 
the context to the JSON-LD types, there wouldn't be as common a clash 
with other vocabularies.

It's not as if the terms "id"/"@id" or "type"/"@type" are used in the 
Web Annotation Data Model in a way that's uniquely or particularly 
intuitive for JS/JSON devs who aren't used to the RDF parlance.

(I might be totally off-base in this suggestion, but I thought I'd bring 
it up.)


Whatever we do, it's important that we do define a very limited set of 
@contexts for Web Annotation Data Model (preferably 1), and that it's 
the most intuitive for non-Linked-Data developers, for interoperability. 
While RDF/LD experts can easily whip up a custom context, asking JS 
developers to do so is the wrong optimization; as Gregg says, you need 
to understand the @context in order to mess around with it or with 
mixing vocabularies, and JS devs are the ones least equipped to do that 
without possibly introducing bad side effects.

I'm pleased to see the coordination between these groups. While we can't 
anticipate every possible combination with every vocabulary, we can 
anticipate how a likely set of combinations might ideally work together, 
like Web Annotations, ActivityStreams, and PROV-O. Hopefully, we can 
find a way to make them play nicely together.

Regards–
–Doug

On 9/3/15 10:42 AM, Gregg Kellogg wrote:
> My view has been that aliasing keywords should be left to an end user,
> and not a part of generally used contexts, for precisely this reason. If
> a particular application wants to use aliases, they can always
> re-compact the document with a new context that creates such aliases, as
> they’re the ones who will benefit from the aliases. Otherwise, as you
> note, unfortunate interactions when several contexts are used can get in
> the way.
>
> Really, any dependency for a JSON programmer that keys will have
> expected meanings when several contexts are used can be problematic. In
> the case of AS and Social Web you may coordinate so that a term such as
> “resource” will not be defined in each context, but to be generically
> reliable, make sure that data which is intermixed is expanded, and then
> compact using the set of contexts.
>
> Typically, using multiple contexts where you expect the resulting
> compact JSON-LD to reliably use terms needs to be done with knowledge of
> what is in the contexts being used.
>
> Gregg Kellogg
> gregg@greggkellogg.net <mailto:gregg@greggkellogg.net>
>
>> On Sep 2, 2015, at 4:30 PM, 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.
>>
>> 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
>

Received on Sunday, 6 September 2015 16:52:33 UTC