- From: Mark Birbeck <mark.birbeck@webbackplane.com>
- Date: Wed, 18 Aug 2010 14:00:05 +0100
- To: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Cc: Ivan Herman <ivan@w3.org>, Shane P McCarron <shane@aptest.com>, martin@weborganics.co.uk, W3C RDFa WG <public-rdfa-wg@w3.org>
Hi Leif, I think @cite and @longdesc are more than just a resource waiting for a predicate to be defined. They already have semantics about a relationship between the current document and another, it's simply that those semantics haven't been defined in RDF terms. Similarly, @alt is more than just a plain literal waiting for a predicate to be defined. It has the semantics of being a label for a resource, but once again there is no precise definition for it, in RDF terms. So, whilst one /could/ ignore the semantics of these attributes, and treat them as the same as @resource and @content, that would be to ignore the semantics that HTML already gives to these attributes. It would be far better to say that these attributes define a predicate/object couplet in just the same way that @typeof does. But what I'm also saying is that this is not something that should be done in the RDFa specification, but in the HTML/XHTML ones. Regards, Mark -- Mark Birbeck, webBackplane mark.birbeck@webBackplane.com http://webBackplane.com/mark-birbeck webBackplane is a trading name of Backplane Ltd. (company number 05972288, registered office: 2nd Floor, 69/85 Tabernacle Street, London, EC2A 4RR) On Wed, Aug 18, 2010 at 1:30 PM, Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> wrote: > 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 13:01:01 UTC