Re: [JSON] Tiny Proposal

On Wed, 2011-04-06 at 21:16 -0400, Manu Sporny wrote:
> 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"
> }

Two issues, which I'm sorry if I've missed being addressed elsewhere.

1.  Why are you using "@" instead of "_"?   I guess it can still be used
with dot notation, it's just surprising-looking.  

2.  I think we need to allow for the context growing to be fairly
complicated, so let's make it an object with meaningful members, not
just a dictionary of EITHER terms or prefixes.

So, showing how we could use both JSON-LD CURIEs and terms in one
example:

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

I expect the value for @context could also just be a URI of a JSON
expression parsed to produce context object.   Maybe you said that
already.    

     -- Sandro

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

Received on Friday, 8 April 2011 04:59:02 UTC