Subject: Best Practices for Extended Metadata

From: "Nathan Yergler" <[email-masked]>
Date: Wed, 10 Oct 2007 11:16:51 -0700

Creative Commons is currently working on implementation suggestions
for how people can indicate that additional permissions are available
outside the scope of a CC license.  We've been referring to this as
CC+ ("CC Plus").  CC+ is a very simple system that associates a "more
permissions" URL with a work.  Having this URL in a machine readable
format is very important.

One file format we're looking at is the Atom syndication format, and
we have two different ideas for how we might implement this; I'm
seeking feedback regarding best practices. One option is to use link
with a custom rel; for example:

<link rel="http://creativecommons.org/ns#morePermissions"
href="http://example.com/commercial_license_purchase" />

The alternative is using RDFa
(http://www.w3.org/2006/07/SWD/RDFa/primer) as part of an XHTML
content payload.

You can find examples of both at http://wiki.creativecommons.org/Atom.

Is there a feeling regarding the use of additional <link>s in feeds?
Does most software just throw those away if it doesn't understand the
rel?

Thanks for any feedback;

Nathan

-----
Nathan R. Yergler
Chief Technology Officer
Creative Commons

http://wiki.creativecommons.org/User:NathanYergler

---

From: James M Snell <[email-masked]>
Date: Wed, 10 Oct 2007 12:34:24 -0700

Several ideas,

First off, RFC4287 explicitly allows the atom:link element to contain
child elements.  The downside is that, other than Abdera, I'm not aware
of any client or library that would surface such extensions.  So in
theory, the following would be possible:

  <link rel="license" href="http://creativecommons.org/...">
    <cc:additional_stuff>
      ...
    </cc:additional_stuff>
  </link>

Alternatively, there's nothing to say that the href in the license link
cannot be a fragment identifier, e.g.

  <link rel="license" href="#license" />
  <cc:additional_stuff>
    ...
  </cc:additional_stuff>

But again, it's not clear to me what most clients would be able to make
of this kind of thing.

Using the license link to point to an external doc with the extended
data would probably be the most successful approach.

- James

---

From: Eric Scheid <[email-masked]>
Date: Thu, 11 Oct 2007 08:54:44 +1000

> Does most software just throw those away if it doesn't understand the

more are welcome, some aggregators/readers are smart enough to expose those
extra links

e.

---

From: "Joe Gregorio" <[email-masked]>
Date: Fri, 12 Oct 2007 10:34:34 -0400

> href="http://example.com/commercial_license_purchase" />

This is definitely the preferred option, as you can't guarantee
that everyone can produce XHTML content.

> Does most software just throw those away if it doesn't understand the

Even if true I don't think it matters as you've stated that this is
supposed to be a machine readable URL, so applications
that understand the rel will know what to do with it, and others
that don't will ignore it.

   -joe

-- 
Joe Gregorio        http://bitworking.org

---

From: Mike Linksvayer <[email-masked]>
Date: Fri, 12 Oct 2007 13:50:48 -0700

> that everyone can produce XHTML content.

You also can't guarantee that everyone can add <link> elements, let
alone ones with custom rel values.

Both link-with-custom-rel-value and custom-metadadata-in-content are
pretty poor from an adoption standpoint (not a criticism, nor even a
technology problem), unless you control both ends.

The question is really whether CC's recommendation should mention both
methods, or only one, and if only one, which.  Because adoption
characteristics of both are bad, my bias is to recommend only one,
concentrating any implementations on that, and because I'm biased
against metadata that is very unlikely to be rendered for humans and
because my guess is far more real users will be able to publish XHTML in
content than will be able to add links, my bias is to recommend the
former.

But I encouraged Nathan to ask here in the hope that real experts would
smash my biases. :)

-- 
 http://wiki.creativecommons.org/User:Mike_Linksvayer

---

From: "Joe Gregorio" <[email-masked]>
Date: Fri, 12 Oct 2007 17:05:38 -0400

On 10/12/07, Mike Linksvayer <[email-masked]> wrote:
> because my guess is far more real users

OK, if those are the real requirements then I'd suggest
"none of the above". If you really want your link 'rendered'
and seen by 'real' users then it needs to be embedded
in HTML. You can pick a @rel like microformats has
done for tags.

In that case 'machine readable' means using html5lib:

  http://wiki.whatwg.org/wiki/HTML5Lib

   -joe

---

From: Mike Linksvayer <[email-masked]>
Date: Fri, 12 Oct 2007 14:54:44 -0700

> in HTML. You can pick a @rel like microformats has

Ok, that's exactly what I was biased in favor of, modulo
microformats->RDFa.

Thanks for the feedback!

Mike

---

From: "Joe Gregorio" <[email-masked]>
Date: Fri, 12 Oct 2007 19:43:37 -0400

> Ok, that's exactly what I was biased in favor of, modulo

We seem to have a disconnect, isn't RDFa only for XHTML?

   -joe

---

From: Mike Linksvayer <[email-masked]>
Date: Fri, 12 Oct 2007 16:58:49 -0700

> We seem to have a disconnect, isn't RDFa only for XHTML?

Works in HTML but causes that HTML to not validate (on the off chance
it did before).

Separate issue from what I intended to bring up, which imagining use of
uFs instead of custom link rel values surfaces just as well.

---

From: Eric Scheid <[email-masked]>
Date: Sat, 13 Oct 2007 10:40:35 +1000

> (http://www.w3.org/2006/07/SWD/RDFa/primer) as part of an XHTML

Assuming you have an X/HTML payload, that is. Not so useful for images,
sounds, clips, and other media where you want to declare the CC license.

e.

---

From: "Edward O'Connor" <[email-masked]>
Date: Mon, 15 Oct 2007 16:13:45 -0400

> sounds, clips, and other media where you want to declare the CC license.

Well, you could have (X)HTML in atom:rights.

Ted

-- 
Edward O'Connor
[email-masked]

Ense petit placidam sub libertate quietem.

---

From: Eric Scheid <[email-masked]>
Date: Tue, 16 Oct 2007 12:32:49 +1000

> Well, you could have (X)HTML in atom:rights.

hmmm ... you could, and that might be a sneaky way past the spec saying
atom:rights wasn't intended to be machine readable.

> 4.2.10.  The "atom:rights" Element

>  The atom:rights element SHOULD NOT be used to convey machine-readable
>  licensing information.

e.

---

From: "Edward O'Connor" <[email-masked]>
Date: Tue, 16 Oct 2007 03:12:33 -0400

>> The atom:rights element SHOULD NOT be used to convey machine-readable

Hmm. OK, this is interesting.

I have a blog. (The backing store for this blog happens to be Atom Entry
Documents, but I suspect that mightn't matter in this case.) Entries of
this blog often have atom:rights that look like so:

  <atom:rights type="xhtml">
    <div xmlns="http://www.w3.org/1999/xhtml">
      Copyright &#169; 2007
      <a href="http://edward.oconnor.cx/">Edward O&#8217;Connor</a>.
      <a href="http://creativecommons.org/licenses/by-sa/3.0/"
         rel="license">Some rights reserved (CC BY-SA 3.0).</a>
    </div>
  </atom:rights>

It happens to be the case that the XHTML content of this atom:rights
element contains content which conforms to the rel-license microformat,
and thus is, in principle, machine-readable.

Is this invalid? If so, why? If not, why not?

-- 
Edward O'Connor
[email-masked]