Re: @rel syntax in RDFa (relevant to ISSUE-60 discussion), was: Using XMLNS in link/@rel

Mark,

CC indeed recommends using RDFa, as we describe in detail here:

http://www.w3.org/Submission/2008/SUBM-ccREL-20080501/

which we published once RDFa was REC.

I'll focus on your point #3, since you say it is the most important and
I believe Steven has answered the others.

> 3) CC's adoption of *proposed* XHTML conventions from RDFa into HTML4
> via CURIEs further muddies the waters; xmlns has no meaning whatsoever
> in HTML4, so they're promoting bad practice there by circumventing the
> specified Profile mechanism. I find this aspect of this the most
> concerning, and it needs clarification (more colourful words come to
> mind, but I'll leave it there for now). 

Creative Commons specifically held off on encouraging ccREL widely until
RDFa was a REC for XHTML.

Of course, Creative Commons has made no secret of the fact that we're
working to include RDFa in HTML. RDFa is part of HTML5's charter in part
because Creative Commons, among others, asked. In addition, we strongly
support the RDFa task force's current work on using @prefix rather than
@xmlns to declare CURIE prefixes, in order to remove technical
complications from parsing @xmlns:* in HTML.

Now, let's be clear that the RDFa task force, on the other hand, has not
advocated putting RDFa in HTML right now, although it has done
everything in its power to make that transition as easy as possible from
a technical standpoint. The RDFa task force also worked to ensure that,
even as link-types evolve, RDFa would do its best not to conflict. In
particular, we parse RDFa as link-type or prefixed-CURIE, so rel="foo"
will mean nothing until a Link Type is added for "foo" (or a profile
gives it meaning.)

All that said, is Creative Commons jumping the gun a bit?

Yes, we are. We've been working since 2001 with various parties at and
outside of W3C to find scalable ways of embedding simple metadata in
HTML, and colorful words of our own come to mind to describe the
obstructionism we've encountered along the way :)

So while 90% of our work has been entirely in the context of standards
groups, 10% has stepped out in front of the standard as unobtrusively as
possible. Yahoo parses RDFa, in XHTML and in HTML, and it's been working
extremely well (they happily ignore non-prefixed CURIEs in @rel values).

I think the only section in [1] that potentially conflicts is 4.2, which
is quite short:

   4.2.  Extension Relation Types

   Applications that don't merit a registered relation type may use an
   extension relation type.  An extension relation type is a URI
   [RFC3986] that, when dereferenced, SHOULD yield a document describing
   that relation type.

   Extension relation types MUST be compared in a case-sensitive
   fashion, character-by-character.

Would you consider tweaking this section to indicate that certain
syntaxes, e.g. XHTML+RDFa, may further process the raw attribute value
to yield a URI? I certainly agree that, semantically, @rel should be a URI.

-Ben

[1] http://tools.ietf.org/id/draft-nottingham-http-link-header-04.txt

Received on Friday, 27 February 2009 17:20:50 UTC