- From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Date: Wed, 18 Aug 2010 14:30:17 +0200
- To: Mark Birbeck <mark.birbeck@webbackplane.com>
- Cc: Ivan Herman <ivan@w3.org>, Shane P McCarron <shane@aptest.com>, martin@weborganics.co.uk, W3C RDFa WG <public-rdfa-wg@w3.org>
Mark Birbeck, Wed, 18 Aug 2010 12:39:32 +0100: > Hi Ivan/Leif, > > On Wed, Aug 18, 2010 at 11:44 AM, Ivan Herman <ivan@w3.org> wrote: >> Leif, >> >> thanks. I think I indeed misunderstood you. If I concentrate on the >> image related >> attributes, what you seem to say is that: >> >> - the value of @longdesc should be treated as if it was a @resource >> - the value of @alt should be treated as if it was @content >> >> and that is all. Correct? >> >> Sorry for the misunderstanding >> >> Ivan > > This doesn't work, I'm afraid, because @longdesc, @cite and @alt are > *very* different to @resource and @content. > > @resource and @content are generic containers for objects (and > subjects...sometimes) and for that reason are general-purpose. We > added support for @src for the same reason -- that it's generic. You don't mention @href. (My understanding is that @href and @resource are synonyms.) "Generic" can be used in at least two senses: 1) as "the common way", 2) as "the general purpose way". I believe you use it in the second way. (?) And I believe @data is generic in that same sense. As for @cite and @longdesc, they are not generic in the second sense - I admit that. But it is possible to map them to the same generics. How would that be to step on the semantics of the host language? Like I said: Even by supporting @src, you step on the semantics of the host language - it enables embed@src (forbidden syntax in today's HTML recommendations). > @alt, @cite and @longdesc on the other hand are predicate/object > couplets, and for that reason they require a decision to be made about > which predicate to map to. If we were to do that mapping then it would > take us away from providing a generic *framework* for semantics, to > actually defining the semantics themselves. Why do @cite and @longdesc need any more such decision than @href? By treating them like @href, they would not generate triples unless the authors themselves adds the predicate. > That's why at the very beginning of this discussion I said that we > should look at how we allow host languages to define their own > 'mappings' from attributes and elements to predicates. If we provided > that capability it would then allow people to define an interpretation > not only for @alt, @cite and @longdesc, but also for <title> and a > bunch of other things, too. I think my idea, from the start, was - as you say - that @cite and @longdesc already indicate a predicate/object couplet. Now my idea has changed a little. I think even whether it is true that it defines a such couplet, should be up to the language. But what is cannot be disputed, is that @cite/@longdesc are links - like @href is a link. And, by treating them like @resource/@href, RDFa would allow people to define an interpretation of those attributes, without defining a host vocabulary mapping first. I don't think this steps on the semantics of the host language. This doesn't preclude offering a way for the host language to define @cite/@longdesc as couplets. > (<title> is a good example of the problem we face once we move into > semantics; should <title> map to 'dc:title'? Lots of people think it > should, and we could spend weeks just discussing that. My response > would be that it's none of our business -- we are in the business of > providing a *framework* for semantics, and we let other people define > the semantics themselves.) > > The only attribute we have in the current spec that is comparable to > @cite et.al, is @typeof, which represents *both* a predicate of > 'rdf:type' *and* a resource. However, that particular exception is > driven by the needs of RDF and not HTML. > > So in summary, I don't doubt that it's possible to come up with > suitable mappings for these attributes, but I don't believe it's our > place to do so. A fundamental tenet of RDFa from the start was to > focus on a framework for semantics rather than the semantics > themselves, and that is what allowed us to avoid the 'Microformats > trap' (i.e., leave the definition of any actual semantics to the > specialists). Would you say that RDFa risk landing in a trap if it simply treats @cite and @longdesc as @resource/@href? -- leif halvard silli
Received on Wednesday, 18 August 2010 12:30:51 UTC