Re: [JSON] Tiny Proposal

cc-RDF WG

Peter Frederick Patel-Schneider wrote:
> From: Nathan <nathan@webr3.org>
> Subject: Re: [JSON] Tiny Proposal
> Date: Wed, 23 Mar 2011 14:38:31 -0500
> 
>> 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"]
>> }
> 
> No!  This would be the second.  The first would be
> 
> {
>   "@id": "x",
>   "y": "a",
>   "y": "b",
>   "y": "c"
> }

Sadly that's valid JSON, but can't be parsed, as it would parse to:

{
  "@id": "x",
  "y": "c"
}

Overriding the previous two values, each object can only have one unique 
key.

>> One approach is to double wrap lists [["a","b","c"]], another is to 
>> infer from the range of a property.
> 
> Range of a property?  I thought that we were doing RDF, not RDFS.

Indeed we are, it's still a possibility though

>>>> 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"
>> }
> 
> Where is this from?  I don't see "key" anywhere important in JSON.

The "string" in the above pair ( string : value ) is commonly referred 
to socially as the "key" in a "key"/"value" pair, also property, 
attribute and so forth.

>> JSON allows whitespace in the keys:
>> {
>>    "key foo bar": "value"
>> }
> 
> Sure, but isn't this just
> 
> [ <...key%20foo%20bar> "value" ]

well we haven't defined if it is or is not :) we could also treat it as 
syntax sugar for multiple space separated keys, as with relLists in HTML 
rel="key foo bar".

>>>> 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.
> 
> But the point is when is something one of these values and when is it
> just a string.

indeed, I follow

>>> 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.
> 
> And the solution is?

don't have one yet I'm afraid, this is but one small idea to show a 
possible starting point for one spec which may handle some common use 
cases. essentially though, there is no distinction between "foo" a 
string and "foo" a relative-IRI, a problem we encountered recently in 
RDFa too, and managed to "fix" since we could simply specify the related 
attribute on the dom node as only taking relative IRIs and not any 'ol 
value.

>>>> 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.
> 
> Hmm.  Why not?

In all honesty, to preserve the beloved . notation in JSON.parse'd 
output, and because certain would be adopters (like the browser vendors 
and HTML5 WG) have a /real/ problem with the indirection, spanning way 
back to the HTML5/XHTML2.0 split and general hatred of @xmlns. Sigh, the 
issues run deep throughout the communities.

An alternative is:
 
http://www.w3.org/2011/rdf-wg/wiki/JSON_Syntax_Options#TERMs_.28with_colon_allowed.29

>>> 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
> 
> What other limitations are there in this proposal?  I think that it
> would be a good idea to list them all.

will do, if there's any point that is!

cheers,

Nathan

Received on Wednesday, 23 March 2011 20:27:24 UTC