[foaf-protocols] First WebID Teleconference minutes (July 27th 2010)
kidehen at openlinksw.com
Tue Aug 3 11:31:30 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
>>>>>> 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
>> 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).
Human or Machine readable format depending on user agent request. We
can't really negate content negotiation when implementing an HTTP based
>> 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.
Browsers negotiate HTML because that's all they really know re. Web :-)
Improving HTTP appreciation cannot be harmful since its ubiquity and
"deceptively simple" design is why we have the World Wide Web.
President & CEO
More information about the foaf-protocols