[foaf-protocols] First WebID Teleconference minutes (July 27th 2010)
Bruno.Harbulot at manchester.ac.uk
Tue Aug 3 01:35:18 CEST 2010
(Sorry, jumping back into this thread, not replying to Seth specifically.)
I think there are two notions of "essential" here: one is for the
protocol to work (at the technical level), the other is for having any
chance to have some user adoption.
Having an HTML representation belongs to the second category. Whilst it
should be recommended, it's not actually a necessary part of the
technical specification. I'm all in favour of putting a SHOULD for this
I think the use cases (between RDF/XML and RDFa) would be as follows:
1. Publishing a WebID in RDF/XML is only really for technical users.
That's what we've been doing early on, it's fine, but that's also one of
the reasons FOAF (and RDF) may not have a good image everywhere. It's
just not good for the majority of potential users.
(The other use-case I can think of for this would be for a way to
create FOAF documents to represent things more in the domain more of
enterprise authentication (e.g. virtual organizations, groups, etc.),
perhaps administered via a separate interface; that's all arguable,
because there's no reason you couldn't have an HTML page for these too.)
2. Publishing in XHTML+RDFa (optionally in conjunction with RDF/XML with
content-type negotiation). That's fine (and RDF/XML would be redundant
Practically, it might not be so easy, considering the difficulties
regarding embedding RDFa into HTML using template engines. I'm not
saying it's impossible, I'm just saying the current tools don't
necessarily make it easy for web developers.
3. Publishing a page in HTML (without any RDF) and RDF/XML with
content-type negotiation. For this to work at the technical level, the
verification agent must request RDF/XML with a higher preference (which
is not a problem).
I think this case should definitely be allowed. I don't see a
problem with publishing a list of friends by putting "normal" HTML links
in a page, without necessarily having anything to do with RDF. It can
make it easier to produce both types of pages, depending on the web
While I think there should be 'MUST' requirements for elements of the
protocol that are required for the authentication mechanism to work, I
think a 'SHOULD' should be sufficient for the elements that will make
users adopt the services, on the basis that services that don't offer
that won't have users (and the guys who publish in RDF/XML only won't
make many friends anyway).
Essentially, I think a WebID provider MUST serve a representation that
can be processed by the verification agent, which is a machine
(otherwise it will just fail technically), and that it SHOULD serve a
representation that can be rendered in a human-readable way by a browser
Note that the 'SHOULD/RECOMMENDED' is still a fairly strong recommendation.
On a side-note, mandating an HTML representation for all WebID doesn't
necessarily make sense in some contexts, more specifically when
dereferencing isn't used. The verification agent (or the service that's
using it with its authorization components and others) could very well
cache the graphs and put them in an RDF store (or import it from an
explicitly trusted store). In this case, we're not necessarily talking
about representations, but of graphs directly. The WebIDs in such graph
stores could very well be valid without having anything to do with any
specific format (maybe not even RDF), but the notion of "compliant
WebID" shouldn't be affected by that.
On 02/08/2010 20:30, Seth Russell wrote:
> The human readable part of the WebID *is* an *essential* component of
> the thing. Without that essential component it is not a real WebID. We
> certainly can put in some minimal wording about partial compliance, so
> that if some hacker wants to implement something for a shortcut, that is
> fine, this specification will not stand in her way, or make her life
> harder. But she should be aware that she is not making a real fully
> compliant WebID.
More information about the foaf-protocols