Re: [web-annotation] Is a JSON-LD library required?

> On 25 Feb 2016, at 11:24, Maik Riechert <notifications@github.com> 
wrote:
> 
> I've just discovered this series of specs and am very delighted. It 
seems to be the missing pieces to make (open) annotations a reality.
> 
> One question though: Does an annotation service linked via a Link 
header with http://www.w3.org/ns/oa#annotationService always return 
JSON-LD with a fixed structure for the core terms etc? Said 
differently: Do I need a JSON-LD library to understand the basic data 
contained within the annotations? I hope not! But note that 
associating a JSON-LD context to a profile is not enough to enforce a 
certain JSON structure.
> 
> I'm working on annotations for geospatial datasets, so obviously 
we'd include some domain-specific data as well in an annotation, for 
example a bounding box within the dataset for which the annotation 
applies. And I could imagine that this would result in a new JSON-LD 
domain-specific profile that again guarantees a certain structure, 
with the goal of not forcing users to have JSON-LD parsers at hand if 
they want to understand the additional geospatial information.
> 
> 

The intention is that the user would not need to use a JSON-LD 
library/tool; the structure of annotations are fully described in the 
model and protocol documents. JSON-LD comes to the fore if the user 
wants to explicitly combine the annotation with other RDF/LOD based 
(or simply JSON-LD based) environments.

Indeed, the profile is not enough to enforce a certain JSON structure.
 Unfortunately, the JSON-LD frame specification is not a 
Recommendation; nevertheless, we're also considering to provide an 
informal annex in one of the documents that would describe such 
frames. That is a step forward to enforce those structures.






-- 
GitHub Notification of comment by iherman
Please view or discuss this issue at 
https://github.com/w3c/web-annotation/issues/180#issuecomment-188716348
 using your GitHub account

Received on Thursday, 25 February 2016 10:36:38 UTC