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

Henry Story henry.story at gmail.com
Mon Aug 2 18:55:16 CEST 2010


On 2 Aug 2010, at 18:40, Nathan wrote:

> Henry Story wrote:
>> Where is the latest version of the spec so that I can edit that? I'd like to just put some text together for a proposal. On 2 Aug 2010, at 18:23, Nathan wrote:
>>>>>>   
>>>>> 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.
>> Because it is often difficult to do RDFa right. On small sites it is very easy for people to edit an RDFa template without understanding the consequences to the RDF of their actions. Generating RDF/XML automatically is a lot easier to do.
>> More and more Content Management Systems, have an object view of the data stored. Even a real simple one such as XWIki has that. If one knows what types of objects get displayed on a html page, it is very easy to automatically use that information to generate RDF/XML.
> 
> I'd say that yes it may be difficult to do RDFa right at the minute, but this is true of any new not totally understood technology, by the time WebID has a high market penetration I'd presume this issue would be voided, and also referentially resolved by tying WebID to RDFa (either by MUST of by inference).

I  can see this always being an issue. Tying markup and semantics are tasks that require two very different types of skills, and they are rarely in the same people. 

With time tools will of course appear, but don't count on that happening before WebID is huge enough for the big players to put the money in the complex tooling this will require.


> 
>>> 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.
>> In the end the consumer - aka Relying Party - should accept as many formats as he can get away with. And the publisher should publish one well known format. Clearly  the established RDF formats have been researched in most depth, and it should support those. If new formats come along and manage in one way or another to push themselves on the scene, then RPs will have a big advantage in supporting those too. 
> 
> I both agree an disagree (weirdly) but most interested in getting to the root of why you say 'consumer should accept as many formats as he can get away' - is this for technical reasons, or due to the current climate of the semantic web?

The more people can login easily to your site, the more friendly people will find you to be, the more friends and customers you will have. That's why.

So as mentioned previously, I think RDFa and rdf/xml are for the moment two formats that should be supported.  I think we all do already, so we just need to grow the number of sites using this, and the SHOULD will turn into a pragmatic MUST.

Just as with HTML. Once Netscape had 80% of the market on an open format that any competitor could re-implement, there was absolutely no advantage for them to work on a new format. M$ tried and failed even. The network effect is what is important here. The spec is useful for psychological reasons mostly.

Check out again the intro of David Lewis' book on Convention I linked to earlier.

Henry

> 
> Best,
> 
> Nathan



More information about the foaf-protocols mailing list