- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Tue, 06 Jul 2010 14:26:15 -0400
- To: Bruno Harbulot <Bruno.Harbulot@manchester.ac.uk>
- CC: Thomas Roessler <tlr@w3.org>, Tim Berners-Lee <timbl@w3.org>, Harry Halpin <hhalpin@w3.org>, foaf-protocols@lists.foaf-project.org, Ivan Herman <ivan@w3.org>, Ian Jacobs <ij@w3.org>, Jeffrey Jaff <jeff@w3.org>, www-archive <www-archive@w3.org>, Henry Story <henry.story@gmail.com>
Bruno Harbulot wrote: > > > On 06/07/2010 18:14, Kingsley Idehen wrote: >> Bruno Harbulot wrote: >>> Hi all, >>> >>> I'll start by a list of points that could be standardized (open >>> questions). >>> >>> First, on the authentication part: >>> >>> 1. Standardizing the representation format: RDF/XML, RDFa, N3? >>> >>> We do need a common format that representation consumers must be >>> able to understand and that representation publishers must >>> produce. We've had issues with the libraries we've used. I think >>> it's fair to say that existing RDF libraries can generally accept >>> RDF/XML more often or better than they accept RDFa or N3. >> >> Bruno, >> >> Data representation has to be negotiable. >> >> For sake of removing content negotiation requirement we should have >> defaults (or example/suggested representations) such as; HTML+RDFa, >> N3/Turtle, and RDF/XML. >> >> But we shouldn't bind the protocol to any of the above. >> > > Sorry, I disagree. Sure, negotiating the data representation is fine and > it should be encouraged. > However, when it comes to software agents, we need to be sure that the > format negotiation process will converge. Either the publishers > need to publish in at least one format that the software agents must > understand, or all software agents must be able to understand all the > possible formats the publishers may produce. (Here, the software agent, > is the client that gets the WebID document to verify the ID.) > > Imagine that: > - your WebID host can only produce HTML+RDFa and N3, > - the website to which you're trying to authenticate has a software > agent verifier that can only process RDF/XML. > > You can have a nice negotiation system (HTTP content-negotiation or > otherwise). If the implementation of the WebID host can only produce > HTML+RDFa and N3, and if the implementation of the verifier can only > process RDF/XML, the negotiation will not conclude. If the negotiation > doesn't result in a format that the verifier can understand, you won't > be able to log on. > > > Henry also said: >> Oddly enough, choice of formats are no longer an issue once one has >> understood the semantic web. GRDDL for example allows any xml format >> to be mapped automatically to rdf. This is for many computer >> scientists a very odd result. It took me some time to believe it. It >> is very liberating when understood. :-) > > This sounds fine in theory, but in practice, when it comes to > something that is to be processed by software agents (independently of > the programming language), we can't really make the assumptions that > these conversions will happen by magic and that implementations will > support it. > We need a common denominator regarding what the libraries will be able > to support. > As far as I'm aware, most RDF libraries support RDF/XML fairly well, > but when it comes to HTML+RDFa, N3, Turtle, support is uneven > depending on the library and the programming language. I mean negotiable in terms of HTTP based QoS. > > If we say something like "implementations may support any of these > formats", we'll potentially end up with two implementations that can > comply with the specification and be unable to talk to each other, > which would be a bad thing. But since QoS introduced HTTP content negotiation burden, the only option is to lay out some sample representations for higher level representation specific user agents while keeping the more powerful inbuilt HTTP feature at a slightly lower level. I hope I made myself a little clearer :-) Kingsley > > > Best wishes, > > Bruno. > -- Regards, Kingsley Idehen President & CEO OpenLink Software Web: http://www.openlinksw.com Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca: kidehen
Received on Tuesday, 6 July 2010 18:26:44 UTC