W3C home > Mailing lists > Public > semantic-web@w3.org > September 2007


From: Benjamin Nowack <bnowack@semsol.com>
Date: Thu, 6 Sep 2007 14:19:06 +0200
To: cr <_@whats-your.name>
Cc: semantic-web@w3.org
Message-ID: <PM-GA.20070906141906.79F42.1.1D@semsol.com>

On 06.09.2007 00:59:55, cr wrote:
>{bnodeid: {prop: [{type: 'literal',value:"v"}]}}
>{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 Nowack
Received on Thursday, 6 September 2007 12:19:19 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 07:41:59 UTC