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

I like this line of thinking a lot.

I would suggest the following precisions:

- RESOURCE overrules HREF if placed on the same element (for RDFa
purposes.) I believe Ivan mentioned this.

- sticking with REL rather than PROPERTY, because you may want to use
both REL and PROPERTY, each to generate a different triple with very
different objects (one an information resource, the other a literal),
but I can't see why you would want to use both RESOURCE and HREF as
objects on the same element.

- HREF remains an attribute of the host language, meaning that, in XHTML
1.1, HREF is only on A and LINK, while in XHTML 2, HREF is everywhere. I
believe Mark said this, but then he also said we would only tone down
HREF everywhere... I still think we should not have HREF where the host
language doesn't allow it.

This allows developers to continue to think of HREF as the "make it
clickable" attribute, with RESOURCE effectively overriding HREF a bit
like CONTENT overrides the element content.


-Ben



Mark Birbeck wrote:
> 
> 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
>

Received on Saturday, 26 May 2007 02:51:36 UTC