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

[Nathan]

Kingsley Idehen wrote:
> Bruno Harbulot wrote:
>> On 02/08/10 16:21, Henry Story wrote:
>>> On 2 Aug 2010, at 16:34, Bruno Harbulot wrote:  
>>>> On 02/08/10 12:54, Henry Story wrote:
>>>>       
>>>>> [...]
>>>>> In the end what matters is that we can all interoperate, and that we can build cool apps.
>>>>>         
>>>> Sure, but that's an argument in favour of a small number of formats and to have them mandatory (at least on one side).
>>>>       
>>> It is a very good argument in favor of a few. But it is a practical argument.
>>> The spec can make this argument, without specifying that it MUST be so.
>>>
>>> As you say in your last email
>>>
>>> "To me, it's quite clear that social networking websites that
>>> choose to implement WebID but don't serve an HTML representation will
>>> fail to be considered useful by users, so there will be a bit of
>>> self-selection there anyway."
>>>     
>> It's quite a different thing though.
> No it isn't.
> 
> Henry is making the same point that I am making.
> 
> We can get there by separating Semantics from Data Representation.
> 
> We MUST have Structured Profile Documents that have HTML representations.
> 
> The REST is simply about implementor specific details.
> 
> Remember, the best way to really appreciate HTML+RDFa is by attempting 
> to reinvent it en route to producing a Structured Profile Document that 
> is Human and Machine readable.

yes, we could easily accomplish everything needed with *only* RDFa.

I for one would be happy to go balls out and specify 'MUST use RDFa' 
only, would anybody here who has a WebID or a foaf profile have any good 
reason not to do this?

I could debate every other serialization till the end of time, RDFa I 
can't - so why add any others in to the mix.

Caveat, if any others are added in, then all must be for (other than N3) 
they are all equal - RDFa rises above because it's Human Readable, N3 
rises above for obvious reasons, but those N3 reasons aren't needed for 
this protocol.

Best,

Nathan