rev and the costs of inverses/aliases in SPARQL

I just ran into this message again from an HTML 5 validator:

"The rev attribute on the a element is obsolete. Use the rel attribute
instead, with a term having the opposite meaning."

This seems to encourage the pattern of minting an inverse
for each property, a la:

  abridgement
  abridgementOf
 -- http://vocab.org/frbr/core.html

Doesn't that just gum up the works when doing SPARQL queries? Which
do you query for, abridgement or abridgementOf? Or do you use
a UNION?

It's one thing to discover, post-hoc, that two properties are
inverses of each other, and to write down that relationship.
But to make up these inverse-aliases by choice seems like
a big waste, to me.
(see also http://esw.w3.org/topic/HasPropertyOf bit on inverses and
aliases)

How are SPARQL users dealing with this in practice?


Meanwhile, RDF/XML doesn't have syntax for inverting a relationship
(a la is/of in N3), and there's data that says rev="..." is
too confusing for HTML authors to use.

"The short answer is unfortunately "NO". Use of "rev" SHOULD be
avoided."
 -- http://microformats.org/wiki/rel-faq
"the only <link rev=""> link to appear is rev="made" (to point to the
author's page) — and the latter is not used that much more than the more
sensible rel="author". Also, ironically, just off the graph in position
21 is rel="made", probably showing that the distinction between rel and
rev may be too subtle for many authors."
 -- http://code.google.com/webstats/2005-12/linkrels.html


Would the RDFa authoring community miss a/@rev if it went away?
Does anyone have 1st-hand experience to share?


-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/
gpg D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E

Received on Monday, 8 March 2010 15:00:46 UTC