Re: [whatwg] Creative Commons Rights Expression Language

Ian Hickson wrote:
> I've taken this off the WHATWG list since it isn't about HTML5.

That's unfortunate, since that's where it started regarding adding RDFa
support in HTML5. It would be nice if at least folks could see the
answer I sent.

> Is anyone who actually processes Creative Commons metadata actually doing 
> so in an RDF manner?

So, we *just* introduced ccREL in part because the previous kludgy
approach (RDF/XML in comments) was causing serious trouble for tools,
and because we need to convey more information than just the license.

I would suggest reading, or even skimming, the ccREL paper, where a
number of these questions are answered already.

> Google certainly isn't (we just inspect the metadata 
> using regular expressions). It seems that if people aren't processing the 
> data using real RDF tools, using any kind of RDF-based expression language 
> is somewhat pointless.

Read/Skim the paper. We're doing much more than a license pointer.

> Also, as Henri points out, the real problems that Creative Commons are 
> facing really have nothing to do with syntax.

So, because we also face other challenges (which you and Henri are
significantly overstating), we shouldn't address this one? I like to
address multiple challenges in parallel :)

> Who is "we"? Are there any people who actually want to use such tools?

Yes, there are lots of people who ask us (CC) if we have tools to
automatically embed license + attribution + title + more information and
automatically extract it.

In the wider RDFa community, the UK National Archive is one important
example of an important organization that is jumping onto the RDFa
bandwagon because it fits their needs. Digg is producing RDFa. And lots
of other implementations are in the works.

> In practice, it seems that just inspecting the content for a copyright 
> statement is more than enough to address the needs of people who want to 
> reuse content.

Please read the ccREL paper. Every time you say "copyright statement" as
if that's the entire issue, it shows that you haven't taken much time to
think about our needs.

Not that you have to take the time, of course, I'm sure you're busy. But
if you're going to spend time arguing with us, then please argue with us
about what we actually need, not about what you think we need.

> Furthermore, as noted above, at least one of the major 
> search engines that can be used to track down content of one type or 
> another certainly isn't even remotely attempting to build the tools to 
> that level of granularity, and as far as I'm aware, hasn't received any 
> significant amount of feedback requesting such features.

If the world always went by what the biggest player thinks is useful,
innovation would slow down pretty quickly. Some of your competitors are
quite a bit more interested in RDFa than you are.

> You can create your own vocabularies without clashing with the 
> Microformats community and without introducing extensions to HTML.

How do you know you're not clashing? Especially if others are doing the
same thing, without talking to the uF community? Whatever happened to
the web extensibility model, where you mint a URI at a domain you own?

> If the class attribute and other HTML mechanism can be used to mark up 
> entire vCards, iCalendar events, and entire Atom feeds on HTML, it seems 
> someone unlikely that it can't also be used to mark up what license the 
> content is available under.

Again, please read the ccREL paper, and my last email, which explains
that we need to mark up quite a bit more than a license link. You seem
to think our problem is simpler than a single vocab like Atom, when
actually it is far more complex, because we need to annotate many
different data types, so we need the vocabulary modularity that
Microformats simply don't have.

> Adding to the language is not friendly to that language, especially when 
> that language has as many existing extension mechanisms as HTML.

So far, we've added to XHTML because it's extensible. There's community
interest (expressed by others at the start of this thread) in seeing if
HTML5 might adopt RDFa attributes. What is the difference between that
proposal and your proposals to extend HTML? What makes your proposals
"friendlier?"

> Fundamentally my opinion is that RDFa is solving a problem that people at 
> large have no interest in addressing.

I'm not sure what "people at large" means, but I do think your opinion
is not very well informed. There is significant interest in a generic
syntax for adding metadata inside HTML. It's a lot of the same drive for
microformats, for all the folks who can't handle the centralized process
and who need the vocab modularity.

> That's not to say that I don't think computer-readable detailed 
> metadata is a great idea and everything, I just don't think it'll work 
> when your average human faces it.

Why don't we at least build a real mechanism for expressing web-based
data, with distributed innovation and such, and the good parts of
microformats (*in* the HTML, DRY, etc...) And then we'll see. But you
keep basing your opinion on a past that never attempted to do this right.

> With things like licensing metadata, where the person who 
> benefits the most isn't the person who writes the data, users simply 
> aren't going to bother doing a good job.

That's an incorrect assumption. We want, for example, to allow folks to
express how people should give them attribution. There's a very good
reason to do so as a publisher, so you get proper credit.

> Anyway. That's just my opinion. I'll shut up now. :-)

I sincerely hope you'll give us enough credit to actually read up what
we wrote. I don't expect to change your mind, but it's a bit silly to
argue based on incorrect assumptions.

> Actually the <progress> element is explicitly designed to be usable in a 
> manner that has acceptable fallback.

Great. So is RDFa. Current browsers deal with it super well, they just
ignore it. We used attributes only to achieve this specific outcome. And
yet we can still pick up the data in bookmarklets, plugins, etc..

So, browsers wouldn't have to be mandated to do anything with RDFa
attributes. You could literally just leave them hanging in the DOM, and
we'll build our tools around them. The smart browsers might do something
with RDFa, of course, but no one is asking that they be forced to do so
to comply with the standard.

-Ben

Received on Thursday, 21 August 2008 23:29:21 UTC