- From: Markus Lanthaler <markus.lanthaler@gmx.net>
- Date: Tue, 13 Aug 2013 17:48:12 +0200
- To: "'Arnaud Le Hors'" <lehors@us.ibm.com>, "'Pierre-Antoine Champin'" <pierre-antoine.champin@liris.cnrs.fr>
- Cc: <pierre.antoine.champin@gmail.com>, "'RDF WG'" <public-rdf-wg@w3.org>
On Tuesday, August 13, 2013 12:12 AM, Arnaud Le Hors wrote: > Bonjour Pierre-Antoine, > I've now gone through all your comments and updated the draft > accordingly. See below for further details. > > pierre.antoine.champin@gmail.com wrote on 07/02/2013 04:21:38 PM: > > > NOTE TO JSON-LD PEOPLE: there is a question for you at the very end > > of this message; you might want to read the last part "Meta-remark" > > /NOTE > > I haven't seen any response from our JSON-LD experts. My response is here: http://lists.w3.org/Archives/Public/public-rdf-wg/2013Jul/0027.html [...] Internet media type: > Per Andy's suggestion, I got rid of most of that section and > replaced it with a much simpler tex. Why is that appendix normative? >> Meta-remark: >> >> It would be nice if, instead of proposing an alterative format to >> JSON-LD we could propose a controlled subset of JSON-LD that meets >> the requirements that this format addresses. >> >> I understand that this format 1) has some advantages over JSON-LD >> (less variability, easy access to a given triple...), and 2) is >> already deployed in some applications. I'm not sure which one, of 1 >> or 2, is the strongest argument for publishing this note. > > 1 is definitely what motivates the use of RDF/JSON by some of my colleagues. > >> If this is >> 1, why not propose something with the same advantages, by compatible >> with JSON-LD? > >> For exemple, instead of > >> { "http://example.org/S": { >> "http://example.org/P": [ >> { "type": "uri", >> "value": "http://example.org/O" >> }, >> { "type": "bnode", >> "value": "_:b1" >> }, >> { "type": "literal", >> "value": "a literal" >> "lang": "a literal" >> }, >> { "type": "literal", >> "value": "a literal" >> "datatype": http://example.org/DT" >> } >> ] >> } >> } >> >> one could write >> >> { "http://example.org/S": { >> "@id": "http://example.org/S", >> "http://example.org/P": [ >> { "@id": "http://example.org/O" >> }, >> { "@id": "_:b1" >> }, >> { "@value": "a literal", >> "@language": "en" >> }, >> { "@value": "a literal", >> "@datatype": "http://example.org/DT" >> } >> ] >> } >> } >> >> As far as I can tell, this is valid JSON-LD, provided with the >> appropriate @context -- I would require a confirmation form JSON-LD >> experts, though... > > I'd like to hear it too. I did reply to that question already (see above). The only thing that's not supported is the top-level node index (the "http://example.org/S":). Other than that, everything works as expected. If there's just one top-level node, you won't have a problem because there's no need for an index. If you have more than one top-level node, you can index them by using a blank node property which is ignored by default when converting to RDF: { "@context": { "data": { "@id": "_:data", "@container": "@index" } }, "data": { "http://example.org/S": { "@id": "http://example.org/S", "http://example.org/P": [ { "@id": "http://example.org/O" }, { "@id": "_:b1" }, { "@value": "a literal", "@language": "en" }, { "@value": "a literal", "@type": "http://example.org/DT" } ] } } } Result when converting to N-Quads: http://bit.ly/14tPJLo > I even think that the JSON-LD subset could be made to look even > closer to the original format, for example by stating in the > implicit context that "lang" is equivalent to "@language", and > "datatype" to "@datatype" (but "value is a problem, sometimes > meaning "@id"; and sometimes "@value"). Right -- Markus Lanthaler @markuslanthaler
Received on Tuesday, 13 August 2013 15:48:45 UTC