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

Henri Sivonen wrote:
> the assumption that new work would all be XML-based.

And our work is entirely XML-based to date. But the RDFa Task Force is
joint with the Semantic Web Deployment working group, which itself has
an interest in seeing RDFa adopted more widely.

> We now know that the demise of text/html was greatly exaggerated, so
> it's now necessary to evolve HTML and XHTML in such a way that a unified
> vocabulary works with both text/html and application/xhtml+xml. Hence,
> previous XML-only bets were misplaced. That's tough, but things need to
> be adjusted for the dual serialization situation.

I agree with that, which is why we're seriously considering the @prefix
change, but I disagree with your approach, which appears to be more
about "change for the sake of change", or at least change to fit an HTML
world view which is empirically incorrect.

>> So I don't think we did anything rogue
> 
> Yet, when RDFa is deployed in
> text/html, community sites like rdfa.info cheer[2].

And when HTML5 features are deployed in browsers before they're
standardized and while many other folks are howling, is the HTML5
community not happy?

Let's stop with the holier-than-thou attitude, please. We're all trying
to push the web forward, and there's always a delicate balance between
sticking to the standard and experimenting with new deployments.

If anything, the fact that RDFa is being successfully deployed in HTML
should make many of your arguments moot, but you continue to fight this
battle where the only good deployments are the ones that comply with
your view of the world.

[...]

> I think this argument is a distraction. Prepending "http:" to a string
> doesn't magically bring about semantics.

I wasn't talking about the semantics of *using* a URI, I was talking
about semantically interpreting the *value* of @rel as a URI. @rel has
always been defined as plain string without meaning. To interpret it as
a URI is *new*, whether in CURIE form or in plain URI form.

So I think this point is *very* relevant, because you're claiming that
it was URIs all along in @rel, when actually that's simply not true.

> The decisions weren't vetted through the W3C Process for text/html.

No decisions have been made for text/html, nor have I ever claimed that
we, the RDFa Task Force, can make them. So again, this accusation of
poor process makes no sense.

> I think Process-wise, RDFa in text/html doesn't occupy
> any moral high ground.

You're right on this point, but again that doesn't mean change for the
sake of change is a good idea. HTML5 doesn't *have* to leave its mark on
everything just for the sake of it.

> (HTML5 probably doesn't, either. After all, it
> went outside the W3C entirely for a while.)

Understatement of the year.

> I suggest changing RDFa to use full IRIs instead of CURIEs.

I appreciate you putting a concrete proposal on the table.

I believe it is rather arbitrary and in conflict with existing uses in
HTML4. First, the use of IRIs in @rel is *quite* new, I know of no major
(or even minor) vocabulary that's deployed this way.

Rather, Dublin Core suggests a prefix-like approach: dc.title,
dc.creator, etc... OpenID does the same thing. eRDF does the same thing
*and* uses indirection to define its prefixes.

And finally, microformats suggest using @profile to interpret their
@rel's and @class's.

In other words, existing use of HTML strongly contradicts the raw IRI
approach. There's a level of indirection for every practical use of @rel
I've encountered.

And, as I just explained in my email to mnot, existing W3C RECs that
*do* function on text/html, e.g. GRDDL and eRDF, use @profile to alter
the meaning of @rel via a level of indirection.

I think your proposal is nice and clean if we had no empirical evidence,
but in the face of empirical evidence, I don't think it's justified.

Given the way HTML4 is *already* used with @profile and @rel values,
RDFa's approach doesn't introduce additional cost. (It may be that what
Link-Header is trying to do is simply far more difficult than it hoped,
but that's not RDFa's fault.)

So, given this, I don't see a technical reason for your proposal.

-Ben

Received on Sunday, 1 March 2009 16:26:22 UTC