Re: RDF/JSON

On 06.09.2007 00:59:55, cr wrote:
>{bnodeid: {prop: [{type: 'literal',value:"v"}]}}
>vs
>{prop: 'v'}

Ah, that looks rather compact. Let's see if I fully understood
your format (didn't really want to download your platform, sorry):

a doc/graph (or other resource container) is a simple array?
[
 {...},
 {...},
 {...}
]

a resource is a json object of the form
{
   "uri": "http://...#alec",
   "http://xmlns.com/foaf/0.1/name": "Alec Tronnick",
   "http://xmlns.com/foaf/0.1/knows": {"uri": "http://...#john"}
}
or for multiple objects
{
   "uri" : "http://...#alec",
   "http://xmlns.com/foaf/0.1/name": "Alec Tronnick",
   "http://xmlns.com/foaf/0.1/knows": [
      {"uri": "http://...#john"},
      {"uri": "http://...#bob"}
   ]
}
?

Yes, I can see some benefits.

I have two questions:
How do you define a bnodeID and re-use it, so that you can avoid
duplication? Do you set the "uri" key to "_:b1"? (In that case
the key name should prolly be changed to "id" or something similar)

How do you get the prop values of a known resource w/o
having to loop through the array? This is one of the 
advantages I see in the RDF/JSON proposal, being able to do 
   name = resources["http://...#alec"]["http://.../name"][0]["value"]
without the need for FORs, IFs or structure checks.


Let's assume there's a way to combine the two approaches, e.g. by 
keeping  resource IDs as root keys for direct access, but to allow
the native object format (as I can see the utility of natively 
typed objects):

var doc = {
   "resources": {
      "_:bn1": {
         "http://xmlns.com/foaf/0.1/name": [
            "Alec Tronnick"
         ],
         "http://xmlns.com/foaf/0.1/knows": [
            {"id": "_:john"},
            {"id": "http://...#bob"}
         ]
      },
      "_:john": {
         "http://xmlns.com/foaf/0.1/name": [
            "John Doe"
         ]
      }
   } 
}

(I kept "object(s) are always arrays" as I found
approaches with "object might be array or value" a bit
annoying to work with.) The approach above should work 
fine for many resource descriptions. The problem,
however, are cases where literals have types that go 
beyond JSON's built-ins, e.g. "foo"^^ex:someDatatype,
or have a language facet. This information could not 
be expressed in a compact serialisation. 

I plan to go for the proposed RDF/JSON in my toolkit as 
I haven't seen a format that's easier to produce and/or
to consume while supporting any structures that might 
come out of an RDF store. The previous version had
different output options for different use cases, and I
guess I'll keep it that way. But I'm happy to change
the default output to some agreed-on format, and
RDF/JSON is a nice candidate, I'd say.


Benjamin

--
Benjamin Nowack
http://bnode.org/

Received on Thursday, 6 September 2007 12:19:19 UTC