[foaf-protocols] WebID pre-alpha specification (uses RDFa)

[Bruno Harbulot]

On 14/07/10 15:55, Reto Bachmann-Gmür wrote:
> On Wed, Jul 14, 2010 at 3:39 PM, Henry Story<henry.story at gmail.com>  wrote:
>
>> Well if we have a standard a bit more generic that would allow us to transform
>> any syntax into semantics, then we would not even need to specify the format.
>>
>> I don't believe it to be impossible that we should reach such a state. Using mime
>> types, name spaces and some convention for finding an extractor of a document's semantics, it is quite possible to see that we could end up in a situation where
>> this could be done automatically.
>
> That's perfectly possible, we could omit everything format specific,
> foaf+ssl woul work between agents that can find a way to exchange rdf
> graphs. HTTP offers what we need for client and server to find the
> best format for communication.
>
> While I think a serialization format neutral protocol has advantages
> in terms of elegance especially when the dominance and general of
> formats changes, I believe the advance of guaranteeing
> interoperability solely assuming the parties speak http(s) is more
> important with the current state of development of the semantic web.

I'm not sure I completely follow the reasoning here.
Is this about the hope that one day, a semantic processor will be able 
to access any document and get its semantics automatically.
How can this work? I don't know much about GRDDL, but from what I 
understand, you need to provide at least the XSLT sheet for the 
transformation, otherwise, I don't really understand how any format (not 
known a priori) could be turned into RDF (at least with the vocabularies 
that match the ones we expect).

I don't see this as a universal solution, so I think we do need some 
common format(s). Even if there was a theoretical universal solution, it 
doesn't seem to be available in terms of implementation.



>> So as we don't want to wait for this world, we pragmatically specify a couple
>> of formats parsers SHOULD support.
>
> I think this is a bad compromise. SHOULD requirements mean according
> to rfc2119 "that there may exist valid reasons in particular
> circumstances to ignore a particular item, but the full implications
> must be understood and carefully weighed before choosing a different
> course.". A typical usage would be something like "Clients SHOULD
> inform the user if ..." this rule might be valid in most cases but
> particular situations might make the application objectively better if
> it violates the SHOULD-level requirement.
>
> No I agree that its enough to specify that a webid SHOULD be
> dereferenceable either as RDF/XML or a HTML+RDFA but I think the
> requirement for the consumer should be a MUST.
>
> When would a situation be that an application ants to choose a
> different course and thus be a reason for a SHOULD in the
> specification?
> - In a future situation a new format is supported by virtually all
> web-ids out there and the costs for additionally supporting rdfa and
> rdf/xml are high

I still think there should be a guarantee to find a common format that 
both the publisher and the verification agent support.

Let's take the example of French and German 3-pin mains plugs and 
sockets. Modern 3-pin plugs for electrical devices sold on the European 
continent can work in a French socket or in a German socket (at least).
Manufacturers can treat this area as a single market by shipping plugs 
that support both types of socket, because they know that houses in that 
area will support at least one of those two types of sockets.
If one of the houses in this area decides to use another type of socket, 
it's probably not illegal, but it won't be able to use any of the 
electrical devices sold on that market and will be hard to sell: 
practically, it doesn't work.


I think it barely makes sense to have only a 'SHOULD' on the provider 
side. It more or less implies to the provider: you are allowed not to 
support any of the formats that the verification agent must support, but 
if you do so, you have no guarantee that it will support your format 
(according to the same spec.), therefore your WebID might not be usable. 
The publisher would deserve the problems it gets.


I think by the time other formats become popular, we'll have 
FOAF+SSL/WebID v4.0 or so, so we can change that then. I support having 
a vision for the future, but making sure things work for the present is 
quite important too.


Best wishes,

Bruno.