Re: [whatwg] Creative Commons Rights Expression Language

[Ian Hickson]

I've taken this off the WHATWG list since it isn't about HTML5.

On Thu, 21 Aug 2008, Ben Adida wrote:
>
> I appreciate all of the comments. I encourage folks who are commenting
> on these issues to read (or at least skim) the ccREL document:
>
>   http://www.w3.org/Submission/2008/SUBM-ccREL-20080501/
>
> It explains exactly our thinking, why we went with RDFa, and why a
> number of the alternatives proposed are insufficient for our needs (and
> the needs of a number of other web publishers.)

Is anyone who actually processes Creative Commons metadata actually doing
so in an RDF manner? 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.

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


> We want to build tools that can answer the question "is this *item*,
> entitled 'Sunset in Hawaii', usable for commercial purposes?" The
> *item*, identified by a URL or present inline as a chunk of HTML, may be
> a video, a photo, a song, a word document, geo-location information, or
> any other type of data we haven't thought of yet.

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

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


> Ian Hickson wrote:
> > I don't think anyone is suggesting that all such ideas should go
> > through the Microformats community.
>
> As far as I understand, that is in fact exactly what the microformat
> community requests, in order to prevent vocabulary collisions and
> enforce some minimal consistency across vocabularies.

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


> > What is being suggested is that instead of adding more features to
> > HTML, the people who want to annotate their HTML documents with
> > metadata, like Creative Commons, merely use some of the many existing
> > HTML extension mechanisms, like class="", rel="", etc.
>
> Not sufficient, and not for lack of trying either. Check out the ccREL
> paper for more details.

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.


> And note that we helped create a standard that would serve *everyone*,
> not just Creative Commons, with very few additional HTML attributes.

HTML can "serve everyone" too.


> How is RDFa any different? It may be a smaller community, but our needs
> are still relevant and important. Not to mention that our design
> approach was specifically tailored to be HTML5-friendly.

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


Fundamentally my opinion is that RDFa is solving a problem that people at
large have no interest in addressing. It's fine for small communities to
be using RDFa for their needs if they really do want structured triples
and inference engines and so forth, but there's no point trying to use
RDFa for something that is supposed to be used by people for whom the
metadata in question isn't a big priority, since they simply won't care
enough. 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. Just look at the typical media library
of your average user -- great metadata for the tracks they bought off
iTunes or Amazon, or which they could get data for through CD ripping
software, but if you look at any tracks they got in othe ways, the
metadata is a disaster. And that's with metadata that is directly helpful
to the users! 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.

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


On Thu, 21 Aug 2008, Ben Adida wrote:
>
> But... legacy browsers have no way to display a Progress Bar either,
> right?

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

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

[Ben Adida-2]

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

[Ben Adida-2]

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

My apologies, I misinterpreted this line, I see that my message to
WHATWG went through. Thanks!

-Ben

[Bonner, Matt (IPG)]

Ben Adida wrote:

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

Is that the only point of discussion?  Seems like understanding the
history, decisions and constraints of the HTML5 standard should be
considered as well.

Ian Hickson wrote:
>> 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?

Well, if you used <link> instead of <a>, there's the RelExtensions wiki..

http://wiki.whatwg.org/wiki/RelExtensions

What motivated the use of <a>, anyway?  It would be useful to add some
background to the next draft of the Submission that explains the
rationale for the design choices. Please point me to it if I missed
where ccREL explains it.

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

Well, section 3.1 of the Submission says:

  "A publisher who wishes to license a Work under a Creative
  Commons license must, at a minimum, provide one RDF triple that
  specifies the value of the Work's license property"

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

Perhaps it would be better to start over and engage the HTML5
community on your requirements, what makes sense and proceed from there?
Coming with a complete Submission and accepting no compromises doesn't
seem like the route to productive discussion.

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

Well, for example, HTML5 provides the data-* attributes. Could ccREL
use those instead?  To flip what you have said, perhaps reading/skimming
the "extensions" sections HTML5 spec would help the ccREL advocates
understand how best to fit ccREL into HTML5.

