Re: longdesc URLs and RDFa

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, there is no real difference.

[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...)


> 
>> 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

[snip]

> [sni.  
> 
>> 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.

Cheers

Ivan


> -- 
> leif halvard silli


----
Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf