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
