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

Nathan nathan at webr3.org
Tue Aug 3 11:41:57 CEST 2010

Kingsley Idehen wrote:
> 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 :-)

as you know I fully agree, but surely it always MUST be machine 
readable, and SHOULD be Human readable.

Being just human readable doesn't really cut it protocol wise, otherwise 
we may as well assert microsoft word files or a jpg with it written in.

Before I go mixing up and conflating what I'm saying - my preferred 
approach would be to simply say 'MUST be machine readable'...'see the 
section on serializations/formats' then use RDFa examples through the 
primer with turtle/n3 for clarity in certain bits.

Then list a few possible serializations somewhere which includes all the 
common ld ones.

Critical imho is keeping that paragraph [2.3.3] defined enough to make 
it work (MUST MRD) yet open enough to be future compatible - then use 
the rest of the doc/primer to infer preferences.



More information about the foaf-protocols mailing list