W3C home > Mailing lists > Public > public-rdf-in-xhtml-tf@w3.org > May 2007

Re: PROPOSAL: Using @resource to define objects that are resources

From: Shane McCarron <shane@aptest.com>
Date: Thu, 24 May 2007 10:39:15 -0500
Message-ID: <4655B1A3.90606@aptest.com>
To: José Manuel Cantera Fonseca <jmcf@tid.es>
CC: mark.birbeck@x-port.net, RDFa <public-rdf-in-xhtml-tf@w3.org>

Just to be clear, are you suggesting that @content now be a URI type 
instead of a CDATA type?  To date content has been a way of specifying 
content for a property when you do not want to use the actual content of 
the element in question.  I think, anyway.

José Manuel Cantera Fonseca wrote:
>
> Hello,
>
> I'm suggesting the following counterproposal which sounds more 
> orthogonal to me and avoids introducing a new attribute:
>
> <div about="http://joost.com/some-film">
>   <div property="dc:title">A film</div>
>   <div property="dc:description">
>     Some notes on the film
>   </div>
>   <span property="dc:subject" content="http://film-vocab/horror" 
> datatype="rdf:resource">Category:
> Horror</span>
> </div>
>
> Best wishes
>
> Mark Birbeck escribió:
>>
>> This is a proposal for the requirement at:
>>
>>  <http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2007May/0018.html> 
>>
>>
>> Any discussion about whether this is a legitimate thing to try to do
>> should be added to that thread. This thread is for a possible solution
>> that meets the perceived need.
>>
>>
>> CURRENT SYNTAX
>>
>> There are two current technique for specifying an object that is a
>> resource. They are to use @href on elements that are not anchor tags,
>> and the second is to use a link element.
>>
>> The first, using '@href everywhere':
>>
>>  <div about="http://joost.com/some-film">
>>    <div property="dc:title">A film</div>
>>    <div property="dc:description">
>>      Some notes on the film
>>    </div>
>>    <span rel="dc:subject" href="http://film-vocab/horror">Category:
>> Horror</span>
>>  </div>
>>
>> There has been some pushback on this technique.
>>
>> The second is to use a link element:
>>
>>  <div about="http://joost.com/some-film">
>>    <link rel="dc:subject" href="http://film-vocab/horror" />
>>    <div property="dc:title">A film</div>
>>    <div property="dc:description">
>>      Some notes on the film
>>    </div>
>>    <span>Category: Horror</span>
>>  </div>
>>
>> In terms of use in current browsers, we're finding that context
>> information is lost when using 'link' in the body of the document, so
>> this doesn't look like it will work. Obviously the elements could be
>> added to <head> with an @about, but that makes things quite difficult
>> to manage.
>>
>>
>> @HREF EVERYWHERE
>>
>> In my view the idea that authors will be confused by having '@href
>> everywhere' is not as big a problem as has been posed. However, I'm
>> always of the view that if we can find an alternative solution that
>> does as good a job as a solution that people aren't comfortable with,
>> why not just use it. In this case, I think there is an alternative
>> solution that is in some ways better than '@href everywhere'.
>>
>>
>> A SHORT HISTORY OF @RESOURCE
>>
>> In my earliest drafts of RDFa I used attributes for subject, predicate
>> and objects, and the one for objects that were resources was
>> @resource. However, this was never satisfactory, because it meant that
>> information would often be duplicated--once for a clickable link, and
>> once for a statement--and it was the big thing that Ben Adida insisted
>> we should solve. So, after a great deal of juggling things around, I
>> stumbled upon the fact that @rel and @rev could be used on anchor
>> tags--maybe I was the only one who didn't, but I had not known that
>> that--and so it became pretty clear that HTML already gave us what we
>> needed and we could use @href instead of @resource. This seemed to
>> meet Ben's crucial requirement that we should only have to express the
>> URI once, and so 'bridge the clickable and semantic webs'. :)
>>
>> Now, since XHTML 2 had previously added a new feature that @href could
>> be used on any element in a document, to create a navigable link, it
>> seemed obvious that all we had to do was drop @resource, and replace
>> it with @href.
>>
>> However, non-XHTML 2 browsers actually have a tough time turning @href
>> on a span into a clickable link, and although it can be done with some
>> script, we don't get that out of the box. This means that we can have
>> @href attributes in a document that are not clickable links, and there
>> has been some argument that using @href on non-anchor elements could
>> confuse people.
>>
>>
>> PROPOSAL
>>
>> My proposal would therefore be to still _allow_ @href anywhere, but to
>> play this feature down, and point people towards @resource. I feel
>> that an RDFa parser should still process @href as an object that is a
>> resource, wherever it finds it, so that if it encounters an XHTML 2
>> document, it will still work.
>>
>> But whilst we still _support_ that feature, in our example code,
>> tutorials, and so on, we should instead use the resource attribute to
>> express an object that is a resource. Hopefully this way things will
>> be clearer to authors.
>>
>> One way that we could understand this is that @resource is a core RDFa
>> attribute, whilst @href is not. When we come to use RDFa in a 'host
>> language' we add further rules, and in the case of the host language
>> being HTML or XHTML we can say that @href is given the 'RDFa meaning'
>> of being equivalent to @resource.
>>
>>
>> SYNTAX
>>
>> Our previous example would now become:
>>
>>  <div about="http://joost.com/some-film">
>>    <div property="dc:title">A film</div>
>>    <div property="dc:description">
>>      Some notes on the film
>>    </div>
>>    <span rel="dc:subject" resource="http://film-vocab/horror">
>>      Category: Horror
>>    </span>
>>  </div>
>>
>> (I'll leave how the predicate is expressed out of this, but there are
>> good arguments for using @property here. I'll start a new thread for
>> that.)
>>
>> Regards,
>>
>> Mark
>>
>
>
>

-- 
Shane P. McCarron                          Phone: +1 763 786-8160 x120
Managing Director                            Fax: +1 763 786-8180
ApTest Minnesota                            Inet: shane@aptest.com
Received on Thursday, 24 May 2007 15:39:34 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:15:04 GMT