Re: attempting to merge the 'vocab' and 'profile' documents

Hi Ivan,

Thanks for this -- it's a good place to start.

I have a couple of quite direct points to make, so excuse me if I just
take out those lines from your email and reference them here. It means
that I agree with the rest! :)


> [...]
>
> - I have taken over the JSON version of Mark but... after some thoughts
> I decided to make the JSON encoding a little bit more complicated:-(.

That's ok -- that was going to be my next step. :) I just didn't want
to muddy the waters by introducing too much.

One of the reasons I keep using the term 'profile' rather than
'default prefix mappings' is because as you have also concluded, there
could be a lot more in a profile than just tokens. I've been
experimenting with different properties and structures, and the work
is here, called RDFj:

  <http://code.google.com/p/backplanejs/wiki/Rdfj>

About halfway down or so, you'll see structures like this:

{
  "context": {
    "base": "<http://example.org/about>",
    "token": {
      "title": "http://xmlns.com/foaf/0.1/title",
      "maker": "http://xmlns.com/foaf/0.1/maker",
      "name": "http://xmlns.com/foaf/0.1/name",
      "homepage": "http://xmlns.com/foaf/0.1/homepage"
    }
  },
  "$": "<>",
    "title": "Anna's Homepage",
    "maker": {
      "name": "Anna Wilder",
      "homepage": "<>"
    }
}

This is a JSON object that represents RDF (beginning at '$'), but the
tokens, base URL and so on are defined in the object that begins
'context'.

These context objects can exist independently of the JSON object they
are describing in this example, and are what I would call 'profiles'.
(Actually, I should change that property name to 'profile'.)


> [...]
>
> So I used an RDF encoding in JSON
> that the community is considering at the moment[5]. That may give us
> more flexibility if we want to add other things into that profile file
> (see next item), though obviously more convoluted. I do not have very
> strong feelings about this, though, so we may decide to fall back on a
> simple, albeit closely tailored JSON definition (if we decide that we
> should keep JSON, that is).

I'm not so sure that RDF/JSON is used outside of returning results
from SPARQL end-points. As a generic format for RDF in JSON it's fine
-- but then it doesn't matter what structure you use, really.

But as a set of JSON objects that reflect RDF it's incredibly verbose.
I discuss this topic in the following blog-post, which also explains
why I devised an alternative, called RDFj.

  <http://webbackplane.com/mark-birbeck/blog/2009/04/20/rdfj-semantic-objects-in-json>

Note also that Jeni Tennison and David Reynolds have been looking in
detail at ways to describe APIs that sit on top of SPARQL (called
'linked-data-api'), and part of that work has involved looking at how
the JSON is returned. They don't use RDF/JSON either, and have instead
devised something that uses many of RDFj's ideas.

I'm not saying that you might not come up with another solution too!
All I'm trying to stress is that RDF/JSON is not at all the 'JSON
serialisation of choice for RDF'. :)

By the way, on RDFj and the linked-data-api work, I intend to bring
back some of the things we agreed in the linked-data-api, to RDFj. For
example, in RDFj I used '$' for an object's subject with a note to say
that could well prove confusing. In the linked-data-api we agreed that
'@' might be a better choice:

  <http://code.google.com/p/linked-data-api/wiki/DI_simple_resource>

At some point I'll bring that back across.

Anyway, that's merely to point out that there could well be
convergence on the format at some point soon, and I hope to also bring
this in to the JSON API work.

Regards,

Mark

--
Mark Birbeck, webBackplane

mark.birbeck@webBackplane.com

http://webBackplane.com/mark-birbeck

webBackplane is a trading name of Backplane Ltd. (company number
05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
London, EC2A 4RR)

Received on Friday, 5 March 2010 14:39:05 UTC