Fwd: JSON-LD Feedback
Ian Davis
cc'd here for public discussion)
Hi all,
Nice to see more work on JSON serialisations for RDF. I have some
feedback on some possible flaws or gotchas with the format as
specified which you might find useful. This is only from a cursory
reading of the spec at http://json-ld.org/spec/latest/ dated 14 Oct,
so apologies if there are clear answers in there already.
Imagine a developer receives the following 5 responses from 5
different requests. What is the single piece of javascript
that can be written to find the foaf:name of the resource that works with all 5?
r1 = {
"#": { "name": "http://xmlns.com/foaf/0.1/name" },
"a": "foaf:Person",
"name": "Manu Sporny",
}
r2 = {
"#": { "foaf": "http://xmlns.com/foaf/0.1/" },
"a": "foaf:Person",
"foaf:name": "Manu Sporny",
}
r3 = {
"#": { "__vocab__": "http://xmlns.com/foaf/0.1/" },
"a": "foaf:Person",
"name": "Manu Sporny",
}
r4 = {
"#": { "f": "http://xmlns.com/foaf" },
"a": "foaf:Person",
"f:/0.1/name": "Manu Sporny",
}
r5 = {
"a": "foaf:Person",
"http://xmlns.com/foaf/0.1/name": "Manu Sporny",
}
Given the string replacement rules of the strings in the context,
what ntriples does the following map to?
{
"#": { "fo": "http://example.org/fo/", "foafname":
"http://xmlns.com/foaf/0.1/name" },
"a": "foaf:Person",
"foafname": "Manu Sporny",
}
How can I express the following triples in JSON-LD:
<http://example.org/foo1> <http://example.org/label> "foo@ex"
<http://example.org/foo2> <http://example.org/label> "foo@ex"@en
<http://example.org/foo3> <http://example.org/label> "foo^^xsd:string"
<http://example.org/foo4> <http://example.org/label> "foo^^xsd:string"@en
<http://example.org/foo5> <http://example.org/label> "foo@en"^^xsd:string
<http://example.org/foo6> <http://example.org/label>
"foo^^xsd:string"^^xsd:string
What ntriples are represented by the following:
{
"#": { "label": "http://example.org/label" },
"a": "foaf:Person",
"label": "foo@ex@en",
}
{
"#": { "label": "http://example.org/label" },
"a": "foaf:Person",
"label": "foo^^xsd:date@en",
}
Cheers,
Ian
Manu Sporny
> Nice to see more work on JSON serialisations for RDF. I have some
> feedback on some possible flaws or gotchas with the format as
> specified which you might find useful. This is only from a cursory
> reading of the spec at http://json-ld.org/spec/latest/ dated 14 Oct,
> so apologies if there are clear answers in there already.
Thanks for the feedback, Ian - much appreciated. Answers to your
questions below:
> Imagine a developer receives the following 5 responses from 5
> different requests. What is the single piece of javascript
> that can be written to find the foaf:name of the resource
> that works with all 5?
Hmm, that's an interesting take on JSON-LD - I wouldn't expect people to
work with JSON-LD directly without normalizing it first. I was assuming
that JSON-LD would fit in with something like the RDFa API:
http://www.w3.org/TR/rdfa-api/
That is, there will be a triple/quad store backing this in some way (in
the browser or in the application). If you want to work with JSON-LD
data, you MUST normalize it, otherwise you're asking for trouble. I'll
describe, using N-Triples the output you get below by normalizing the
JSON-LD:
> r1 = {
> "#": { "name": "http://xmlns.com/foaf/0.1/name" },
> "a": "foaf:Person",
> "name": "Manu Sporny",
> }
_:bnode1
<http://www.w3.org/1999/02/22-rdf-syntax-ns#type>
"foaf:Person".
_:bnode1
<http://xmlns.com/foaf/0.1/name>
"Manu Sporny".
Note that the "foaf:Person" bit above would be interpreted as a plain
literal since there was no mapping for "foaf" provided.
> r2 = {
> "#": { "foaf": "http://xmlns.com/foaf/0.1/" },
> "a": "foaf:Person",
> "foaf:name": "Manu Sporny",
> }
_:bnode2
<http://www.w3.org/1999/02/22-rdf-syntax-ns#type>
<http://xmlns.com/foaf/0.1/Person> .
_:bnode2
<http://xmlns.com/foaf/0.1/name>
"Manu Sporny".
> r3 = {
> "#": { "__vocab__": "http://xmlns.com/foaf/0.1/" },
> "a": "foaf:Person",
> "name": "Manu Sporny",
> }
_:bnode3
<http://www.w3.org/1999/02/22-rdf-syntax-ns#type>
"foaf:Person" .
_:bnode3
<http://xmlns.com/foaf/0.1/name>
"Manu Sporny".
Note that the "foaf:Person" bit above would be interpreted as a plain
literal since there was no mapping for "foaf" provided.
> r4 = {
> "#": { "f": "http://xmlns.com/foaf" },
> "a": "foaf:Person",
> "f:/0.1/name": "Manu Sporny",
> }
_:bnode4
<http://www.w3.org/1999/02/22-rdf-syntax-ns#type>
"foaf:Person" .
_:bnode4
<http://xmlns.com/foaf/0.1/name>
"Manu Sporny".
Note that the "foaf:Person" bit above would be interpreted as a plain
literal since there was no mapping for "foaf" provided.
> r5 = {
> "a": "foaf:Person",
> "http://xmlns.com/foaf/0.1/name": "Manu Sporny",
> }
_:bnode5
<http://www.w3.org/1999/02/22-rdf-syntax-ns#type>
"foaf:Person" .
_:bnode5
<http://xmlns.com/foaf/0.1/name>
"Manu Sporny".
Note that the "foaf:Person" bit above would be interpreted as a plain
literal since there was no mapping for "foaf" provided.
> Given the string replacement rules of the strings in the context,
> what ntriples does the following map to?
>
> {
> "#": { "fo": "http://example.org/fo/", "foafname":
> "http://xmlns.com/foaf/0.1/name" },
> "a": "foaf:Person",
> "foafname": "Manu Sporny",
> }
_:bnode6
<http://www.w3.org/1999/02/22-rdf-syntax-ns#type>
"foaf:Person" .
_:bnode6
<http://xmlns.com/foaf/0.1/name>
"Manu Sporny".
Note that the "foaf:Person" bit above would be interpreted as a plain
literal since there was no mapping for "foaf" provided.
Unfortunately, I haven't specified the Property and Object processing
rules, but this is the basic algorithm:
When processing a property or an object:
1. Check for a non-escaped ':' character, if it exists split on
that character and see if the left-most item exists in the
context. If it does, replace it and the colon with the
mapping and generate an IRI.
2. If a ":" character doesn't exist, check for the entire value,
including any escape characters, for an entry in the context
map, if the entire entry exists in the context map, replace it
with the mapping and generate an IRI.
3. Otherwise, take the entire value and generate an IRI if
processing a property. If processing an object literal and
the value is not encapsulated in '<' and '>' characters, it
is a plain literal, otherwise it is an IRI.
I think that's the algorithm, but just wrote it down for the first time,
so it might be wrong.
> How can I express the following triples in JSON-LD:
>
> <http://example.org/foo1> <http://example.org/label> "foo@ex"
{
"@": "<http://example.org/foo1>",
"http://example.org/label": "foo\@ex"
}
> <http://example.org/foo2> <http://example.org/label> "foo@ex"@en
{
"@": "<http://example.org/foo2>",
"http://example.org/label": "foo\@ex@en"
}
> <http://example.org/foo3> <http://example.org/label> "foo^^xsd:string"
{
"@": "<http://example.org/foo3>",
"http://example.org/label": "foo\^^xsd:string"
}
or
{
"@": "<http://example.org/foo3>",
"http://example.org/label": "foo\^\^xsd:string"
}
Haven't quite settled on how to handle that one - we really only need
the first escape character, but we may want to say that "^" SHOULD be
escaped at all times. Implementations only need to detect the first "^".
> <http://example.org/foo4> <http://example.org/label> "foo^^xsd:string"@en
{
"@": "<http://example.org/foo4>",
"http://example.org/label": "foo\^\^xsd:string@en"
}
> <http://example.org/foo5> <http://example.org/label> "foo@en"^^xsd:string
{
"@": "<http://example.org/foo5>",
"http://example.org/label": "foo\@en^^xsd:string"
}
> <http://example.org/foo6> <http://example.org/label>
> "foo^^xsd:string"^^xsd:string
{
"@": "<http://example.org/foo6>",
"http://example.org/label": "foo\^\^xsd:string^^xsd:string"
}
or
{
"@": "<http://example.org/foo6>",
"http://example.org/label": "foo\^^xsd:string^^xsd:string"
}
For the same reasons listed above - haven't settled on escaping data
typing characters.
> What ntriples are represented by the following:
>
> {
> "#": { "label": "http://example.org/label" },
> "a": "foaf:Person",
> "label": "foo@ex@en",
> }
_:bnode7
<http://www.w3.org/1999/02/22-rdf-syntax-ns#type>
"foaf:Person" .
_:bnode7
<http://example.org/label>
"foo@ex"@en.
Note that the "foaf:Person" bit above would be interpreted as a plain
literal since there was no mapping for "foaf" provided.
For language tags, I think we should always split on the last '@' in a
character sequence - it would "fix" bad markup like the above, however,
we may choose to do it the other way because it would surface markup
issues like the above sooner.
> {
> "#": { "label": "http://example.org/label" },
> "a": "foaf:Person",
> "label": "foo^^xsd:date@en",
> }
Ouch... this one hurt my brain, I think this is the output per the
current (unspec'd) processing algorithm for objects:
_:bnode8
<http://www.w3.org/1999/02/22-rdf-syntax-ns#type>
"foaf:Person" .
_:bnode8
<http://example.org/label>
"foo"^^<xsd:date@en>.
Note that the "foaf:Person" bit above would be interpreted as a plain
literal since there was no mapping for "foaf" provided.
Since you didn't specify a mapping for xsd:, but the datatype specifier
"^^" was specified correctly, you'd get a typed literal, but it isn't
what you would want. If you had this markup:
{
"#": { "label": "http://example.org/label",
"xsd": "http://www.w3.org/2001/XMLSchema#"},
"a": "foaf:Person",
"label": "foo^^xsd:date@en",
}
you would have had this:
_:bnode8
<http://www.w3.org/1999/02/22-rdf-syntax-ns#type>
"foaf:Person" .
_:bnode8
<http://example.org/label>
"foo"^^<http://www.w3.org/2001/XMLSchema#date@en>.
I think we have to have a rule that says that the processing order is
"search for typed literal first", then "search for language tag" when
determining whether you have a typed literal or a plain literal w/ a
language tag.
Thanks for the feedback Ian, I hope the answers above clarify the intent
of the JSON-LD spec. I've logged a few more issues to make sure that
these bugs in the spec are addressed:
http://github.com/digitalbazaar/json-ld/issues/#issue/1
http://github.com/digitalbazaar/json-ld/issues/#issue/2
http://github.com/digitalbazaar/json-ld/issues/#issue/3
http://github.com/digitalbazaar/json-ld/issues/#issue/4
http://github.com/digitalbazaar/json-ld/issues/#issue/5
-- manu
--
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: Making Payments Frictionless, Saving Journalism
http://digitalbazaar.com/2010/09/12/payswarm-api/