W3C home > Mailing lists > Public > public-annotation@w3.org > August 2015

Re: JSON-LD serialization and linked data support

From: Frederick Hirsch <w3c@fjhirsch.com>
Date: Thu, 13 Aug 2015 19:42:53 -0400
Cc: Robert Sanderson <azaroth42@gmail.com>, Ivan Herman <ivan@w3.org>, W3C Public Annotation List <public-annotation@w3.org>
Message-Id: <D3FBED6E-2440-4EDF-8F28-A3BF601EBC16@fjhirsch.com>
To: t-cole3@illinois.edu
Tim's questions seem a good place to continue the discussion, can somebody concerned with the use of JSON-LD answer these questions?

I would hate to see the WG spin into a long discussion and JSON-OA work effort only to discover that we are close to what James was suggesting, which is to scope  our usage of JSON-LD to what it is practical for our use (which I thought we had done)

To be honest, I'm not sure why @ signs are frightening, aren't developers used to various syntax items in languages etc and won't this all be hidden from end-users (and even most developers with libraries)?

regards, Frederick

Frederick Hirsch
Co-Chair, W3C Web Annotation WG

www.fjhirsch.com
@fjhirsch

> On Aug 13, 2015, at 2:09 PM, Timothy Cole <t-cole3@illinois.edu> wrote:
> 
> Setting aside for a moment how best to express the individual roles of bodies and targets in a multi-Body/Target Annotation, what are the shortcomings of how we serialize the rest of our data model in JSON-LD? 
>  
> ·         We have improved our @context document such that we know we can get rid of the '@' symbol on keys almost entirely if we want. 
> ·         We have unresolved questions (raised I think by Ivan?) about when type is MUST, SHOULD, and MAY appear.  Can we discuss this issue? If we pare down how often type is required, are we okay? Alternatively, given how frequently it appears, would people be more comfortable with a different key than 'type'? (I have no idea what might work better, but thought I should ask.)
> ·         Is there significant discomfort with having to do "body" : { "id" : "http://example.org/Body1" } rather than just "body" : "http://example.org/Body1" ?  If so, we could perhaps revisit the tradeoff of adding hasTextBody instead of relying solely on hasBody. 
>  
> What else about JSON-LD examples in the current Data Model are developers on the list finding unnatural? Is there anything in serializations of our current data model other than @context that requires JSON-LD tools?  
>  
> If JSON-LD serialization of the rest of the data model is generally in good shape now that we know more about how to use @context, then I would suggest we can find an approach to the body/target role issue that does not require a whole new JSON serialization.  (Attractive as it is from a RDF-based data modeling perspective, I for one am willing to accept that the Role Assignment approach is probably not it.)
>  
> But maybe the JSON-LD serialization of our current Data Model has more problems than have been surfaced on the list to date?
>  
> -Tim Cole
>  
>  
> From: Robert Sanderson [mailto:azaroth42@gmail.com] 
> Sent: Thursday, August 13, 2015 12:22 PM
> To: Ivan Herman <ivan@w3.org>
> Cc: Frederick Hirsch <w3c@fjhirsch.com>; W3C Public Annotation List <public-annotation@w3.org>; Tim Cole <t-cole3@illinois.edu>
> Subject: Re: JSON-LD serialization and linked data support
>  
>  
>  
> On Thu, Aug 13, 2015 at 9:08 AM, Ivan Herman <ivan@w3.org> wrote:
>> 
>> > Here comes Paolo's proposal (at least the way I understand it): let us *replace* the JSON-LD serialization with a dedicated JSON serialization of our model. Ie, we drop the -LD *from the syntax* (but that does not mean dropping Linked Data) and we may replace it with -OA to yield something like JSON-OA.
>> >
>> > There is no real interoperability issue: we drop JSON-LD, and we require JSON-OA to be the interchange format; for Linked Data aware systems there is a processor that maps this the internal representation of RDF, whereas non-Linked Data aware systems can use that particular JSON dialect only.
>  
>  
> I'm sorry Ivan, maybe I'm completely misunderstanding you, but I can't reconcile "we require JSON-OA [which is not an RDF serialization] to be the interchange format" with "Annotation systems are able to export their data into RDF at their heart's content."
>  
> So our special syntax would be required, and all other syntaxes optional? And you think that anyone would implement these optional, by definition more complex, syntaxes, that are not required and not used to transfer information between annotation clients and servers?  
>  
> Rob
>  
>> > In fact, this is not so far off from what Rob proposed in [1]:
>> >
>> > I think it's the complete opposite, actually. You are proposing to have an abstract model with no practical interoperability with linked data systems,
>> 
>> No I am not.
>> 
>> > the core of which is a new JSON format,
>> 
>> No I am not. The core is the model, with a specific serialization thereof.
>> 
>> > that any linked data system needs to revert back to something it can deal with via special code.
>> 
>> No I am not. Annotation systems are able to export their data into RDF at their heart's content.
>  
>  
> 
>  
> -- 
> Rob Sanderson
> Information Standards Advocate
> Digital Library Systems and Services
> Stanford, CA 94305
Received on Thursday, 13 August 2015 23:43:22 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:39 UTC