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

[Kingsley Idehen]

Nathan wrote:
> 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).

Human or Machine readable format depending on user agent request. We 
can't really negate content negotiation when implementing an HTTP based 
protocol :-)
>
>> 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.


-- 

Regards,

Kingsley Idehen	      
President & CEO 
OpenLink Software     
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen