- 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