[whatwg] RDFa statement consistency

Henri Sivonen wrote:
> Now we have people from the RDF community asking for CURIEs in HTML.

No. I'm not "from the RDF community." I am from Creative Commons. I
represent Creative Commons at the W3C. I have done no research or active
work on RDF, only on integrating RDF in HTML, because RDF was clearly
the best metadata model for our needs.

I am a member of the *Web* community. I believe URLs are useful. The
overhead you mention is easily optimized by caching common namespaces,
all the while maintaining a *Web* architecture, where you don't hand
over power to a central authority, you allow many to develop their own
vocabularies, and you let a thousand flowers bloom.

I understand that "RDF" is a four-letter word in some circles. But I
deal with the realities of what's needed for the kinds of applications
that we envision at Creative Commons, so it's important for me to get
over the exaggerated (and unprofessional) badmouthing of RDF and see
what it offers.

The SemWeb folks will tell you that I criticize large parts of RDF all
the time. I think many mistakes were made. But there are also many solid
design principles, especially if you believe in the Web.

> Even if the experiment didn't work out, the damage would already have
> been done, and the HTML community would be stuck with supporting CURIEs.

No. You don't have to support them at all. You can say that "browsers
are free to ignore these attributes. If browsers or other user agents
want to parse them, they should use the RDFa specification."

The *rest* of your HTML is completely unaffected. This is quite
different from the XML experience you describe, where you have to be
namespace-aware to start parsing anything. So, not a fair comparison by
any stretch.

> Or even if we were able to negotiate CURIEs away and settle on full
> URIs, the HTML community would be stuck with unwieldy identifiers (just
> consider how much things would suck if HTML element names had to be
> written as URIs).

We agree, writing out full URIs often sucks, which is why we limit that
with prefixes. But we never claimed we needed to do so with element
*names*, that's a strawman argument.

> It's really not nice to impose the RDF tax onto the HTML community.

It's not the RDF tax. It's the Web tax. It's building an architecture
that supports distributed innovation, that says your URL is not
inherently more powerful than mine.

You want monolithic, top-down, one solution-fits-all. I want the Web.

> Back in the Atom WG, there was also the issue that some RDF proponents
> wanted to make Atom RDF. Instead of making all Atom consumers deal with
> RDF, we specced a way for mapping Atom rel keywords onto URIs, so people
> who want to see the world as URIs, can see it as URIs but the rest of us
> don't have to.

Doesn't Atom have namespaces for all of its extensions, i.e. gdata? Why
aren't you complaining there? In fact, the funny thing is that Atom is
effectively RDF, because it's XML that doesn't have a very strict
schema, since you can extend every which way you like, add extra
namespaces, etc... and pretty soon it looks like RDF/XML, only it's not
called that.

I suspect you're more afraid of the acronym "RDF" than you are of the
actual technology.

> I like the GRDDL approach of seeing RDF there by looking at non-RDF
> things just right--with the modification that the person who wants to
> look just right is the one supplying the transform.

GRDDL is great, but in the HTML case it has some significant downsides.
It doesn't let you do the important Ubiquity-like use case: where you
point to an area of the screen and you get exactly *that* structured data.

> The point of
> http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-August/016021.html
> was to try to come up with a scheme that allows people who want to see
> HTML as RDF to see it that way, but in doing so making them pay the RDF
> tax so that those who don't need or want to see HTML as RDF do not need
> to pay the RDF tax.

This entire line of reasoning around the "RDF tax" is, in my opinion,
bogus. There is no significant RDF-specific tax in the proposal we're
making. The question is whether you believe in a Web-like architecture,
or whether you want all parsers to know all sorts of pre-defined kludges
ahead of time. Monolithic vs the Web.

Is it a bit slower to do things with a Web-like architecture?
Absolutely. That's the price we pay for flexibility, a price we already
accept by getting on the web in the first place, e.g. visiting sites
that include JavaScript from other servers which then slow down the
rendering of the page, etc....

> I'm getting mixed signals about the extent to which RDFa in envisioned
> to be browser-sensitive. Weren't browsers supposed to do cool stuff with
> it according to some emails in this thread?

Loose coupling. Browsers can do nothing or lots with RDFa, up to them.
But you don't have to mandate anything, certainly not any rendering
behavior.

No mixed message, just flexibility in what user agents choose to
implement. In fact, I'd rather they implement nothing and let extensions
like Ubiquity do the work.

-Ben

Received on Friday, 29 August 2008 09:04:59 UTC