Re: longdesc URLs and RDFa

Shand, Leif,

I must respectfully disagree with part of what you say.

Indeed, the role of RDFa is to decide what triples to generate for a specific attribute. However, each new attribute has a price. It has a price in terms of precisely specify in the documents what the attribute does and how it compares and interacts with other attributes (eg, @src also generates a new subject for the subtree, would @longdesc do the same?). It has also a price insofar as each conformant implementation has to introduce a new branch in their code for that specific attribute. In this discussion thread, we already referred to a number of other HTML attributes as possible inclusions into RDFa. @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. 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.

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

(Sorry, still on vacations, so just chiming in...)

Cheers

Ivan



On Aug 16, 2010, at 19:21 , Leif Halvard Silli wrote:

> Shane McCarron, Mon, 16 Aug 2010 12:09:18 -0500:
>  ,,,
>> However, in this case what we have are some well defined features of 
>> the languages we support (HTML4 and XHTML 1.1) that we are not 
>> currently using to reap triples.  So any requirements and use cases 
>> should really be about why triples from these features are relevant 
>> to the semantic web (who would consume them, what would the consumers 
>> learn if they did), not about justifying the features themselves.
> 
> I agree.
> 
>> This isn't the forum in which we could attempt to justify the 
>> features anyway - that's the HTML5 working group.  Our job is only to 
>> define processing rules for extracting triples from the languages 
>> that we support, and rules for extending that processing into 
>> additional host languages.
> 
> Well said.
> -- 
> 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