Re: longdesc URLs and RDFa

Leif,

thank you.

You said that the floodgate was opened when RDFa accepted @href and @src. While this may very well be true, what you describe in your examples go further. To stick to @longdesc, you seem to ask not only to interpret @longdesc somehow, but also to assign a specific property to it from the foaf namespace (and the same for @alt). This is a significant step further than the usage of @href/@src which simply set the object or subject of triples. Other than that, RDFa is almost completely agnostic as for what vocabularies are used in the triples, except for some of the 'inherited' historical @rel values that (X)HTML carries (like 'next' or 'stylesheet').

In effect: the proper and complete logical approach along the lines of what you say is:

1. make a thorough analysis of the whole of XHTML to find those attributes and possibly elements that have a 'semantic' interpretation in an RDF sense
2. define the exact processing steps, ie, the extensions for the general, RDFa Core processing steps for each of these

To be very honest with you, and I must emphasize that this is my private opinion, I believe this goes beyond what this Working Group can, and indeed should do...

Cheers

Ivan


On Aug 18, 2010, at 03:20 , Leif Halvard Silli wrote:

> Manu posted a link on Twitter today - where I found this: [1]
> 
> ]] strange phenomenon in the linked data movement: the almost total
>   disregard for the linking part. Sure data is getting published 
>   as triples with dereferencable URIs, but where are the links? [[
> 
> Be that as it may: support for @cite and @longdesc would at least show 
> _regard_ for links.
> 
> Ivan Herman, Tue, 17 Aug 2010 08:01:05 +0200:
> 
>> @longdesc, @alt, @cite, @data, but we could also think 
>> about @title: all these make sense individually, but each has 
>> different issues with them. So yes, use cases are important to 
>> justify the price for each of these.
> 
> @price
> 
> There are of course implementation costs.
> 
> But the price that motivated me to ask for support for @cite and 
> @longdesc, is the price of illogical gaps in the support of the primary 
> host language. If RDFa does not support synonymous features of the host 
> language, then it means that RDFa - in reality and purely for its own 
> economical reasons, favors certain parts - a simplified version - of 
> the host language. 
> 
> It is a shared cost: RDFa becomes less 'native'. While, for the host 
> language, it may trigger shoehorning (of a@href) instead of using its 
> specialized features (@longesc + @cite). It also causes duplication of 
> the content of @alt, @longdesc, @cite, @data into the parallel RDFa 
> attributes. With the risk of things falling out of sync and so on. 
> 
> Also: being a "good guy" should not be punished: using <object> because 
> of its richer alternative text opportunities (compared with <img@alt>) 
> should preferably not complicate the RDFa tagging. And it would be 
> logical the use of native semantic features, such s @cite, _simplified_ 
> the RDFa tagging.
> 
> It seems to me a bit ironic that RDFa supports embed@src - out of the 
> box. While when it comes to object@data, then one has to duplicate the 
> @data URI inside a @about attribute. (However, I admit that supporting 
> @data requires some thinking, since object is a multifaceted element.)
> 
>> I know, Leif referred to 
>> @longdesc only, but that opens that floodgate I referred to before; I 
>> cannot justify adding only one attribute and not taking another one 
>> without proper arguments.
> 
> The flood gate really opened when you chose to support @href and @src, 
> @content and <e>native element content</e> - doing so implicates that  
> @cite, @longdesc, @data and @alt should also be supported.
> 
>> Leif, unless I missed it in your mails (in which case my apologies) 
>> what you answered were not use cases but more ways of expressing 
>> @longdesc in triples. What I am looking for is which are the 
>> applications that become possible with or, say, that cannot be done 
>> without these extra triples; more precisely, that cannot be done 
>> easily by the author or an RDFa authoring tool like Drupal 
>> automatically adding some RDFa attributes alongside (or instead of) 
>> @longdesc.
> 
> 'Instead of' is not meaningful. @longdesc is used in order to provide 
> access, for a human, to a resource - same as @href. I think rather that 
> one sometimes could consider using @longdesc instead of @resource, once 
> RDFa supports it. (One should of course not misuse @longdesc - it must 
> be a "real" and helpful long description.) 
> 
>> We had some pretty good examples in the past for the 
>> creation of, say, meaningful foaf files which led to the inclusion of 
>> @src into the RDFa attribute set, to give an example. This is what I 
>> thing should accompany any discussion...
> 
> Below I try to demonstrate some FOAF use case as well as some other 
> ones. Are these better? 
> 
> @data: 
> 
>   foaf:img. Shouldn't all of these work equally well?
> 
> <span rel="foaf:img">
> <img 
>  src="http://www.formsplayer.com/files/pictures/picture-11.jpg" 
>  alt="Picture of Mark Birbeck" />
> </span>
> <span rel="foaf:img">
> <embed type="image/jpeg" 
>  src="http://www.formsplayer.com/files/pictures/picture-11.jpg"/>
> </span>
> <span rel="foaf:img">
> <object type="image/jpeg"
>  data="http://www.formsplayer.com/files/pictures/picture-11.jpg">
>   Picture of Mark Birbeck
> </object>
> </span>
> 
> @alt: 
> 
> 	* @alt should count as @content value if you set the @property 
>      attribute on an <img>
> 	* same goes for @alt on an <area> element
>    * <img src="mother" property="foaf:topic" 
>           alt="My smiling mother" />
>      instead of  
>      <img src="mother" property="foaf:topic" 
>           alt="My smiling mother" 
>           content="My smiling mother" />
> 
> img@longdesc: 
> 
> 	foaf:depiction and foaf:depicts. @longdesc is supposed to explain what 
> those looking at a graphical user agent already can see. Which seems to 
> circa fit the foaf:depiction use case.
> 
>    I have here constructed an example with both @longdesc and @alt - I 
> believe it should be possible to use @longdesc instead of @resource and 
> @alt instead of @content:
> 
>    <img xmlns:foaf="http://xmlns.com/foaf/0.1/"
>                src="diagram.png" 
>                rel="foaf:depicts"
>           resource="diagram-data-as-a-table.html"
>           longdesc="diagram-data-as-a-table.html"
>           property="foaf:topic"
>                alt="Development last six months."
>            content="Development last six months."  
>    />
> 
> 
> iframe@longdesc
> 
> 	foaf:page could be a use case:
> 
>    <iframe src="feed.atom" title="Our news feed"
>            rel="foaf:page"
>            longdesc="about-page-for-the-feed.html"/>
> 
> @cite: 
> 
> 	 Toby had a use case for this. Which made me uncertain with regard to 
> whether @cite should logically be an @about parallel or a 
> @resource/@href parallel. 
> 
> @title:
> 
> 	I have no use cases for @title. And I do not think that adding support 
> for @cite, @longdesc, @alt or @data require that there is also support 
> for @title.
> 
>    My motivation for adding the other attributes, is to make sure that 
> RDFa doesn't "forget" to implement synonymous features to the ones it 
> has already implemented.
> 
>    But for @title, then I see no obvious currently implemented 
> parallel. Unlike @alt, it it does not have a parallel/synonym feature 
> in the form of @content or real element content. And unlike @longdesc, 
> it is no parallel/synonym feature to @href. An unlike @cite, it is no 
> parallel feature of @src - or @href (again, I became uncertain what the 
> best parallel is).
> 
>    There is only few HTML elements where the @title attribute has a 
> defined function. Right now I recall <abbr>, <acronym>, <iframe>, 
> <frame>, <style title="*"> and <link rel="stylesheet" title="*">. May 
> be RDFa should start thinking about those elements first, if some kind 
> of support for @title is wanted. 
> 
> [1] http://www.mkbergman.com/902/i-have-yet-to-metadata-i-didnt-like/
> -- 
> 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