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

Hi Ben,

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

There are a number of problems with this though.

The first is that we haven't yet agreed on what attribute is used for
the predicate on @resource, so we need to do that first, before we
address this question. This is because, if we chose to use @property:

  <span property="a:b" resource="c:d">Fred</span>

then there doesn't seem a lot of point in making it 'override' @href,
since the author probably knows what they are doing if they create
mark-up like this:

  <a
   property="a:b" resource="c:d"
   rel=e:f" href="http://..."
  >Fred</a>

If on the other hand we decide to us @rel and @rev to set predicates
in RDFa-core:

  <span rel="a:b" resource="c:d">Fred</span>

then I can see some argument for having an 'override' when we create
the HTML/XHTML dialect, but the problem then is that we *lose* triples
if we ignore @href:

  <a
   rel="a:b" resource="c:d"
   href="..."
  >Fred</a>

Since @rel is part of HTML/XHTML independently of whether it is also
in RDFa-core, then if anything it should be the object in @href that
takes priority, and not @resource.

As you know, we've generally steered clear of having a notion of
'overrides' in RDFa--so we have meaning if both @rel _and_ @rev are
used on the same element, for example--and the main motivation for
this was to keep parsing logic simple; in the case of @href and
@resource if we want one to 'override' the other then we will have to
have the two parsing components closely interrelated. (This is not the
same for @content, since that can all be done in one parser.)


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

My thinking is that if someone has both @resource and @href present on
an element they probably meant both sets of triples, and we could make
that more explicit if we use @property to set the predicate for
@resource. This means that simple cases look like this:

  <span property="a:b" resource="c:d">Fred</span>

and when there is both @resource and @href there is no ambiguity:

  <a
   property="a:b" resource="c:d"
   rel=e:f" href="http://..."
  >Fred</a>

The key advantage of this is that there is no crossover between
RDFa-core and HTML/XHTML, which means we can 'unwind' any changes we
have made to the host language; for example, just as we inhibit '@href
anywhere', so too we should inhibit '@rel/@rev anywhere', 'link/meta
anywhere' and so on.


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

I'm saying exactly this--that we don't alter the host language at all,
other than to incorporate the RDFa core attributes. And I'm saying
this for all of our rules; not only do we leave @href only where the
host language allows it, but the same goes for @rel, @rev, <link>,
<meta> and so on.

I think the main point about my proposal is that 'RDFa in HTML'
becomes a combination of some new attributes (@about, @property,
@resource, etc.) and an *interpretation* of the semantic information
already provided in HTML. This latter effectively says, 'given this
language, with some semantic information in it, what triples could we
*generically* deduce from the language'. Unlike GRDDL, which says,
'what specific triples can we deduce from _content_ in the mark-up',
we're saying 'what can we deduce from what we know about the language
itself'.

The obvious examples in HTML/XHTML are <link> and <a> which use @rel
and @rev to establish relationships between documents. But we might
also want to provide an RDF interpretation of @title, <abbr>, <ins>,
<del>, @profile, @scheme, and so on.

Now, we're doing this with HTML and XHTML 1.x retrospectively, so
there are things that we'd like to be able to do but can't. XHTML 2
gives us an opportunity to build some of these features into the
language at the beginning and so create a more 'knowing' language.


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

It's <a> that is the "make it clickable" element, and really there is
actually nothing special about @href. It's only in XHTML 2 that @href
becomes the "make it clickable" attribute; in HTML 4 and XHTML 1.x
@href can be used on <link> and <a>, but only <a> is clickable.

Regards,

Mark

-- 
  Mark Birbeck, formsPlayer

  mark.birbeck@x-port.net | +44 (0) 20 7689 9232
  http://www.formsPlayer.com | http://internet-apps.blogspot.com

  standards. innovation.

Received on Tuesday, 29 May 2007 12:36:57 UTC