I agree with Tantek’s comments, though I wouldn’t advise removing admittedly ugly and potentially redundant RDF-in-HTML-comments, at least not until mozCC and ccRdf and consequently some dependent code go case insensitive.
There are currently at least two Creative Commons metadata cases where a simple
rel="license" attribute won’t do, requiring RDF:
- The current resource needs to make statements about other resources, e.g., when those resources aren’t adept at carrying their own metadata or staying in one place.
- One wants to include rich metadata, for example concerning a creator or rights holder, though that particular example I suppose cries out for
rel="tipjar"where no further requirements are present.
In my view, metadata-enabled web tools will do well to include a RDF model layer, whether the statements be gleaned from semantic [X]HTML, parsed from human language, or mainlined from some RDF encoding, and whatever the tool’s internal knowledge representation. Content creators will do well to produce the simplest, most utilitarian metadata possible.
I’m turning a bit sour on the phrase “lowercase semantic web”. I like semantic [X]HTML. I like RDF. All in the service of our near-term goals. All in the service of the Semantic Web, which will surely be a superset of the RDF web. I dig real world semantics in any case.
As I mentioned
I find "semantic HTML" very interesting — it keeps the metadata close
to the presentation, militating against "metacrap" and can be used to
populate the big-S Semantic Web through RDF generation.
Since then the RDF-in-XHTML proposal that builds on semantic HTML has
moved ahead and generalized, see <http://www.w3.org/2004/01/rdxh/spec>
"Gleaning Resource Descriptions from Dialects of Languages" is a pretty
Also, Kevin Marks and Tantek Celik headed up a very nice BoF at Etech
which they discussed current small-semantic web implementations. See
that URL for some good links.
Largely, people are using the "rel" attribute of "a" elements
to describe "the relationship from the current document to the URI
referred to by the element. The value of this attribute is a
space-separated list of link types."
(I can’t find the equivalent documentation for XHTML1, but rel is
supported, per the DTD above).
A neat thing on the presentation side is that CSS selectors can actually
change the document rendering based on rel attributes — making the
metadata not just close to the presentation, but part of it.
Anyway, a rel attribute on anchors removes the big problem with assuming
that a link to a license indicates that a page is available under that
license — the page could be linking to the license for any reason. <a
rel="license" href="http://creativecommons.org/licenses/by/1.0/"/> on
the other hand, is no more ambiguous than the following RDF snippet
and can be used to generate the same.
The upshot is that I’m planning to recommend adding a rel="license"
attribute to links to CC licenses where the license applies to the
current page, have <http://creativecommons.org/license/> spit that out,
and encourage other apps to support the same.
Note that this is all entirely complementary with RDF. All apps should
continue to use/generate/support RDF, and RDF is required for making
license (or any metadata) statements about resources other than the