Matt
--
Matt Bonner
Hewlett-Packard Company

[Julian Reschke]

Bonner, Matt wrote:
> ...
> Well, for example, HTML5 provides the data-* attributes. Could ccREL
> use those instead?  To flip what you have said, perhaps reading/skimming
> the "extensions" sections HTML5 spec would help the ccREL advocates
> understand how best to fit ccREL into HTML5.
> ...

No, it can't. At least not without working against it's intended use:

"Custom data attributes are intended to store custom data private to the
page or application, for which there are no more appropriate attributes
or elements." -- <http://www.w3.org/html/wg/html5/#custom>

BR, Julian

[Ian Hickson]

On Fri, 22 Aug 2008, Bonner, Matt wrote:
>
> Well, for example, HTML5 provides the data-* attributes. Could ccREL use
> those instead?  To flip what you have said, perhaps reading/skimming the
> "extensions" sections HTML5 spec would help the ccREL advocates
> understand how best to fit ccREL into HTML5.

The HTML5 spec admittedly doesn't make that very easy, but there's an
entry in the FAQ that covers the main extension points:

   http://wiki.whatwg.org/wiki/FAQ#HTML5_should_support_a_way_for_anyone_to_invent_new_elements.21

For example, RDF n3 could be included directly (and unambiguously) using
the <script type="..."> extension mechanism.

HTH,
--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

[Julian Reschke]

Ian Hickson wrote:

> On Fri, 22 Aug 2008, Bonner, Matt wrote:
>> Well, for example, HTML5 provides the data-* attributes. Could ccREL use
>> those instead?  To flip what you have said, perhaps reading/skimming the
>> "extensions" sections HTML5 spec would help the ccREL advocates
>> understand how best to fit ccREL into HTML5.
>
> The HTML5 spec admittedly doesn't make that very easy, but there's an
> entry in the FAQ that covers the main extension points:
>
>    http://wiki.whatwg.org/wiki/FAQ#HTML5_should_support_a_way_for_anyone_to_invent_new_elements.21
>
> For example, RDF n3 could be included directly (and unambiguously) using
> the <script type="..."> extension mechanism.

"The script element allows authors to include dynamic script and script
data in their documents." -- <http://www.w3.org/html/wg/html5/#script>

BR, Julian

[Křištof Želechovski]

The META element provides the generic syntax for adding metadata inside
HTML.  Note that you can have arbitrary serialized markup in the content
attribute value.
Chris

-----Original Message-----
From: Ben Adida [mailto:ben@...]
Sent: Friday, August 22, 2008 1:29 AM
To: Ian Hickson
Cc: Dan Brickley; Kristof Zelechovski; Tab Atkins Jr.; Bonner, Matt; Henri
Sivonen; www-archive@...
Subject: Re: [whatwg] Creative Commons Rights Expression Language

Ian Hickson wrote:
> 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.

[Ian Hickson]

On Fri, 22 Aug 2008, Julian Reschke wrote:

> Ian Hickson wrote:
> > On Fri, 22 Aug 2008, Bonner, Matt wrote:
> > > Well, for example, HTML5 provides the data-* attributes. Could ccREL use
> > > those instead?  To flip what you have said, perhaps reading/skimming the
> > > "extensions" sections HTML5 spec would help the ccREL advocates understand
> > > how best to fit ccREL into HTML5.
> >
> > The HTML5 spec admittedly doesn't make that very easy, but there's an entry
> > in the FAQ that covers the main extension points:
> >
> >    http://wiki.whatwg.org/wiki/FAQ#HTML5_should_support_a_way_for_anyone_to_invent_new_elements.21
> >
> > For example, RDF n3 could be included directly (and unambiguously) using the
> > <script type="..."> extension mechanism.
>
> "The script element allows authors to include dynamic script and script data
> in their documents." -- <http://www.w3.org/html/wg/html5/#script>

Right, this would be script data.

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

[Julian Reschke]

Ian Hickson wrote:

