Re: longdesc URLs and RDFa

Ivan Herman, Sun, 15 Aug 2010 07:38:50 +0200:
> Leif,
> 
> if you formally want @longdesc and @cite to be interpreted in RDFa, I 
> think for the sake of the discussion in the RDFa WG you should really 
> give a clear use case for both attributes' usage in terms of RDF 
> triples. The mail of Shane seems to suggest that this would not 
> really be a solution for assistive technologies, for example.

What diff does it make whether it is useful for assistive technologies 
or not? That said: while a sighter user looking at some triples might 
be interested in clicking on the link to 'IMG@src triples', a blind or 
text browser user might be interested in the img@alt or img@longdesc 
triples ... 

The micro format I presented initially - roughly this:
	<a href="http://example.com/l.htm" rel="longdesc">	
		<img src="img" alt="text" />
    </a>

leads to the triple: 
http://example.com/doc <longdesc> <http://example.com/l.htm>

And my initial idea was that doing this
<img src="img" alt="text" longdesc='http://example.com/l.htm' />
should lead to the same triple. 

However, I see that the very image is not part of the triple here. 
Perhaps my idea of correlation between micro format and triple is to 
simplistic. For example, when we discuss HTML5 in the HTMLwg, then you 
will sometimes here people say that if one do <a href=link><img></a>, 
then the image is a link. However, despite the image being a link, the 
triple created from the micro format above does not contain a reference 
to the image ... 

In the example that you showed - in your first reply in this thread - 
one would get these triples:
 
http://example.com/doc/i.src <alt> "short description"
http://example.com/doc/i.src <longdesc> <http://example.com/longer.html>

And these triples perhaps are more meaningful. 

On the other side, coming back to @cite - what kind of triple would you 
suggest being generated from using @cite? I think, logically, there 
should be a triple containing the fragment URI of the <q> or 
<blockquote> element - if such a thing is possible in RDFa. 

So for example this:
<q id='quote' cite='http://example.com/source#fragment'>Lorem ipsum.</q>

should lead to something like this - 
http://example.com/doc#quote <cite> <http://example.com/source#fragment>

So, by analogy, I would say that use of @longdesc on an image 
<img id='iFrag' src="i.png" alt="text" 
longdesc='http://example.com/l.htm' />

then should lead to
http://example.com/doc#iFrag <longdesc> <http://example.com/l.htm>

though this would also be meaningful:
http://example.com/doc/i.png <longdesc> <http://example.com/l.htm>

> B.t.w., you referred to my reference to object. The reason I referred 
> to object is as follows. There are a number of attributes in HTML4 
> and HTML5 that might be reasonably interpreted in RDFa beyond @rel, 
> @rev, @href. The original RDFa design decided to give a specific 
> interpretation (essentially like @href) to @src to give a proper 
> treatment to <img> (Luckily, the @src attribute covers the 
> requirement of HTML5's <video> and <audio>.) With the same logic, the 
> @data attribute of <object> could be interpreted a similar way but it 
> isn't; I do not remember why it was decided not to do that, but I 
> suspect the reason was to keep the language more succinct.

I agree that it you support @src, then it seems logical to support 
@data as well. Why don't you? On the other side, OBJECT is a 
complicated element. In fact, it has many similarities to VIDEO and 
AUDIO that way: Some object-s may have both a @data and - in a param 
element - a @src. Or you may find the @src in a 'fallback' element such 
as EMBED ... 

For VIDEO and AUDIO, then the element _either_ has a @src, _or_ it has 
one ore more <source src='*'> elements. (Not so for OBJECT - there is 
is possible to find both object@data + param+src.) Is fallback and 
alternative contet a 'problem' for RDFa? I guess that I tend to think 
in 'constructs' - and expect triples to be generated for microformats, 
so to speak. Thus I see problems ... E.g I would like to know whether 
the source@src belongs to a video or an audio element. If a triple is 
being generated for a @src only, then  it is not always clear from the 
MIME type and - or - file suffix (because not all URIs are semantic - 
without file suffix ...) whether it is audio or video, for instance.

But, OK, I can understand that the 'floodgate' argument may have some 
validity, still. OTOH, in the case of @data, you could just map it to 
@src, why not?

> That is why I would like to have a very clear use case both for 
> @longdesc and @cite. And also why you do not add @alt to this list, 
> although I think it would belong to the same family, so to say.

Regarding @alt: In the case of IMG@longdesc, then the long description 
resource, according to HTML4 relates to @alt - it is a long alternative 
to IMG@alt. So, in a way, I have included @alt - though perhaps that is 
to stretch it. 

In the case of iframe@longdesc and frame@longdesc, then the longdesc 
resource represents a long alternative to iframe@title and frame@title. 
OTOH, some would probably say that a longdesc resource for an IMG 
relates to the image of the src URL and not to the @alt text of the 
image ... Both are in a way true.

Anyway, my view is that when it comes to @alt then you should make sure 
that RDFa treats IMG@alt the same way that it would have treated <img 
src=* >alt</img>. So in other words, the @alt should be treated as the 
content of the IMG element.

If we say that @longdesc and @cite are shorthand for - or workaround 
for - using anchor elements, then I don't think that I in the same go 
must request that RDFa handles @alt. Though, on the other side: The 
thing they have in common - and perhaps that is what you meant - is 
that the @cite URL must be linked to the _content_ of blockquote/q just 
like the @longdesc URL must be linked to the _content_ of the IMG 
element = its alt attribute. 

(Btw, in the HTMLwg there is a debate about what a non-decorative IMG 
represents - the @src or the @alt.)

(Though in the case of @longdesc on an iframe and frame element, then 
the @longdesc must be linked to the content of their @title attribute - 
though perhaps that is less obvious ... since the content of an iframe 
element is not the title attribute ... in that case linking the 
@longdesc URL to the iframe URL makes more sense. There are a few loose 
ends in HTML ...)

> Thanks
> 
> Ivan 

Leif

Received on Sunday, 15 August 2010 11:17:47 UTC