Re: [JSON] Tiny Proposal

On 03/23/2011 02:51 PM, Peter Frederick Patel-Schneider wrote:
>> 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?

I believe Nathan means no "enclosing arrays", meaning, this syntax is
not supported in the proposal:

[{}, {}, {}]

rather, this syntax is used:

{}

Also - we can talk about arrays as object value's eventually, but for
the moment, let's not talk about them and say that they're not part of
the proposal. That is not to say that we won't eventually talk about
them, but people are already divided about how to use [] syntax so let's
not go there right now, but try to get to the heart of this proposal.

So, for now, arrays are not supported (but will most likely be in the
future).

>> 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.

What Nathan was talking about was probably this:

"foo bar": "baz"

would result in two triples:

<> foo "baz" .
<> bar "baz" .

Yes, we could support escaped whitespace in IRIs, but let's not talk
about IRIs as object keys yet. We will eventually talk about IRIs as
object keys, but lets not do it right now as it muddies the waters.
Also, JSON developers are not used to using IRIs as object keys in JSON.
That is, this is fairly foreign to JSON developers:

"http://xmlns.com/0.1/foaf/name": "Peter Frederick Patel-Schneider"

but this is acceptable and common:

"homepage": "http://example.com/pages/pfps"

>> 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? 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?)

I believe Nathan mean "automagic detection", but let's not talk about
doing this just yet for the purposes that you outline above. Therefore,
there is no automagic IRI detection.

>> 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.

That is correct - that is what Nathan was proposing, afaict.

He was not saying "subject of the object" in the sense of "RDF object",
he was saying in the sense of "JSON object". So the "@id" is used inside
of a JSON object as a key to specify the subject, which is the value of
the "@id" key.

>> 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?
> 
> Perhaps you mean that "@vocab" is something like a local base URL.

Let's not go down the @vocab-only route as a solution - the issues with
this approach are outlined below in the response from Peter.

> What about namespaces?

Yes, they are an issue w/ this approach.

> 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?

Yes, also problematic and you are basically suggesting that we use
CURIEs in object keys (which I'd love to see), but let's not go there
right now. Let's stay with something simpler, like "terms" and a
"@context". That is, something like this:

{
   "@context": {"name": "http://xmlns.com/foaf/0.1/name"},
   "name": "Peter Frederick Patel-Schneider"
}

>> 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.)

@types value could be an IRI, or we could expand it from a @context if
we had such a thing. That is - @type is expanded from the @context if
one is available, or it is an IRI.

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

Let's not go here just yet. We can remove this an not affect the basic
proposal.

>> 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.

Yes, there can be multiple JSON serializations for the same set of RDF
triples. That is not an inherently good or bad thing.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: The PaySwarm Vocabulary
http://digitalbazaar.com/2011/03/31/payswarm-vocab/

Received on Thursday, 7 April 2011 01:16:51 UTC