[foaf-protocols] First WebID Teleconference minutes (July 27th 2010)
nathan at webr3.org
Mon Aug 2 18:40:50 CEST 2010
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).
>> 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?
More information about the foaf-protocols