Difference between revisions of "Extend Metadata"

From Creative Commons
Jump to: navigation, search
(fresh)
Line 9: Line 9:
 
If you've got comments or suggestions on any of this, don't hesitate to [[Contact|send us a note]].
 
If you've got comments or suggestions on any of this, don't hesitate to [[Contact|send us a note]].
  
== Defining dc:rights ==
+
== Defining <code>dc:rights</code> ==
  
 
Use of the Dublin Core dc:rights element has long been fraught with confusion and misunderstanding. A study of its use in practice shows a variety of different purposes and formats with little commonality. For the Creative Commons metadata specification, we wanted to define a profile of the rights element that was more useful and structured.
 
Use of the Dublin Core dc:rights element has long been fraught with confusion and misunderstanding. A study of its use in practice shows a variety of different purposes and formats with little commonality. For the Creative Commons metadata specification, we wanted to define a profile of the rights element that was more useful and structured.

Revision as of 21:57, 12 April 2006

Extending Creative Commons Metadata

Familiar with RDF and want to know how this fits in with the larger picture?

If you've got comments or suggestions on any of this, don't hesitate to send us a note.

Defining dc:rights

Use of the Dublin Core dc:rights element has long been fraught with confusion and misunderstanding. A study of its use in practice shows a variety of different purposes and formats with little commonality. For the Creative Commons metadata specification, we wanted to define a profile of the rights element that was more useful and structured.

Most copyright statements consist of a statement of the date and copyright holder (i.e. "(C) 2002 Gnomovision Records. All rights reserved.") and the actual text of the legal license. The date can be described using dc:date, the copyright holder using dc:rights and the license can be linked to with cc:license.

We've decided to use dc:rights to hold a more structured description of the copyright holder. Here's an example:

<dc:rights>
  <Agent rdf:about="http://me.yoyo.dyne.name/">
    <dc:title>Yo-Yo Dyne</dc:title>
    <dc:date>1001-10-01</dc:date>
  </Agent>

</dc:rights>

As you can see the copyright holder is a person with a URL, a name and a date (of birth).

In this way we cover all the parts of the copyright notice in a way that RDF tools can deal with. As a full example, this plain text statement:

(C) 2002 Gnomovision Records. All rights reserved.

This document has NO WARRANTY. You are permitted to 
copy it, modify it, and place up to three (3) copies 
of it on the White House lawn.

becomes this chunk of RDF:

<rdf:Description>
  <dc:date>2002</dc:date>
  <cc:license rdf:resource="http://flf.org/licenses/whiteHouseLawn" />
  <dc:rights><Agent>
    <dc:title>Gnomovision Records</dc:title>
  </Agent></dc:rights>
</rdf:Description>

Note: The actual text and description of the license ("...place up to three (3) copies...") is not included in this RDF, but would presumably be available at the URL given for the license.

Embedding RDF in HTML

There may be lots of RDF out there, but it's no good if no one can find it. Since almost everything on the Web is HTML, we need a good way to hook RDF into the HTML Web. Here are the best ways to do so:

LINKing to it

RDF can be kept in a separate file (filename.rdf) and linked to using <link rel="meta" type="application/rdf+xml" ... /> or an equivalent a href tag.

  • Pro: Doesn't break anything.
  • Con: Requires users to make files. Not supported by all readers.

In the HEAD

RDF can be included inline in the <head> tag of the document, along with the title and any <link>s.

  • Pro: Should be ignored by browsers.
  • Con: Not all users may be able to. Doesn't validate.

In the BODY

RDF can be included inline in the <body> of the document, like any other HTML.

  • Pro: Super simple.
  • Con: RDF needs to be formatted as attributes. May cause problems with some browsers. Doesn't validate.

In META

A reference to the license a web page is offered under may be included in a <meta> tag in the document's <head>.

Example:

<meta name="DC.rights"
      scheme="DCTERMS.URI"
      content="http://creativecommons.org/licenses/by-sa/2.0/" />
<meta name="DC.rights"
      content="(c) 2002 Gnomovision Records" />
  • Pro: Won't break anything.
  • Con: Not all users may be able to. Not RDF (included in this list due to obviousness). Limited to statements about the current page.

Further reading: Expressing Dublin Core in HTML/XHTML meta and link elements

As an element attribute

A rel="license" attribute may be added to an "a" anchor element in HTML/XMTML. Example:

This work is licensed under the <a rel="license"
    href="http://creativecommons.org/licenses/by/2.0/">Creative
    Commons Attribution License</a>.
  • Pro: Super simple, validates.
  • Con: Not RDF (however may be used to generate RDF in a GRDDL fashion). Limited to statements about the current page.

Further reading: small-s semantic web and CC.

In a comment

The RDF can be included in a in the document. The TrackBack system embeds its RDF in this way.

Note that if a literal "--" is included in a comment, it must be encoded as "--".

  • Pro: Won't break anything. Super simple.
  • Con: Not supported by all readers. Makes people queasy.

Conclusions

RDF readers should support all of these methods.

We use and recommend the "in the comment" method, since it's easy and won't break anything. Hopefully tools that don't yet support it will be upgraded to do so. Two examples: ccValidator and mozCC.

Further reading: Embedding RDF in HTML