Re: [JSON] Tiny Proposal

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?

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

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

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

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

What about namespaces?

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?

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

> 7: add recognition for a special "@base" property who's value is an IRI 
> (relative IRI-ref resolution)

Doesn't this just duplicate "@vocab"?

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

>   {
>    "@vocab": "http://xmlns.com/foaf/0.1/",

How does this capture RDF namespaces?

I think that you are missing the type here.

>    "@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"?
Why not use { "@id" : "http://jondoe.example.org/me.jpg" } as the value here?
>    "homepage": "http://jondoe.example.org/",
>    "interest": "http://dbpedia.org/resource/Film",
>    "knows":  {
Why embed here?  Shouldn't Jane be a second top-level object?
>      "@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".
>     }
>   }


> 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?
... and many more issues.
>    "legalName": "Example Business, Inc.",
>    "page": [
>      "http://business.example.com",
>      "http://business.example.org/openinghours.html"
>    ],
>    "fn": "Example Business, Inc.",
>    "geo": {
>      "latitude": "49.0202626",
>      "longitude": "12.8407428"
>    },
>    "tel": "+49-12-3546789",
>    "url": "http://business.example.com",
>    "hasPOS": {
>      "@vocab": "http://purl.org/goodrelations/v1#",
>      "@type": "LocationOfSalesOrServiceProvisioning",
>      "@id": "#shop",
>      "hasOpeningHoursSpecification": [
>        {
>         "@type": "OpeningHoursSpecification",
>         "@id": "#mon",
>         "opens": "08:00:00",
>         "closes": "18:00:00"
>        },
>        {
>         "@type": "OpeningHoursSpecification",
>         "@id": "#tue",
>         "opens": "08:00:00",
>         "closes": "18:00:00"
>        },
>        {
>         "@type": "OpeningHoursSpecification",
>         "@id": "#wed",
>         "opens": "08:00:00",
>         "closes": "14:00:00"
>        },
>        {
>         "@type": "OpeningHoursSpecification",
>         "@id": "#thu",
>         "opens": "08:00:00",
>         "closes": "18:00:00"
>        },
>        {
>         "@type": "OpeningHoursSpecification",
>         "@id": "#fri",
>         "opens": "08:00:00",
>         "closes": "20:00:00"
>        },
>        {
>         "@type": "OpeningHoursSpecification",
>         "@id": "#mon",
>         "opens": "09:00:00",
>         "closes": "15:00:00"
>        }
>      ]
>    }
> 
> trade-offs and clarifications:
> 
>   - multiple values represented by an array
>   - blank nodes are objects with no "@id" (blank node identifiers not 
> supported)
>   - no provision for @language or @datatype
>   - when terms from multiple vocabularies are needed it requires people 
> to make their own custom vocab which includes aliases to terms in other 
> vocabularies. (having a single cachable vocab is lighter for network 
> though and easier to maintain)
> 
> I think that's about it..
> 
> Best,
> 
> Nathan
> 
> [1] http://json.org/
> [2] http://www.w3.org/2011/rdf-wg/wiki/TF-JSON#Sample_Graphs

peter

Received on Wednesday, 23 March 2011 18:51:45 UTC