Re: longdesc URLs and RDFa

Ivan Herman, Wed, 18 Aug 2010 17:03:14 +0200:
> On Aug 18, 2010, at 15:46 , Leif Halvard Silli wrote:
> 
>> Mark Birbeck, Wed, 18 Aug 2010 14:00:05 +0100:
>>> 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.
>> 
>> It is true that they already have semantics about the relationship 
>> between (in @longdesc's case) the subject (@src) and another resource. 
>> But, for instance, in @longdesc's case, the longdesc URL doesn't need 
>> to be another _page_, it could be a fragment on the same page. Whether 
>> it is another page or another fragment, can e.g be expressed via the 
>> predicate.
> 
> Actually, that is not really true. A fragment on the same page is 
> translated into a URI. Ie, on the RDF level, both of these options 
> result in a URI,

Of course both results in a URI.

> there is no real difference.

I meant that the predicate could be used to - for instance, and perhaps 
not so useful (?) - inform whether the URI points to another page, or 
to fragment of some page (the current page or another page).

> [snip]
> 
>> 
>> E.g. sometimes newspapers publishes documents online in image form. Via 
>> @longdesc, one could link to a transcript. An RDFa predicate could 
>> declare the longdesc URL to represent a transcript. Thus, I don't see 
>> why the predicate must represent the host language's purist 
>> interpretation of what the longdesc relationship is.
> 
> The HTML spec very clearly defines what @longdesc is:
> 
> [[[
> This attribute specifies a link to a long description of the image. 
> This description should supplement the short description provided 
> using the alt attribute. When the image has an associated image map, 
> this attribute should provide information about the image map's 
> contents. This is particularly important for server-side image maps. 
> Since an IMGelement may be within the content of an A element, the 
> user agent's mechanism in the user interface for accessing the 
> "longdesc" resource of the former must be different than the 
> mechanism for accessing the href resource of the latter.
> ]]]
> 
> using it for a transcript _may_ be against the definition of 
> @longdesc (well, depending on what the transcript is, of course). I 
> think that this is what Mark is referring to: it may not be 
> absolutely kosher for RDFa to make this fully open, without defining 
> a predicate _and_ an object in this respect (I know this is not what 
> you ask for, but if we really have to go down that predicate+object 
> route than we get back to my mail of this morning...)

If I understand your argumentation, then it operates near the border of 
FUD land.

Let me see if I understand your line of thought: If the transcript 
contains a _description_ of the image, then you think it might be OK to 
use @longdesc as I described. But if the transcript really is a 
transcript of the text inside the image (I suggested that the image was 
a photocopy of a document - published as a proof of existence of a 
document and - such was the unspoken thought - the text of the document 
was readable to sighted users), then you think it is not OK. Because 
then it is not a _description_ anymore.

? Is that your line of thought?

You know in the ARIA spec, which also uses the @role attribute, then 
the @alt attribute is understood as a caption. Thus ARIA also says that 
a construct such as the following, can replace the user of text in the 
@alt:

<imageContainer role="img" >
<imageCaption>Mom and dad in their sofa.</imageCaption>
<img src="image" alt=""/>
</imageContainer>

Others, such an unnamed HTML spec editor, is IMHO hung up in the idea 
that the @alt is supposed to be a replacement of the IMG. And 
everything that doesn't fit that bill, is not considered a useful use 
of @alt.

I must admit myself, that the idea that an element caption, can replace 
the use of @alt, is a new thought. In the example above, the <img> has 
an empty @alt, which usually has been interpreted to mean that the 
<img> is purely decorative.

Thus: The fact that the @longdesc definition uses the word 
'description' should not be given too much weight. HTML4 doesn't 
describe @alt as a caption either - despite that that might be a useful 
interpretation, taken in by the ARIA spec.

The key thing is that @longdesc points to something which supplements 
the @alt. (Given the new construct that ARIA allows, and which HTML5 
partly formalizes as <figure role=img ><figcaption>foo</figcaption><img 
src=bar alt=""></figure>, then it seems correct to say that @longdesc 
may even already be the long description of e.g. a <figure>)

Above I described a transcript use case. Another one that I have 
described earlier, is that @longdesc could point to a  table 
representation of a diagram. If I understood your reading, then this 
would not be allowed since a table would not be a _description_ of the 
image.

Provided I understood your line of thought, then this not an exactly 
best intent reading of @longdesc. It seems to me that you are in need 
of a much simpler understanding of @longdesc. 

>>> 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.
>> 
>> W.r.t. @alt, then I don't only compare it with @content but also with 
>> <element>content</element>. The <element>content</element> of an 
>> element is more than some material that is waiting to be defined via 
>> RDFa. Thus, I cannot see that you have provided a sound justification 
>> for why it is illogical to treat @alt as @content.
> 
> I am sure that Mark can argue for himself:-) but, well... @alt is 
> used and defined for a very specific purpose:
> 
> [[[
> For user agents that cannot display images, forms, or applets, this 
> attribute specifies alternate text. 
> ]]]
> 
> Ie, it has a very specific 'semantics' attached to it per HTML. An 
> <element>content</element> or @content does not, so the user can and 
> should do what he/she wants with it. This is not true with @alt

I have not said that author should do what he/she wants with @alt. 
Quite the opposite. Unless the @alt can satisfy both the RDFa need and 
the usability need, then one must of course use @content - and not @alt 
- for the RDFa need.

It is however imprecise that the author may do what he/she want with 
<element>content</element>. For instance: <object>content</object>. It 
would be wrong to place as content of object some construct that is 
purely useful for and RDFa consumer, since user agents that cannot 
display the object@data, should display the <object>content</object> 
instead. Thus one must always consider the human consumer.

> [snip]

>>> 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.
> 
> To be fair, and here I have to give a counter argument to Mark:-): 
> yes, formally an HTML WG should define those semantics in terms of 
> RDF triples. That is correct. However, the current RDFa Core plus 
> XHTML+RDFa infrastructure is not flexible enough for an _external_ 
> group to add new attributes and incorporate them into the processing 
> model easily, with RDFa parsers easily keeping conformance. One could 
> _imagine_ a mechanism whereby a configuration for a specific host 
> language could be defined that generates an automatic RDFa-type 
> processor for a specific language, but I do not even want to think 
> about going there right now... The bottomline is that if the RDFa WG 
> does not define these attributes (and I am not saying it should!) 
> then nobody will. That is the reality.

So I guess I should +1 this. +1. :-)
-- 
leif halvard silli

Received on Wednesday, 18 August 2010 15:56:24 UTC