Re: longdesc URLs and RDFa

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

Received on Wednesday, 18 August 2010 01:21:31 UTC