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

Nathan nathan at webr3.org
Tue Aug 3 11:21:45 CEST 2010

Kingsley Idehen wrote:
> Nathan wrote:
>> Henry Story wrote:
>>> On 3 Aug 2010, at 00:26, Kingsley Idehen wrote:
>>>>> RDF and semantics.   People will see how flexible it is as we use it.
>>>>> But frankly if that bothers you, then lets forget the spec.   
>>>> So this is an RDF spec? No RDF over emphasis or no spec?  I am 
>>>> saying: tone it down a little re. RDF, that's all.
>>> yes, sorry for cutting the discussion short. It is using the semantic 
>>> web standards, of which RDF semantics is a core (and evolving 
>>> piece_). This is what linked data is founded on, anything else that 
>>> goes that way is just going to reinvent the wheel.
>>> We use that and we use SPARQL, and the web.
>>> That does not mean that one cannot use any representation one wants 
>>> to - as long as it has a clear mapping to RDF, using GRDDL or 
>>> something like that.
>>> But please let's not start a discussion on words here. If people 
>>> can't deal with these distinctions it's to our advantage. Anything 
>>> they produce will just reinvent what we are doing, just less well.
>> Yup, 'structured data' or 'machine readable data' are both safe terms 
>> - one mention of RDF or even FOAF and masses of people go running and 
>> immediately shut off, whether we like it or not. Have tried, tested 
>> and seen this happen often in recent times.
>> However, the spec isn't the sales pitch, and if it is then something's 
>> vastly wrong - quite sure that <0.001% of people will hit the WebID 
>> spec as their first introduction, the vast majority will already know 
>> the idea and be checking the spec to implement, and further a big 
>> majority of those will be doing it because it's their job to do so, 
>> they've been told to do it, the client/boss requires it, or most 
>> likely because everybody else is, the users are begging for support 
>> and thus they need to support WebID too :p
>> The spec needs to be technically correct, if the correct technical 
>> decision is to write 'a representation in a machine readable format.' 
>> then that's the one, if it's 'a RDF representation.' because the 
>> protocol depends on a serialization of RDF then use that, but picking 
>> nice names for things for political / marketing reasons in a technical 
>> spec surely won't do - it's akin to calling +TLS 'website with 
>> padlock' - in a primer document maybe, not in a core spec though.
>> back to it then, what does WebID require to operate on the 
>> representation side? to function it has to be 'MUST xxxxxxx' what's 
>> the xxxxxxx and is it tightly defined enough to ensure the protocol 
>> can function globally? - do we have any agreement?
> Yes, but a real technical spec wouldn't and shouldn't negate HTTP's 
> essence.
> If you note, content negotiation is seen as a problem hence this 
> protracted discussion about data serialization formats.
> Content negotiation is the key to taking away the preoccupation with 
> specific data serialization formats via MUST statements.

yes, but you still need a MUST, even if it's "MUST return a 
representation in a machine readable format." - we can't really just let 
somebody return nothing, or an animated gif and expect it to work - we 
must specify something (even if it's not a specific serialization).

> Today, Web Browsers default to HTML, and this won't change re. WebID 
> protocol -- even without a MUST for HTML+RDFa.

indeed they do - if there is something to negotiate that is :) afaict 
most people outside of sem web space never touch content negotiation 
most of the time; hell even static html is rare nowadays it's virtually 
always script/cms controlled.

More information about the foaf-protocols mailing list