Difference between revisions of "Extend Metadata"

From Creative Commons
Jump to: navigation, search
(data:)
Line 76: Line 76:
  
 
* '''Pro:''' It includes the data in the HTML document; it doesn't break old browsers; it's standard-compliant; it uses the proper element (link) for associating metadata
 
* '''Pro:''' It includes the data in the HTML document; it doesn't break old browsers; it's standard-compliant; it uses the proper element (link) for associating metadata
* '''Con:''' It requires the RDF to be URL-encoded; it's hard to read; not all URL libraries can recognize or decode a data: URL; current tools (like MozCC) don't support it
+
* '''Con:''' It requires the RDF to be URL-encoded; it's hard to read; not all URL libraries can recognize or decode a data: URL; Creative Commons tools ([[MozCC]], [[CcLookup]], etc) don't support it
  
 
See also: [http://software.hixie.ch/utilities/cgi/data/data data: URI kitchen] (tool for making data: URLs), [http://www.mozilla.org/quality/networking/docs/aboutdata.html about data: URLs] (from Mozilla)
 
See also: [http://software.hixie.ch/utilities/cgi/data/data data: URI kitchen] (tool for making data: URLs), [http://www.mozilla.org/quality/networking/docs/aboutdata.html about data: URLs] (from Mozilla)

Revision as of 20:03, 23 May 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 an external file

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.

LINKing to a data: URL

A data: URL (see RFC 2397) encapsulates data into the URL itself. If used as the href attribute of a <link> element, it can include an RDF document verbatim.

 <link rel="meta" type="application/rdf+xml" href="data:application/rdf+xml,%3Crdf%3ARDF%20xmlns%3D%22http%3A%2F%2Fweb.resource.org%2Fcc%2F%22%0D%0A%20%20%20%20xmlns%3Adc%3D%22http%3A%2F%2Fpurl.org%2Fdc%2Felements%2F1.1%2F%22%0D%0A%20%20%20%20xmlns%3Ardf%3D%22http%3A%2F%2Fwww.w3.org%2F1999%2F02%2F22-rdf-syntax-ns%23%22%3E%0D%0A%3CWork%20rdf%3Aabout%3D%22http%3A%2F%2Fexample.org%2Fgnomophone.mp3%22%3E%0D%0A%20%20%3Cdc%3Atitle%3ECompilers%20in%20the%20Key%20of%20C%3C%2Fdc%3Atitle%3E%0D%0A%20%20%3Cdc%3Adescription%3EA%20lovely%20classical%20work%20on%20compiling%20code.%3C%2Fdc%3Adescription%3E%0D%0A%20%20%3Cdc%3Acreator%3E%3CAgent%3E%0D%0A%20%20%20%20%3Cdc%3Atitle%3EYo-Yo%20Dyne%3C%2Fdc%3Atitle%3E%0D%0A%20%20%3C%2FAgent%3E%3C%2Fdc%3Acreator%3E%0D%0A%20%20%3Cdc%3Arights%3E%3CAgent%3E%0D%0A%20%20%20%20%3Cdc%3Atitle%3EGnomophone%3C%2Fdc%3Atitle%3E%0D%0A%20%20%3C%2FAgent%3E%3C%2Fdc%3Arights%3E%0D%0A%20%20%3Cdc%3Adate%3E1842%3C%2Fdc%3Adate%3E%0D%0A%20%20%3Cdc%3Aformat%3Eaudio%2Fmpeg%3C%2Fdc%3Aformat%3E%0D%0A%20%20%3Cdc%3Atype%20rdf%3Aresource%3D%22http%3A%2F%2Fpurl.org%2Fdc%2Fdcmitype%2FSound%22%20%2F%3E%0D%0A%20%20%3Cdc%3Asource%20rdf%3Aresource%3D%22http%3A%2F%2Fexample.net%2Fgnomovision.mov%22%20%2F%3E%0D%0A%20%20%3Clicense%20rdf%3Aresource%3D%22http%3A%2F%2Fcreativecommons.org%2Flicenses%2Fby-nc-nd%2F2.0%2F%22%20%2F%3E%0D%0A%20%20%3Clicense%20rdf%3Aresource%3D%22http%3A%2F%2Fwww.eff.org%2FIP%2FOpen_licenses%2Feff_oal.html%22%20%2F%3E%0D%0A%0D%0A%3C%2FWork%3E%0D%0A%0D%0A%3CLicense%20rdf%3Aabout%3D%22http%3A%2F%2Fcreativecommons.org%2Flicenses%2Fby-nc-nd%2F2.0%2F%22%3E%0D%0A%20%20%3Cpermits%20rdf%3Aresource%3D%22http%3A%2F%2Fweb.resource.org%2Fcc%2FReproduction%22%20%2F%3E%0D%0A%20%20%3Cpermits%20rdf%3Aresource%3D%22http%3A%2F%2Fweb.resource.org%2Fcc%2FDistribution%22%20%2F%3E%0D%0A%20%20%3Crequires%20rdf%3Aresource%3D%22http%3A%2F%2Fweb.resource.org%2Fcc%2FNotice%22%20%2F%3E%0D%0A%20%20%3Crequires%20rdf%3Aresource%3D%22http%3A%2F%2Fweb.resource.org%2Fcc%2FAttribution%22%20%2F%3E%0D%0A%20%20%3Cprohibits%20rdf%3Aresource%3D%22http%3A%2F%2Fweb.resource.org%2Fcc%2FCommercialUse%22%20%2F%3E%0D%0A%0D%0A%3C%2FLicense%3E%0D%0A%3C%2Frdf%3ARDF%3E" />
  • Pro: It includes the data in the HTML document; it doesn't break old browsers; it's standard-compliant; it uses the proper element (link) for associating metadata
  • Con: It requires the RDF to be URL-encoded; it's hard to read; not all URL libraries can recognize or decode a data: URL; Creative Commons tools (MozCC, CcLookup, etc) don't support it

See also: data: URI kitchen (tool for making data: URLs), about data: URLs (from Mozilla)

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