[foaf-protocols] First WebID Teleconference minutes (July 27th 2010)

[Bruno Harbulot]

Hi,

(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 
one, though.


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 
this way).
      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 
framework used.



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 
(i.e. HTML).

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.



Best wishes,

Bruno.


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