- From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Date: Wed, 18 Aug 2010 17:55:45 +0200
- To: Ivan Herman <ivan@w3.org>
- Cc: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>, Mark Birbeck <mark.birbeck@webbackplane.com>, Shane P McCarron <shane@aptest.com>, martin@weborganics.co.uk, W3C RDFa WG <public-rdfa-wg@w3.org>
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