[whatwg] Creative Commons Rights Expression Language

[Ben Adida]

Ian,

Thanks for the details.

Some questions below.

Ian Hickson wrote:
> The Database stuff was mostly driven by requests from large Web 
> application authors (including, for example, GMail), who wanted to be able 
> to offer their services even while their users were offline.

I am quite favorable to the SQL DB in the browser approach, in that I
think it is an enabler of many great things.

However, it's pretty clear that this need comes from technically capable
folks, not from "the bulk of users," right? The need from the bulk of
users is, at best, "I'd like to access my email offline."

So then, why is IMAP insufficient? And why SQL? Why not something a
little simpler?

I ask these questions because there's a parallel to RDFa here. A number
of web publishers / application authors want to use RDFa, because they
know it will enable many new applications. End-users likely won't know
much about RDFa, nor should they. They'll just know that suddenly their
browsers can recall articles similarly tagged in their history, that
search engines like Yahoo's SearchMonkey can surface significant useful
information directly in their search results, that reusing CC-licensed
works is now much easier with automated attribution, etc...

Pick any single application here, and you could come up with an easier
alternative than RDFa. But putting them together, you need something
more generic. The SQL database of interoperable web data, in a sense.
And that's where RDF (and thus RDFa) comes in.

So my question is: what would it take to convince you that we need
something more generic than the one-off solutions you and others have
been suggesting?

How did the gmail proposal become "we need more than just IMAP, we need
the generic SQL DB, and we will change the way the web browser works
forever by enabling offline access."

Again, I like the SQL-DB idea, I'm not arguing against it, I'm just
wondering how it got through your stringent process. And I note that
RDFa is a much more modest proposal that requires almost no work for
browser implementors.

> Consider it from our side. How would you feel if you asked a question and 
> I told you the answer was somewhere in the HTML5 spec?

Not quite the same thing, ccREL is the complete reasoning for this
particular problem, from one party (the equivalent of gmail to
SQL-in-browser).

> We have to address problems that people know they have, or would agree 
> they have if told they had them, because people won't spend any effort to 
> address problems they don't think they have.

So, just to be clear, how does that link up with SQL-in-browser? When
you say "people," do you mean web publishers / application builders?

> The word "problem" doesn't appear once in the ccREL paper. Where is the 
> statement of what ccREL is trying to solve?

Well, the exact word doesn't have to appear, does it? Here are the first
two sentences of the introduction:

"This paper introduces the Creative Commons Rights Expression
Language (ccREL), the standard recommended by Creative Commons
(CC) for machine-readable expression of copyright licensing terms
and related information. ccREL and its description in this
paper supersede all previous Creative Commons recommendations for
expressing licensing metadata."

>From this it's pretty clear that we're trying to express copyright
licensing information (with all of the sub-fields it implies and all the
possible data types we might license) in machine-readable form.

> But I'm more concerned about RDFa, since presumably if we addressed the 
> problems of RDFa, ccREL would be automatically resolved.

Sure, although if you want to understand the use case, ccREL is fairly
important.

> The ccREL paper is long, wordy, and doesn't really seem to clearly state 
> the answers to the questions I listed above.

Interestingly, ccREL has been extremely well received in the
non-technical space. But I guess you can't please all the people all the
time :)

> I'm really just looking for a 
> simple one-page answer.

A one-page answer? That's only possible if you're willing to accept
premises like "RDF is a good way to express interoperable data on the web."

Imagine trying to convince someone about SQL-in-browser when that
someone doesn't believe that SQL is the right approach, rather that it
should be XML object and XPath. Can you do that in one page?

So, if you're willing to start with "RDF is a good idea for
interoperable web data," then we can probably put together a short
proposal. But without a baseline, you're sending me on a fool's errand.

-Ben