[whatwg] Creative Commons Rights Expression Language

[Ben Adida]

Henri Sivonen wrote:
> I don't know what the right way to find the useful bits is, but just
> telling people out there to publish metadata and expecting use cases to
> emerge later isn't a good way, since that approach wastes a lot of
> people's effort.

In this email you claim there are no use cases.

But in another email only 6 hours earlier, you said:

> 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?

So, clearly, there are use cases we've explained. Here they are again,
just in case:

SearchMonkey:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-August/015967.html

Ubiquity:
http://lists.w3.org/Archives/Public/www-archive/2008Aug/0127.html
(I can't find the WHATWG link, but it was sent to WHATWG, too...)

> (I'm not suggesting that you are telling people to just
> go publish a lot of stuff. However, the upwards-scalable RDF naming
> approach and the approach of ignoring triples the consumer doesn't know
> about seem to be designed for erring on the side of publishing too much
> whereas the Microformats Process and the WHATWG approach ask for use
> cases first.)

You could put it that way, but what RDF is really about is publishing
data in a fine-grained enough matter that applications can easily
overlap. That's why you can ignore parts of the data if you don't need
it. You get a much more loosely-coupled, opportunistic Web, that way,
which is exactly the kind of opportunity explored by tools like Ubiquity.

> One example of useless metadata evangelism that I myself fell for 8
> years ago was embedding Dublin Core metadata in HTML. It wasn't nice to
> realize that I had been tricked into something totally pointless. (The
> data was redundant with HTML and HTTP native data.)

I don't think anyone was trying to trick you (did someone make money or
acquire fame off your DC markup?), but certainly it's true that the
infrastructure wasn't quite there (and the flexibility of adding other
vocabularies wasn't there, either.) We tried to remedy that with RDFa,
and we can already see from the CC uptake and tools that the situation
is quite a bit better.

> Also, having more metadata leads to UI clutter and data entry fatigue
> that alienates users. In the past, I worked on a content repository
> project that failed because (among other things) the content upload UI
> asked for an insane amount (a couple of screenfuls back then; probably a
> screenful today) of metadata when it didn't occur to system specifiers
> to invest in full text search. More metadata isn't better. Instead,
> systems should ask for the least amount of metadata that can possibly
> work (when the metadata must be entered by humans as opposed to being
> captured by machines like EXIF data). See also
> http://www.w3.org/QA/2008/08/the-digital-stakhanovite

That is an extremely limited view of how this might be used, as if every
web site that wants to publish RDFa is going to prompt users for 20
fields. No. Take Craigslist again: 5 structured fields is plenty to do
super interesting stuff, but we'd have to come up with a special
microformat for "apartment listings" if we reject fine-grained metadata
like RDF.

And in some cases, you *do* need to be able to output lots of metadata
(think publication records at pubmed, other online journals.)

Some past approaches to this problem have failed for reasons we believe
we've identified:
- repetition of rendered and machine-readable data leading to staleness
- too hard to include (modifying the HEAD, separate file) for non-savvy
web publishers
- vocabularies are monolithic and non-remixable, limiting reuse and
ability of little guys to participate

We've worked hard to address these in RDFa, and the publisher interest
we're seeing shows we've done *something* right.

Maybe it's time to let go of old ghosts and explore how this new
solution may address some of the problems of the past?

-Ben