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