Difference between revisions of "Web Statement"
Jon Phillips (talk | contribs) |
(minor updating) |
||
Line 6: | Line 6: | ||
'''This is a developer-oriented document. Read our [[Embedded Metadata|non-technical account with explanatory comics]] first.''' | '''This is a developer-oriented document. Read our [[Embedded Metadata|non-technical account with explanatory comics]] first.''' | ||
− | License metadata for | + | License metadata for web pages is published with the content it describes. If someone publishes false metadata, it can be taken down or corrected. |
But with non-web content (such as files on peer-to-peer networks), incorrect metadata can propagate around the network, since it's extremely difficult to get everyone to correct it. | But with non-web content (such as files on peer-to-peer networks), incorrect metadata can propagate around the network, since it's extremely difficult to get everyone to correct it. | ||
Line 18: | Line 18: | ||
</div> | </div> | ||
− | + | The URL for the page that includes license metadata for a file is known as a '''WebStatement''' URL after the name used in [[XMP]]. | |
+ | |||
+ | The page at the WebStatement URL should also identify the licensed media file with a content-derived identifier (e.g., SHA1 hash, see example below) so that a program can verify that the page is making a license assertion about the media file at hand. | ||
This has additional benefits besides preventing the propagation of incorrect license metadata: the metadata can now be linked to and indexed by search engines. Imagine searching the Web for music under a Creative Commons license, and then downloading it from a peer-to-peer network. | This has additional benefits besides preventing the propagation of incorrect license metadata: the metadata can now be linked to and indexed by search engines. Imagine searching the Web for music under a Creative Commons license, and then downloading it from a peer-to-peer network. | ||
Line 34: | Line 36: | ||
* [[MP3]] | * [[MP3]] | ||
* [[OGG]] | * [[OGG]] | ||
+ | * [[XMP]] (PDF, JPEG, all others) | ||
'''Step two: building the license info page.''' The license info page must have or HTTP redirect to a page that has RDF, or RDF [[#Extend Metadata|embedded in HTML comments]]. (Readers should be ready to follow several HTTP redirects.) | '''Step two: building the license info page.''' The license info page must have or HTTP redirect to a page that has RDF, or RDF [[#Extend Metadata|embedded in HTML comments]]. (Readers should be ready to follow several HTTP redirects.) | ||
Line 73: | Line 76: | ||
== Tools == | == Tools == | ||
− | [ | + | [[ccLookup]] and [[ccPublisher]] offer GUI tools for MP3 license claim embedding and verification metadata generation. Available for Linux, OS X, and Windows. |
Revision as of 02:27, 19 October 2006
Contents
Using Creative Commons Metadata in Non-Web Content
This is a developer-oriented document. Read our non-technical account with explanatory comics first.
License metadata for web pages is published with the content it describes. If someone publishes false metadata, it can be taken down or corrected.
But with non-web content (such as files on peer-to-peer networks), incorrect metadata can propagate around the network, since it's extremely difficult to get everyone to correct it.
Our solution is to embed a link to a license info page that includes the license metadata, rather than including it directly in the file. For example:
mysong.mp3
links to http://example.com/licenseinfo
(using ID3 tags)
http://example.com/licenseinfo
says the work is available under http://creativecommons.org/licenses/by/2.0/
(using HTML and RDF)
The URL for the page that includes license metadata for a file is known as a WebStatement URL after the name used in XMP.
The page at the WebStatement URL should also identify the licensed media file with a content-derived identifier (e.g., SHA1 hash, see example below) so that a program can verify that the page is making a license assertion about the media file at hand.
This has additional benefits besides preventing the propagation of incorrect license metadata: the metadata can now be linked to and indexed by search engines. Imagine searching the Web for music under a Creative Commons license, and then downloading it from a peer-to-peer network.
Third parties can also build authentication services that provide additional assurance that the data is valid.
Security Considerations
Software will automatically download the license info page. Security impact: Anyone who can get you to download their file, just like anyone who can get you to visit their web page, can get you to visit another page and discover your IP address.
Implementation
Step one: linking to the license info page. We have guides on how to do this in different file formats:
Step two: building the license info page. The license info page must have or HTTP redirect to a page that has RDF, or RDF embedded in HTML comments. (Readers should be ready to follow several HTTP redirects.)
Example RDF:
<rdf:RDF xmlns="http://web.resource.org/cc/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"> <Work rdf:about="urn:sha1:MSMBC5VEUDLTC26UT5W7GZBAKZHCY2MD"> <dc:date>2003</dc:date> <dc:format>audio/mpeg</dc:format> <dc:identifier>http://example.com/mp3s/test.mp3</dc:identifier> <dc:rights><Agent><dc:title>ExampleBand</dc:title></Agent></dc:rights> <dc:title>Example Song</dc:title> <dc:type rdf:resource="http://purl.org/dc/dcmitype/Sound" /> <license rdf:resource="http://creativecommons.org/licenses/by/2.0/" /> </Work> <License rdf:about="http://creativecommons.org/licenses/by/2.0/"> <requires rdf:resource="http://web.resource.org/cc/Attribution" /> <permits rdf:resource="http://web.resource.org/cc/Reproduction" /> <permits rdf:resource="http://web.resource.org/cc/Distribution" /> <permits rdf:resource="http://web.resource.org/cc/DerivativeWorks" /> <requires rdf:resource="http://web.resource.org/cc/Notice" /> </License> </rdf:RDF>
rdf:RDF
contains one or more Work
elements. The value of their rdf:about
attributes are content-based URIs that can be verified by the user (in this case, a sha1 URN). All the children of Work
are optional. If you want to describe their licenses then there must be a license
license child and a corresponding License
element.
In the above example, dc:identifier
is a URL from which the content described may be obtained. It can also be used to identify other content-based names for the work.
Step three: publish the license info page. Publish license info RDF at the license claim URL specified in the embedded metadata (step one).
Tools
ccLookup and ccPublisher offer GUI tools for MP3 license claim embedding and verification metadata generation. Available for Linux, OS X, and Windows.