Re: JSON-LD review

Hi Marios,
Thank you again for doing this analysis and forwarding it to the GLD WG.   Since we had a *lot* on our agenda, we'd like another week to review your comments & refresh the documents from the RDF WG.  Hadley is going to request a week's extension for our comments to the RDF WG on this important topic.

Please see the minutes from today's meeting when published -- we made some important progress vis a vis ORG and Data Cube vocabs.

Thanks again,
Bernadette Hyland

On May 9, 2013, at 5:12 AM, Marios Meimaris <m.meimaris@medialab.ntua.gr> wrote:

> Hello all, 
> 
> I'm sending this email to the members list as it is but a draft for the WG to briefly discuss before sending out an official response.
> 
> I went through the JSON-LD and JSON-LD Algorithms and API documents, the former in more detail than the latter. Overall, the JSON-LD specification is well-thought out and, from what I understand, has been the subject of many discussions between the group's members and people that actually use it. Therefore, it would be difficult to propose any major change in the document or in the way JSON-LD is structured. In any case, there don't seem to be any problems or limits to what can be stated or modelled with JSON-LD. The JSON-LD Processing Algorithms and API is a bit too verbose for its sake, and would probably benefit from a few algorithm/process visualizations for better readability.
> 
> I did not go as far as to check for grammatical or syntactical errors, but just a few comments I'm guessing an RDF inclined individual would make:
> 
> 1. JSON-LD defines a data model that is a superset of RDF. Even though the people of the group have provided RDF conversion     algorithms and guidelines, JSON-LD more or less caters for the same needs as RDF, so shouldn't it basically define the same model? It would seem a bit odd to provide more functionality with JSON-LD than with RDF in general, yet recommend both for Linked Data. At the very least, RDF should be expanded to match JSON-LD (but this would have implications to SPARQL as well).
> 
> 2. They are using the term 'IRI' solely, while GLD uses 'URI' to refer to the same thing. This isn't really important but it would be elegant if WGs shared the same terminology just to avoid any kind of ambiguity by external readers.
> 
> 3. They use the keyword '@id' to denote IRIs of resources within a JSON-LD document. Why not use '@iri' for consistency?
> 
> 4. The '@base' keyword is used to specify the base for relative IRIs:
> 
>> FEATURE AT RISK 1: @base keyword
>> Note: This feature is "at risk" and may be removed from this specification based on feedback. Please send feedback to public-rdf-comments@w3.org. For the current status see features "at risk" in JSON-LD 1.0
>> 
>> Support for the @base keyword might be removed from JSON-LD 1.0 if implementation experience reveals that the fact that a document may have multiple base IRIs is confusing for developers. It is also being discussed whether relative IRIs are allowed as values of @base or whether the empty string should be used to explicitly specify that there isn't a base IRI, which could be used to ensure that relative IRIs remain relative when expanding.
>> 
> When the value of @id is an empty string, it resolves to the document base. This base can be overwritten with the @base keyword. My opinion is that non-existence of a base IRI should be explicitly stated within the document, to avoid confusion and misinterpretation.
> 
> That's all for now, I have to apologise for not being able to participate in today's meeting as I will be on the road at the time.
> 
> Kind regards,
> Marios Meimaris
>