Re: [JSON] Tiny Proposal

Peter Frederick Patel-Schneider wrote:
> From: Nathan <nathan@webr3.org>
> Subject: [JSON] Tiny Proposal
> Date: Wed, 23 Mar 2011 13:14:00 -0500
> 
>> Hi All,
>>
>> Here's a tiny proposal:
>>
>> 1: Constrain JSON [1] to be an (optionally nested) sequence of one or 
>> more objects (where one, no enclosing [] is needed).
> 
> Do you mean here that no arrays are allowed at all?  Why?  Can't arrays
> turn into lists?

Yes arrays are allowed, as for lists how would one distinguish between 
multiple values and a list?

x y "a", "b", "c" .
x y ( "a" "b" "c" ) .

would both be
{
  "@id": "x",
  "y": ["a","b","c"]
}

One approach is to double wrap lists [["a","b","c"]], another is to 
infer from the range of a property.

>> 2: constrain object keys [I think that you mean names here] to be strings with no white space
> 
> Why?  IRIs should be able to handle (escaped) white space so I don't see
> what the problem is.

Specifically I'm referring to the "string" in
  pair
   string : value

from the JSON spec, less formerly this would be the "key" in the below:
{
   "key": "value"
}
JSON allows whitespace in the keys:
{
   "key foo bar": "value"
}

>> 3: add in IRI recognition as a value type (wrapped in quotes), likewise 
>> dateTime, date and time.
> 
> You mean add IRI, dateTime, date, and time to the syntactic categories
> of JSON?  Or do you mean to automagically detect these kinds of strings?

To application/rdf+json or whatever it would be, to the ABNF syntax or 
whatever else we use instead.

> What happens, then, for strings that happen to match the (relative) IRI
> recognizer but that aren't supposed to be IRIs?  (And, isn't "foo" a
> valid relative IRI?)

Yes it is, that's an issue.

>> 4: add recognition for a special "@id" property who's value is an IRI 
>> (sets the subject of the object when present)
> 
> "Subject of the object" isn't a useful RDF notion.  I think that you
> mean that the "@id" property is a special, syntactic property whose
> value becomes the IRI of the RDF node corresponding to the current JSON
> object, and also that the "@id" property doesn't generate an RDF triple.

exactly, yes.

>> 5: add recognition for a special "@vocab" property who's value is an IRI 
>> (when present, each key [name?] in that object is concatenated to the @vocabs 
>> value to form the IRI of the property)
> 
> What @vocabs value?  Is @vocabs something special for JSON?  

@vocab singular sorry, special to this proposed data/media type.

> Perhaps you mean that "@vocab" is something like a local base URL.

like @vocab in RDFa:
  http://www.w3.org/2010/02/rdfa/sources/rdfa-core/#A-vocab

> What about namespaces?

no namespace support proposed.

> What about the special properties?  Are these expanded this way?  (They
> can't be, of course.)  But then, why not just do something like have
> prefixes and then rdf:type can be treated just like any other property?

This was a specific trade-off, see:
 
http://www.w3.org/2011/rdf-wg/wiki/JSON_Syntax_Options#TERMs_.2B_Single_Vocab

>> 6: add recognition for a special "@type" property who's value is simple 
>> string (when present the value is concatenated to the @vocabs value to 
>> form the IRI of the rdf:type)
> 
> Why shouldn't "@type"'s value be an IRI, and be treated just like any
> other IRI value?   Similarly, "@vocab" and "@type" get very different
> treatments. (One generates a triple, the other doesn't.)

re IRI value, no reason why not.

noted about @type getting treated differently to @base, @vocab and @id, 
good point.

>> 7: add recognition for a special "@base" property who's value is an IRI 
>> (relative IRI-ref resolution)
> 
> Doesn't this just duplicate "@vocab"?

No, @vocab is specific to properties/keys and @type, as in RDFa. @base 
is for any relative IRI value.

>> For the Sample Graphs [2] this would produce:
> 
> I don't see that there is a "would" here.  In this proposal an RDF graph
> can translate into many JSON forms, even ignoring the order-independence
> of JSON.

s/would/could

>>   {
>>    "@vocab": "http://xmlns.com/foaf/0.1/",
> 
> How does this capture RDF namespaces?

it doesn't.

> I think that you are missing the type here.

well caught.

>>    "@id": "http://jondoe.example.org/#me",
>>    "nick": "Jonny",
>>    "givenname": "Jon",
>>    "family_name": "Doe",
>>    "depiction": "http://jondoe.example.org/me.jpg",
> Why doesn't this just generate the RDF value "http://jondoe.example.org/me.jpg"?

string vs RDF URI reference? this proposes that any IRI be treated like 
an RDF URI Reference - and suggesting that the rage of properties be set 
where needed.

> Why not use { "@id" : "http://jondoe.example.org/me.jpg" } as the value here?

you could, but no requirement to.

>>    "homepage": "http://jondoe.example.org/",
>>    "interest": "http://dbpedia.org/resource/Film",
>>    "knows":  {
> Why embed here?  Shouldn't Jane be a second top-level object?

No need, the nesting allows one to work with the JSON.parse'd data 
easily, in JS one would do:

var obj = JSON.parse(data);
print( obj.knows.name );

>>      "@type": "Person",
>>      "@id": "http://janedoe.example.org/#me",
>>      "name": "Jane Doe"
> There's no "@vocab" here to turn "name" into <http://xmlns.com/foaf/0.1/name".

yes, @vocab inheritance, I should have noted that, sorry.

>>     }
>>   }
> 
> 
>> and for the next example:
>>
>>   {
>>    "@vocab": "http://business.example.org/v/custom-gr-merged#",
>>    "@base": "http://business.example.org/openinghours.html",
>>    "@id": "#business",
> Why use a base here - the RDF/XML doesn't have it?
>>    "@type": "BusinessEntity",
> I don't think that this expands correctly.
>>    "label": "Example Business, Inc.",
> What happened to the language tag?

no language, no datatypes.

> ... and many more issues.

Indeed, but then it's not "full RDF in JSON", it's a certain common 
subset familiar to typical web developers accustomed to JSON and limited 
datatypes.

Note, perhaps I should have been more explicit, I'm not suggesting that 
this would be the only serialization we should produce, or even one of, 
it needs work, it's just an optional starting point to cover some 
specific requirements. Something like jTriples and Talis JSON/RDF would 
cover the round tripping and "RDF in JSON" requirements.

Best,

Nathan

Received on Wednesday, 23 March 2011 19:39:37 UTC