Re: Cross-Context JSON-LD Integration

Doug,

I am not sure what you're proposing. Can you propose an alternative to "type" and "id" that would feel more natural for JSON users? I must admit I do not see this problem with, eg, the term "type", which is really not an RDF specific notion...

(you are right that @context can map, ie, hide just about any term...)

Ivan

---
Ivan Herman
Tel:+31 641044153
http://www.ivan-herman.net

(Written on mobile, sorry for brevity and misspellings...)



> On 6 Sep 2015, at 18:52, Doug Schepers <schepers@w3.org> wrote:
> 
> 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 18:03:15 UTC