W3C home > Mailing lists > Public > public-xg-webid@w3.org > October 2011

Re: comments to references

From: Henry Story <henry.story@bblfish.net>
Date: Fri, 28 Oct 2011 16:09:51 +0200
Cc: Dominik Tomaszuk <ddooss@wp.pl>, WebID Incubator Group WG <public-xg-webid@w3.org>, Jérôme Louvel <jerome.louvel@noelios.com>
Message-Id: <5E0291F8-7128-42EC-96A6-C908803EF676@bblfish.net>
To: Mischa Tuffield <mischa.tuffield@garlik.com>

On 28 Oct 2011, at 15:54, Mischa Tuffield wrote:

>>>> Now you want one more, that is not standard.
>>> It will be standard. It is going to be one of four official serializactions of RDF model (near RDFa, RDF/XML and Turtle[and N-Triples]). Additionally, it just optional serialization.
>>> But I'm not stubborn on this issue ;)
>> I think we should wait till they are standard or until we can prove a large number of people support it.
>> So earl implementations will help for that.
> Excuse me if I have caught the arse end of the conversation, but am sure that nearly all of he RDF libs/triplestores support turtle. 
> sesame, jena, virtuoso, 4store, redland, arc2, redstore, and so on must all support turtle.

yes, indeed. I think pretty much every rdf engine supports turtle. ( I would love n3 supports with graphs and rules and paths too... )

I think we were speaking of a new JSON rdf serialisation that was on the cards.... And so I think our motto initially has to be: implementations talk. As they say in the IETF: rough consensus and working code. And here I think people who contribute real WebIDs have a say. They need to argue their position, and show us that they are going to follow up on their words with large numbers of WebIDs. I am sure if they do people will be happy to adapt their code to the new serialisation. 

But for the moment we should make things simpler.

So for example I was talking to Jerome Louvel, who develops the RESTlet library. For people like that it is easy to add a WebID module if we support the well known X509 formats, because there is no need to add rdf parsers, and the code can be very small, and be added nearly inconspicuously into large authentication libraries, without having to argue for RDF parsers.  But if that is an argument, then soon it will be an argument for making one of those formats a MUST. Now this moves us away from semweb, but not very far. The people who would follow the link rel="alternative" or "see Also" or whatever would end up on a page where the information would be semwebish - a foaf file for example. 

But perhaps that is a can of worms not worth opening. But it is also hard to argue for having 5 different semweb formats and not the well known original certificate ones...


> Mischa

Social Web Architect

Received on Friday, 28 October 2011 14:10:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:39:47 UTC