Re: [JSON] Initial comments

Hi Thomas,

I'll reply in full later on with some examples and a better explanation, 
but for now there are a couple of quick points I wanted to address in 
your reply:

Thomas Steiner wrote:
> All agreed. But, where do you put subjects?

There are multiple ways to approach the subject side of things

  { "http://..": { foo: "bar" } }
  { "id": "http://..", "foo": "bar" }

or
  { "id": 123412, "foo": "bar" }
where you also provide a map to say you construct the subject with a 
template "http://example.org/users/@id"

>> To me, the above simply points to needing a way to specify @id's and some
>> kind of data transformation map for these objects, essentially a simple map
>> from property name to property URI
>>
>>  "name" -> "http://xmlns.com/foaf/0.1/name"
>>  "gender" -> "http://xmlns.com/foaf/0.1/gender"
> This sounds straight-forward, however, as soon as you start mixing
> ex:name and foaf:name (and this will happen), you need the concept of
> namespaces (call it CURIEs if you want). I have seen foaf.name or
> foaf_name in some of the proposed JSON formats (was it JRON?), and I
> fear, there's no way around sticking to the idea of namespace.

You don't actually need namespace/prefix/CURIE functionality, there's no 
reason why a property name can't have a colon in it..

   { "ex:name": "mr bob", "foaf:name": "bob" }

  "ex:name" -> "http://example.org/ont#name"
  "foaf:name" -> "http://xmlns.com/foaf/0.1/name"

another major reason for suggesting the map approach, is that often data 
which could be considered irrelevant is included in JSON, for example 
debugging data or status messages, when you take a map approach then you 
can simply not map those irrelevant properties, and when you put on your 
RDF goggles you won't see that irrelevant data.

>> The next question is whether that map needs to be in with the JSON, or
>> outwith it (in an external document) - again this seems like an easy design
>> trade-off to make, just as with CSS for HTML an external document makes a
>> lot of sense, especially when you consider the common JSON use-cases (like
>> twitter api), and it also allows bootstrapping on to existing data sources
>> via a Link header or suchlike.
> Not sure I get this, but I think, you're suggesting to introduce
> something like a @profile document as in RDFa, or at least a
> well-known URI where such document would be available, and not be
> touched unless the modification was downwards-compatible. I'm not
> against this idea, thinking of, e.g., well-known Link relations (e.g.,
> @rel="license").

If you take a quick look at JSON-Schema's approach:
   http://tools.ietf.org/html/draft-zyp-json-schema-03#section-4

Let's say we have "xx" which is the relation to the schema/map for this 
chunk of JSON, then one can do:

   Content-Type: application/json; xx=http://example.org/my-schema

or

   Link: <http://example.org/my-schema>; rel="xx"

or we could standardize "@xx" for inclusion inside JSON data which 
pointed to a map for use, or even embedded the map inside the data (as 
with JSON-LD).

>> Additionally, there is often a need to provide custom datatypes and to place
>> restrictions on values for validation and the like, as with xsd and owl,
>> which imho points to the need for something like JSON-Schema.
> And this is where most Web developers (in my humble opinion) will
> start to hate us. JSON is so successful because it limited itself to
> the things that are available in almost every programming language,
> arrays, integers, floats, booleans, objects (did I forget something?).

strings :p

> Introducing long ints, short ints, this kind of things, just makes
> things brittle, strictly tightened, SOAPish. The Web is just not like
> that.

Exactly, and I'm not suggesting we introduce those things in to JSON, 
indeed I'm suggesting "no-change" to JSON, rather that if one has in JSON:


{
   "id": "webr3",
   "name": "nathan",
   "public_key": { "modulus": "FDE4D6.....", "exponent": 65537 }
}

then in ones map they could have something like:

{
   "description": "A Person",
   "type": "object",
   "subject": "http://example.org/users/{id}#me",
   "properties": {
     "name": {
       "type": "string",
       "property": "http://xmlns.com/foaf/0.1/name",
       "domain": "http://xmlns.com/foaf/0.1/Person"
     },
     "public_key": {
       "type": "object",
       "property": "http://www.w3.org/ns/auth/cert#public_key"
       "range": "http://www.w3.org/ns/auth/rsa#RSAPublicKey",
       "properties": {
         "modulus": {
           "type": "string",
           "range": "xsd:hexBinary",
           "property": "http://www.w3.org/ns/auth/rsa#modulus",
         },
         "exponent": {
           "type": "integer"
           "property": "http://www.w3.org/ns/auth/rsa#public_exponent",
         }
       }
     }
   }
}

and then devs could use the good 'ol JSON, and when they wanted to put 
on the RDF goggles to see RDF, then they'd load the map against the data 
and get back:

  <http://example.org/users/webr3#me> a foaf:Person;
    foaf:name "nathan";
    cert:public_key [
      a rsa:RSAPublicKey;
      rsa:modulus "FDE4D6....."^^xsd:hexBinary;
      rsa:exponent 65537
    ] .

make sense?

Best,

Nathan

Received on Thursday, 24 February 2011 18:33:15 UTC