W3C home > Mailing lists > Public > public-rdfa-wg@w3.org > August 2010

Re: longdesc URLs and RDFa

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>
Message-ID: <20100818143017271974.2c96afd5@xn--mlform-iua.no>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 04:55:07 GMT