RE: JSON-LD serialization and linked data support

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" : "" } rather than just "body" : "" ?  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 [] 
Sent: Thursday, August 13, 2015 12:22 PM
To: Ivan Herman <>
Cc: Frederick Hirsch <>; W3C Public Annotation List <>; Tim Cole <>
Subject: Re: JSON-LD serialization and linked data support




On Thu, Aug 13, 2015 at 9:08 AM, Ivan Herman < <> > 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?  




> 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 18:12:02 UTC