W3C home > Mailing lists > Public > public-rdfa-wg@w3.org > March 2010

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

From: Ivan Herman <ivan@w3.org>
Date: Fri, 5 Mar 2010 15:52:55 +0100
Cc: W3C RDFa WG <public-rdfa-wg@w3.org>
Message-Id: <D41238DB-979D-498D-8C5D-E64A2DCF3798@w3.org>
To: Mark Birbeck <mark.birbeck@webbackplane.com>

On Mar 5, 2010, at 15:38 , Mark Birbeck wrote:

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


Right. And I would also be happy to keep to profile if we can... that being said, what this means that if the HTML5 evolution does not allow for @profile (because it is not reintroduced) the @vocab term might not be ideal either...:-(

> 
>> [...]
>> 
>> 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'. :)
> 

True, and agreed. And I have no stake in the current RDF/JSON stuff:-) I am happy to take whatever is more widely used.

I guess my only point was to take some sort of a JSON encoding of RDF and not just a simply key-value pairs.
> 
> 
> 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.
> 

Great.

That being said: we still have to decide whether we _do_ need JSON... I for one would be happy to get rid of it here though, I must admit, these b...dy security issues make me think twice (and more...)

Cheers

Ivan

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


----
Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf







Received on Friday, 5 March 2010 14:52:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 04:55:06 GMT