> On Fri, 22 Aug 2008, Julian Reschke wrote:
>> Ian Hickson wrote:
>>> On Fri, 22 Aug 2008, Bonner, Matt wrote:
>>>> Well, for example, HTML5 provides the data-* attributes. Could ccREL use
>>>> those instead?  To flip what you have said, perhaps reading/skimming the
>>>> "extensions" sections HTML5 spec would help the ccREL advocates understand
>>>> how best to fit ccREL into HTML5.
>>> The HTML5 spec admittedly doesn't make that very easy, but there's an entry
>>> in the FAQ that covers the main extension points:
>>>
>>>    http://wiki.whatwg.org/wiki/FAQ#HTML5_should_support_a_way_for_anyone_to_invent_new_elements.21
>>>
>>> For example, RDF n3 could be included directly (and unambiguously) using the
>>> <script type="..."> extension mechanism.
>> "The script element allows authors to include dynamic script and script data
>> in their documents." -- <http://www.w3.org/html/wg/html5/#script>
>
> Right, this would be script data.

How is this script data? Where's the script?

BR, Julian

[Křištof Želechovski]

The script can be specified in the src attribute of the SCRIPT element or
embedded inline in some cases (e.g. when the inline content does not contain
the text "</script").  The content of the SCRIPT element would contain the
metadata directly as XML text.
Chris

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@...]
Sent: Friday, August 22, 2008 9:45 PM
To: Ian Hickson
Cc: Bonner, Matt; Ben Adida; Dan Brickley; Kristof Zelechovski; Tab Atkins
Jr.; Henri Sivonen; www-archive@...
Subject: Re: [whatwg] Creative Commons Rights Expression Language

Ian Hickson wrote:
> On Fri, 22 Aug 2008, Julian Reschke wrote:
>> Ian Hickson wrote:
>>> On Fri, 22 Aug 2008, Bonner, Matt wrote:
>>>> Well, for example, HTML5 provides the data-* attributes. Could ccREL
use
>>>> those instead?  To flip what you have said, perhaps reading/skimming
the
>>>> "extensions" sections HTML5 spec would help the ccREL advocates
understand
>>>> how best to fit ccREL into HTML5.
>>> The HTML5 spec admittedly doesn't make that very easy, but there's an
entry
>>> in the FAQ that covers the main extension points:
>>>
>>>
http://wiki.whatwg.org/wiki/FAQ#HTML5_should_support_a_way_for_anyone_to_inv
ent_new_elements.21
>>>
>>> For example, RDF n3 could be included directly (and unambiguously) using
the
>>> <script type="..."> extension mechanism.
>> "The script element allows authors to include dynamic script and script
data
>> in their documents." -- <http://www.w3.org/html/wg/html5/#script>
>
> Right, this would be script data.

How is this script data? Where's the script?

BR, Julian

[Ian Hickson]

On Fri, 22 Aug 2008, Julian Reschke wrote:

> Ian Hickson wrote:
> > On Fri, 22 Aug 2008, Julian Reschke wrote:
> > > Ian Hickson wrote:
> > > > On Fri, 22 Aug 2008, Bonner, Matt wrote:
> > > > > Well, for example, HTML5 provides the data-* attributes. Could ccREL
> > > > > use
> > > > > those instead?  To flip what you have said, perhaps reading/skimming
> > > > > the
> > > > > "extensions" sections HTML5 spec would help the ccREL advocates
> > > > > understand
> > > > > how best to fit ccREL into HTML5.
> > > > The HTML5 spec admittedly doesn't make that very easy, but there's an
> > > > entry
> > > > in the FAQ that covers the main extension points:
> > > >
> > > >    http://wiki.whatwg.org/wiki/FAQ#HTML5_should_support_a_way_for_anyone_to_invent_new_elements.21
> > > >
> > > > For example, RDF n3 could be included directly (and unambiguously) using
> > > > the
> > > > <script type="..."> extension mechanism.
> > > "The script element allows authors to include dynamic script and script
> > > data
> > > in their documents." -- <http://www.w3.org/html/wg/html5/#script>
> >
> > Right, this would be script data.
>
> How is this script data? Where's the script?

Hm, you're right, the terminology here isn't great. I've updated HTML5 to
unambiguously allow this.

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

[Julian Reschke]

Kristof Zelechovski wrote:
> The script can be specified in the src attribute of the SCRIPT element or
> embedded inline in some cases (e.g. when the inline content does not contain
> the text "</script").  The content of the SCRIPT element would contain the
> metadata directly as XML text.
> Chris

I still don't see a script.

I have no problem saying "script" is a generic extension point for all
kind of data, but then the spec needs to say so.

BR, Julian

[Ben Adida-2]

Bonner, Matt wrote:
>> 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.
>
> Is that the only point of discussion?

No, it definitely isn't if we're talking about how RDFa fits into HTML5.
But I think you're the one who brought that up, I was just explaining
where CC is coming from :)

> Well, if you used <link> instead of <a>,

<link> doesn't support DRY (the user doesn't see the link to the
license), and it's only in the head, so we can't pass out a small chunk
of HTML that folks can embed in their page.

That's explained in the ccREL paper, under the principles of DRY and
self-containment.

> Well, section 3.1 of the Submission says:
>
>   "A publisher who wishes to license a Work under a Creative
>   Commons license must, at a minimum, provide one RDF triple that
>   specifies the value of the Work's license property"

That's the onus on the *publisher*, to provide at a *minimum*.

But we have specific publishers, e.g. some pharma and biotech companies,
that want to publish a *lot* more, including genomic data, protein
information, etc... using RDFa and CC licensing.

A simpler example that appears clearly in the ccREL paper:
cc:attributionName, and cc:attributionURL.

So, while publishers don't *have* to publish those, they are much
encouraged to, and so the tools should support it. Ideally the tools
will include HTML5.

> Perhaps it would be better to start over and engage the HTML5
> community on your requirements, what makes sense and proceed from there?

Sure, although again I got roped into a conversation that *you* started :)

> Well, for example, HTML5 provides the data-* attributes. Could ccREL
> use those instead?

As mentioned in my previous email and by others, that really doesn't fit
the definition of the data-* attributes, and it's sub-optimal from the
point of view that this is highly HTML5-specific, which would break with
our established work in XHTML1.1.

If HTML5 can tell browsers to ignore data-* attributes, I think it can
probably choose to ignore a few more attributes, right?

-Ben

[Ben Adida-2]

Ian Hickson wrote:
> For example, RDF n3 could be included directly (and unambiguously) using
> the <script type="..."> extension mechanism.

You really read the ccREL proposal? :)

We want DRY, so that human-rendered data and machine-readable data can
be kept in sync at all times. That goes to your point about unmaintained
metadata. Metadata is much more likely be maintained if it has a
user-visible component.

This is actually a principle that the microformats community touted
before we did, and we strongly agree with it.

-Ben

[Ben Adida-2]

Kristof Zelechovski wrote:
> The script can be specified in the src attribute of the SCRIPT element or
> embedded inline in some cases (e.g. when the inline content does not contain
> the text "</script").  The content of the SCRIPT element would contain the
> metadata directly as XML text.

See my answer to Ian on DRY. We don't want standalone metadata. We want
to mark up the content the user already see. That's crucial for
maintaining the relevance of the metadata.

-Ben

[Křištof Želechovski]

Why do you call inline metadata standalone?
I can see two ways to bind the metadata to the markup:
1. For elements with nonempty content, you can embed this script into the
element.
2.The IMG elements are not subject to CC licenses because they do not
constitute main content but they serve as replacements for various user
interface elements.  However, if you insist, you could have <IMG
license="your XML">.  That would make a viable solution.
It seems your main problem is that you cannot put the licenses into
proprietary formats and you want to put the burden on HTML, seeking to put
the data as close to the reference to the describing document as possible
and hoping that that will make the license "relevant".  I do not like this
catch-and-patch attitude at all.  This is far from being a systematic
solution.  It is crucial for the relevance of metadata that the license tag
gets attached firmly onto the documents described.  The META tag can be used