Creative Commons - User contributions [en]

Reuse tracking

2012-08-09T21:16:14Z

Jonathan Palecek:

RDF metadata presents information about a work's ancestry in a machine readable way. The websites of users who properly used our license chooser tool already have this setup. While it is possible to trace backwards to find a derived work's source, it is impossible to trace forwards to find all of a source work's derivatives without the aid of extra infrastructure.

In this page, you will find proposals for several ethical (respects user's privacy, does not involve radio-tagging people with malware or drm) solutions to this problem. These may either be systems that Creative Commons would prototype with the intention of being a reference for other organizations to build their own infrastructure; or systems that we would build an maintain our self, and provide an api to interested parties (either free in the spirit of open, or for a small fee to help offset hosting costs). All of the proposed systems below have their own advantages and disadvantages; none of them the silver bullet.

= Proposal 1: Independent Refback Tracking =

When a user opens a webpage, the browser sends some information to the
server. Of particular interest is the /referrer string/. To put it
simply, the referrer string contains the URL of the webpage that
linked the user to the page they are currently viewing.

The Refback Tracking framework would be hosted by respective content
providers, and served independently from CC. This advantage means
that once a working system is prototyped, it would have no hosting
(potentially none). cost for us, and therefor require the minimal
amount of maintenance.

The disadvantage to this approach is it is only able to trace direct
remixes of a work, but not remixes of remixes.

Here is how it works:

[[File:Proposal_1a.png]]

The above picture describes the sequence of events that triggers the
tracking mechanism, shown from the user's perspective. The steps are
like so:

'''1.''' The user opens Website A. Website A contains a remixed work.
The work provides proper attribution to the work which it is derived
from, both visually for the user and invisibly with metadata.

'''2.''' The curious user clicks on the link to the original work, and
is taken to Website B as expected.

Here is what happens behind the scenes:

[[File:Proposal_1b.png]]

'''1.''' The user opens a website. The user's browser requests a page
from a server. The website has a remixed work on it, and is
attributed with metadata. The server replies to the user's request
with the website.

'''2.''' The curious user clicks on the link to the original work.
The user's browser sends a request to the server hosting the page of
the original work. This request's referrer string contains the url of
the webpage with the remixed work on it. The server replies to the
user's request as expected, and takes note of the url in the referrer
string (this can happen either using javascript embedded in the page,
or with special code running on the webserver itself).

'''3.''' The server hosting the original work downloads the page of
the remixed work (as noted from the referrer string). The server of
the remixed work replies as expected. The server hosting the original
work reads the metadata on the download page to verify that it indeed
contains a remixed of the original work. The server notes the url in
a database, to be used for generating reuse statistics.

= Proposal 2: Hosted Refback Tracking =
Hosted Refback Tracking is a variation of the system described in the
first proposal. In this version, Creative Commons hosts the database
server. The page which contains the work that is the target of re-use
tracking will include a small bit of JavaScript, which CC would
provide. This approach requires no changes to the 3rd party servers.
Our license chooser could include an opt-in option, which would
automatically add the JavaScript to the HTML+rdfa license mark.

This approach requires that CC host a service, thus losing the main
advantage of the first proposal. However, this version is easier for
content creators to opt-in, as it requires no modifications to 3rd
party web servers. If this service sees widespread use, the aggregate
data could potential construct a more robust graph than that described
in the first proposal. However, the opt-in nature of this service
makes this unlikely.

Here is how it works:

[[File:Proposal_2.png]]

'''1.''' The user opens a website. The website contains a remixed
work, which is attributed properly and contains the relevant metadata.

'''2.''' The user clicks on the link to the original work; the
corresponding web page opens in the user's browser.

'''3.''' When the page loads, a script on the page sends the referrer
information to the database server run by CC.

(''4.'') The database server reads the metadata from both websites,
and if one is indeed a remix of the other, then this information about
both sites is recorded in our database.

= Proposal 3: Hosted Scraped Data API =

Creative Commons already has two pieces of infrastructure set up that
could be adapted to collect reuse tracking information. These
components are the license badges (when the HTML provided by the
license chooser is used), and the deed scraper (a tool that is used to
show attribution information on the deed page when the user is linked
there from another site). We currently use the license badges to
estimate the usage statistics for our license. Both the license
badges and deed scraper use referrer information to their work.

In this proposal, when a license badge is downloaded, the referrer URL
is stored in a queue. While the queue is not empty, a service
periodically selects a URL from the queue, downloads the page, reads
and reads the metadata on the page. If the metadata indicates a
source work URL, that page would be downloaded and read as well.

This information would allow us to build a bi-directional graph of
usage data, which could be made accessible to 3rd parties via an API
or a dashboard application.

Of the three proposals on this page, this one features the most
aggressive data collection scheme (and therefor the by far most
complete view of usage information). This scheme would also have the
most demanding server load, and like the Hosted Refback Tracking
proposal, would require ongoing maintenance from the tech team.

This scheme requires no modification to 3rd party websites to work, is
completely invisible to the end user, and can be built by extending
our existing infrastructure.

Here is how it works:

[[File:Proposal_3.png]]

'''1.''' User requests a webpage (either one)

'''2.''' The respective server responds to the user's request with the expected files, except for...

'''3.''' The license badge is (usually) served directly by CC. This allows us to build estimated adoption of the different licenses (and of which versions)

'''4.''' On request of a license badge, a CC server could then read the metadata from the corresponding webpage, and use that to maintain a robust graph of re-use information, using metadata.

Note that steps one through three are how things already are. Some of
our existing infrastructure could be adapted to provide step four,
making this proposal fairly easy to implement

Reuse tracking

2012-08-09T21:15:23Z

Jonathan Palecek: /* Proposal 3: Hosted Scraped Data API */

RDF metadata presents information about a work's ancestry in a machine readable way. The websites of users who properly used our license chooser tool already have this setup. While it is possible to trace backwards to find a derived work's source, it is impossible to trace forwards to find all of a source work's derivatives without the aid of extra infrastructure.

In this page, you will find proposals for several ethical (respects user's privacy, does not involve radio-tagging people with malware or drm) solutions to this problem. These may either be systems that Creative Commons would prototype with the intention of being a reference for other organizations to build their own infrastructure; or systems that we would build an maintain our self, and provide an api to interested parties (either free in the spirit of open, or for a small fee to help offset hosting costs). All of the proposed systems below have their own advantages and disadvantages; none of them the silver bullet.

= Proposal 1: Independent Refback Tracking =

When a user opens a webpage, the browser sends some information to the
server. Of particular interest is the /referrer string/. To put it
simply, the referrer string contains the URL of the webpage that
linked the user to the page they are currently viewing.

The Refback Tracking framework would be hosted by respective content
providers, and served independently from CC. This advantage means
that once a working system is prototyped, it would have no hosting
(potentially none). cost for us, and therefor require the minimal
amount of maintenance.

The disadvantage to this approach is it is only able to trace direct
remixes of a work, but not remixes of remixes.

Here is how it works:

[[File:Proposal_1a.png]]

The above picture describes the sequence of events that triggers the
tracking mechanism, shown from the user's perspective. The steps are
like so:

'''1.''' The user opens Website A. Website A contains a remixed work.
The work provides proper attribution to the work which it is derived
from, both visually for the user and invisibly with metadata.

'''2.''' The curious user clicks on the link to the original work, and
is taken to Website B as expected.

Here is what happens behind the scenes:

[[File:Proposal_1b.png]]

'''1.''' The user opens a website. The user's browser requests a page
from a server. The website has a remixed work on it, and is
attributed with metadata. The server replies to the user's request
with the website.

'''2.''' The curious user clicks on the link to the original work.
The user's browser sends a request to the server hosting the page of
the original work. This request's referrer string contains the url of
the webpage with the remixed work on it. The server replies to the
user's request as expected, and takes note of the url in the referrer
string (this can happen either using javascript embedded in the page,
or with special code running on the webserver itself).

'''3.''' The server hosting the original work downloads the page of
the remixed work (as noted from the referrer string). The server of
the remixed work replies as expected. The server hosting the original
work reads the metadata on the download page to verify that it indeed
contains a remixed of the original work. The server notes the url in
a database, to be used for generating reuse statistics.

= Proposal 2: Hosted Refback Tracking =
Hosted Refback Tracking is a variation of the system described in the
first proposal. In this version, Creative Commons hosts the database
server. The page which contains the work that is the target of re-use
tracking will include a small bit of JavaScript, which CC would
provide. This approach requires no changes to the 3rd party servers.
Our license chooser could include an opt-in option, which would
automatically add the JavaScript to the HTML+rdfa license mark.

This approach requires that CC host a service, thus losing the main
advantage of the first proposal. However, this version is easier for
content creators to opt-in, as it requires no modifications to 3rd
party web servers. If this service sees widespread use, the aggregate
data could potential construct a more robust graph than that described
in the first proposal. However, the opt-in nature of this service
makes this unlikely.

Here is how it works:

[[File:Proposal_2.png]]

'''1.''' The user opens a website. The website contains a remixed
work, which is attributed properly and contains the relevant metadata.

'''2.''' The user clicks on the link to the original work; the
corresponding web page opens in the user's browser.

'''3.''' When the page loads, a script on the page sends the referrer
information to the database server run by CC.

(''4.'') The database server reads the metadata from both websites,
and if one is indeed a remix of the other, then this information about
both sites is recorded in our database.

= Proposal 3: Hosted Scraped Data API =

Creative Commons already has two pieces of infrastructure set up that
could be adapted to collect reuse tracking information. These
components are the license badges (when the HTML provided by the
license chooser is used), and the deed scraper (a tool that is used to
show attribution information on the deed page when the user is linked
there from another site). We currently use the license badges to
estimate the usage statistics for our license. Both the license
badges and deed scraper use referrer information to their work.

In this proposal, when a license badge is downloaded, the referrer URL
is stored in a queue. While the queue is not empty, a service
periodically selects a URL from the queue, downloads the page, reads
and reads the metadata on the page. If the metadata indicates a
source work URL, that page would be downloaded and read as well.

This information would allow us to build a bi-directional graph of
usage data, which could be made accessible to 3rd parties via an API
or a dashboard application.

Of the three proposals on this page, this one features the most
aggressive data collection scheme (and therefor the by far most
complete view of usage information). This scheme would also have the
most demanding server load, and like the Hosted Refback Tracking
proposal, would require ongoing maintenance from the tech team.

This scheme requires no modification to 3rd party websites to work, is
completely invisible to the end user, and can be built by extending
our existing infrastructure.

Here is how it works:

[[File:Proposal_3.png]]

'''1.''' User requests a webpage (either one)

'''2.''' The respective server responds to the user's request with the
expected files, except for...

'''3.''' The license badge is (usually) served directly by CC. This allows
us to build estimated adoption of the different licenses (and of
which versions)

'''4.''' On request of a license badge, a CC server could
then read the metadata from the corresponding webpage, and use that
to maintain a robust graph of re-use information, using metadata.

Note that steps one through three are how things already are. Some of
our existing infrastructure could be adapted to provide step four,
making this proposal fairly easy to implement

Reuse tracking

2012-08-09T20:56:18Z

Jonathan Palecek: /* Proposal 3: Hosted Scraped Data API */

RDF metadata presents information about a work's ancestry in a machine readable way. The websites of users who properly used our license chooser tool already have this setup. While it is possible to trace backwards to find a derived work's source, it is impossible to trace forwards to find all of a source work's derivatives without the aid of extra infrastructure.

In this page, you will find proposals for several ethical (respects user's privacy, does not involve radio-tagging people with malware or drm) solutions to this problem. These may either be systems that Creative Commons would prototype with the intention of being a reference for other organizations to build their own infrastructure; or systems that we would build an maintain our self, and provide an api to interested parties (either free in the spirit of open, or for a small fee to help offset hosting costs). All of the proposed systems below have their own advantages and disadvantages; none of them the silver bullet.

= Proposal 1: Independent Refback Tracking =

When a user opens a webpage, the browser sends some information to the
server. Of particular interest is the /referrer string/. To put it
simply, the referrer string contains the URL of the webpage that
linked the user to the page they are currently viewing.

The Refback Tracking framework would be hosted by respective content
providers, and served independently from CC. This advantage means
that once a working system is prototyped, it would have no hosting
(potentially none). cost for us, and therefor require the minimal
amount of maintenance.

The disadvantage to this approach is it is only able to trace direct
remixes of a work, but not remixes of remixes.

Here is how it works:

[[File:Proposal_1a.png]]

The above picture describes the sequence of events that triggers the
tracking mechanism, shown from the user's perspective. The steps are
like so:

'''1.''' The user opens Website A. Website A contains a remixed work.
The work provides proper attribution to the work which it is derived
from, both visually for the user and invisibly with metadata.

'''2.''' The curious user clicks on the link to the original work, and
is taken to Website B as expected.

Here is what happens behind the scenes:

[[File:Proposal_1b.png]]

'''1.''' The user opens a website. The user's browser requests a page
from a server. The website has a remixed work on it, and is
attributed with metadata. The server replies to the user's request
with the website.

'''2.''' The curious user clicks on the link to the original work.
The user's browser sends a request to the server hosting the page of
the original work. This request's referrer string contains the url of
the webpage with the remixed work on it. The server replies to the
user's request as expected, and takes note of the url in the referrer
string (this can happen either using javascript embedded in the page,
or with special code running on the webserver itself).

'''3.''' The server hosting the original work downloads the page of
the remixed work (as noted from the referrer string). The server of
the remixed work replies as expected. The server hosting the original
work reads the metadata on the download page to verify that it indeed
contains a remixed of the original work. The server notes the url in
a database, to be used for generating reuse statistics.

= Proposal 2: Hosted Refback Tracking =
Hosted Refback Tracking is a variation of the system described in the
first proposal. In this version, Creative Commons hosts the database
server. The page which contains the work that is the target of re-use
tracking will include a small bit of JavaScript, which CC would
provide. This approach requires no changes to the 3rd party servers.
Our license chooser could include an opt-in option, which would
automatically add the JavaScript to the HTML+rdfa license mark.

This approach requires that CC host a service, thus losing the main
advantage of the first proposal. However, this version is easier for
content creators to opt-in, as it requires no modifications to 3rd
party web servers. If this service sees widespread use, the aggregate
data could potential construct a more robust graph than that described
in the first proposal. However, the opt-in nature of this service
makes this unlikely.

Here is how it works:

[[File:Proposal_2.png]]

'''1.''' The user opens a website. The website contains a remixed
work, which is attributed properly and contains the relevant metadata.

'''2.''' The user clicks on the link to the original work; the
corresponding web page opens in the user's browser.

'''3.''' When the page loads, a script on the page sends the referrer
information to the database server run by CC.

(''4.'') The database server reads the metadata from both websites,
and if one is indeed a remix of the other, then this information about
both sites is recorded in our database.

= Proposal 3: Hosted Scraped Data API =

Creative Commons already has two pieces of infrastructure that could
be adapted to be used for reuse tracking. When a website uses the
HTML provided by our license chooser to mark the page with attribution
information and metadata, the badge icon is hosted by us as well. We
are able to use the download statistics of these images to create an
estimation of license usage in the wild, using the referrer string in
requests for the image. We have a tool called Deedscraper which, when
a deed is opened, javascript on the page sends the referrer string to
the Deedscraper server, which reads the metadata on the referring
page. This is used so that the deed can be safely updated after page
load with information for attributing the linked work.

This version proposes that when we get the referring string from the
download request for a license badge, deedscraper reads the metadata
from that page, and takes note of it in a database. Thus, we can
build a bi-directional graph of remixes. This data could be made
available through a simple API or dashboard.

This service would yield significantly better data than the first two
proposals, would be straight forward to set up, but would require
ongoing maintenance by the tech team, and make Kinkade very grumpy.

[[File:Proposal_3.png]]

File:Proposal 3.png

2012-08-09T20:55:08Z

Jonathan Palecek: 1. User requests a webpage (either one) 2. The respective server responds to the user's request with the expected files, except for... 3. The license badge is (usually) served directly by CC. This allows us to build estimated adoption of the different...

1. User requests a webpage (either one)
2. The respective server responds to the user's request with the expected files, except for...
3. The license badge is (usually) served directly by CC. This allows us to build estimated adoption of the different licenses (and of which versions)
4. On request of a license badge, a CC server could then read the metadata from the corresponding webpage, and use that to maintain a robust graph of re-use information, using metadata.

Note that steps one through three are how things ''already are''. Some of our existing infrastructure could be adapted to provide step four, making this proposal fairly easy to implement.

Reuse tracking

2012-08-09T20:18:12Z

Jonathan Palecek: /* Proposal 2: Hosted Refback Tracking */

RDF metadata presents information about a work's ancestry in a machine readable way. The websites of users who properly used our license chooser tool already have this setup. While it is possible to trace backwards to find a derived work's source, it is impossible to trace forwards to find all of a source work's derivatives without the aid of extra infrastructure.

In this page, you will find proposals for several ethical (respects user's privacy, does not involve radio-tagging people with malware or drm) solutions to this problem. These may either be systems that Creative Commons would prototype with the intention of being a reference for other organizations to build their own infrastructure; or systems that we would build an maintain our self, and provide an api to interested parties (either free in the spirit of open, or for a small fee to help offset hosting costs). All of the proposed systems below have their own advantages and disadvantages; none of them the silver bullet.

= Proposal 1: Independent Refback Tracking =

When a user opens a webpage, the browser sends some information to the
server. Of particular interest is the /referrer string/. To put it
simply, the referrer string contains the URL of the webpage that
linked the user to the page they are currently viewing.

The Refback Tracking framework would be hosted by respective content
providers, and served independently from CC. This advantage means
that once a working system is prototyped, it would have no hosting
(potentially none). cost for us, and therefor require the minimal
amount of maintenance.

The disadvantage to this approach is it is only able to trace direct
remixes of a work, but not remixes of remixes.

Here is how it works:

[[File:Proposal_1a.png]]

The above picture describes the sequence of events that triggers the
tracking mechanism, shown from the user's perspective. The steps are
like so:

'''1.''' The user opens Website A. Website A contains a remixed work.
The work provides proper attribution to the work which it is derived
from, both visually for the user and invisibly with metadata.

'''2.''' The curious user clicks on the link to the original work, and
is taken to Website B as expected.

Here is what happens behind the scenes:

[[File:Proposal_1b.png]]

'''1.''' The user opens a website. The user's browser requests a page
from a server. The website has a remixed work on it, and is
attributed with metadata. The server replies to the user's request
with the website.

'''2.''' The curious user clicks on the link to the original work.
The user's browser sends a request to the server hosting the page of
the original work. This request's referrer string contains the url of
the webpage with the remixed work on it. The server replies to the
user's request as expected, and takes note of the url in the referrer
string (this can happen either using javascript embedded in the page,
or with special code running on the webserver itself).

'''3.''' The server hosting the original work downloads the page of
the remixed work (as noted from the referrer string). The server of
the remixed work replies as expected. The server hosting the original
work reads the metadata on the download page to verify that it indeed
contains a remixed of the original work. The server notes the url in
a database, to be used for generating reuse statistics.

= Proposal 2: Hosted Refback Tracking =
Hosted Refback Tracking is a variation of the system described in the
first proposal. In this version, Creative Commons hosts the database
server. The page which contains the work that is the target of re-use
tracking will include a small bit of JavaScript, which CC would
provide. This approach requires no changes to the 3rd party servers.
Our license chooser could include an opt-in option, which would
automatically add the JavaScript to the HTML+rdfa license mark.

This approach requires that CC host a service, thus losing the main
advantage of the first proposal. However, this version is easier for
content creators to opt-in, as it requires no modifications to 3rd
party web servers. If this service sees widespread use, the aggregate
data could potential construct a more robust graph than that described
in the first proposal. However, the opt-in nature of this service
makes this unlikely.

Here is how it works:

[[File:Proposal_2.png]]

'''1.''' The user opens a website. The website contains a remixed
work, which is attributed properly and contains the relevant metadata.

'''2.''' The user clicks on the link to the original work; the
corresponding web page opens in the user's browser.

'''3.''' When the page loads, a script on the page sends the referrer
information to the database server run by CC.

(''4.'') The database server reads the metadata from both websites,
and if one is indeed a remix of the other, then this information about
both sites is recorded in our database.

= Proposal 3: Hosted Scraped Data API =

Creative Commons already has two pieces of infrastructure that could
be adapted to be used for reuse tracking. When a website uses the
HTML provided by our license chooser to mark the page with attribution
information and metadata, the badge icon is hosted by us as well. We
are able to use the download statistics of these images to create an
estimation of license usage in the wild, using the referrer string in
requests for the image. We have a tool called Deedscraper which, when
a deed is opened, javascript on the page sends the referrer string to
the Deedscraper server, which reads the metadata on the referring
page. This is used so that the deed can be safely updated after page
load with information for attributing the linked work.

This version proposes that when we get the referring string from the
download request for a license badge, deedscraper reads the metadata
from that page, and takes note of it in a database. Thus, we can
build a bi-directional graph of remixes. This data could be made
available through a simple API or dashboard.

This service would yield significantly better data than the first two
proposals, would be straight forward to set up, but would require
ongoing maintenance by the tech team, and make Kinkade very grumpy.

Reuse tracking

2012-08-09T20:17:41Z

Jonathan Palecek: /* Proposal 2: Hosted Refback Tracking */

RDF metadata presents information about a work's ancestry in a machine readable way. The websites of users who properly used our license chooser tool already have this setup. While it is possible to trace backwards to find a derived work's source, it is impossible to trace forwards to find all of a source work's derivatives without the aid of extra infrastructure.

In this page, you will find proposals for several ethical (respects user's privacy, does not involve radio-tagging people with malware or drm) solutions to this problem. These may either be systems that Creative Commons would prototype with the intention of being a reference for other organizations to build their own infrastructure; or systems that we would build an maintain our self, and provide an api to interested parties (either free in the spirit of open, or for a small fee to help offset hosting costs). All of the proposed systems below have their own advantages and disadvantages; none of them the silver bullet.

= Proposal 1: Independent Refback Tracking =

When a user opens a webpage, the browser sends some information to the
server. Of particular interest is the /referrer string/. To put it
simply, the referrer string contains the URL of the webpage that
linked the user to the page they are currently viewing.

The Refback Tracking framework would be hosted by respective content
providers, and served independently from CC. This advantage means
that once a working system is prototyped, it would have no hosting
(potentially none). cost for us, and therefor require the minimal
amount of maintenance.

The disadvantage to this approach is it is only able to trace direct
remixes of a work, but not remixes of remixes.

Here is how it works:

[[File:Proposal_1a.png]]

The above picture describes the sequence of events that triggers the
tracking mechanism, shown from the user's perspective. The steps are
like so:

'''1.''' The user opens Website A. Website A contains a remixed work.
The work provides proper attribution to the work which it is derived
from, both visually for the user and invisibly with metadata.

'''2.''' The curious user clicks on the link to the original work, and
is taken to Website B as expected.

Here is what happens behind the scenes:

[[File:Proposal_1b.png]]

'''1.''' The user opens a website. The user's browser requests a page
from a server. The website has a remixed work on it, and is
attributed with metadata. The server replies to the user's request
with the website.

'''2.''' The curious user clicks on the link to the original work.
The user's browser sends a request to the server hosting the page of
the original work. This request's referrer string contains the url of
the webpage with the remixed work on it. The server replies to the
user's request as expected, and takes note of the url in the referrer
string (this can happen either using javascript embedded in the page,
or with special code running on the webserver itself).

'''3.''' The server hosting the original work downloads the page of
the remixed work (as noted from the referrer string). The server of
the remixed work replies as expected. The server hosting the original
work reads the metadata on the download page to verify that it indeed
contains a remixed of the original work. The server notes the url in
a database, to be used for generating reuse statistics.

= Proposal 2: Hosted Refback Tracking =
Hosted Refback Tracking is a variation of the system described in the
first proposal. In this version, Creative Commons hosts the database
server. The page which contains the work that is the target of re-use
tracking will include a small bit of JavaScript, which CC would
provide. This approach requires no changes to the 3rd party servers.
Our license chooser could include an opt-in option, which would
automatically add the JavaScript to the HTML+rdfa license mark.

This approach requires that CC host a service, thus losing the main
advantage of the first proposal. However, this version is easier for
content creators to opt-in, as it requires no modifications to 3rd
party web servers. If this service sees widespread use, the aggregate
data could potential construct a more robust graph than that described
in the first proposal. However, the opt-in nature of this service
makes this unlikely.

Here is how it works:

[[File:Proposal_2.png]]

'''1.''' The user opens a website. The website contains a remixed
work, which is attributed properly and contains the relevant metadata.

'''2.''' The user clicks on the link to the original work; the
corresponding web page opens in the user's browser.

'''3.''' When the page loads, a script on the page sends the referrer
information to the database server run by CC.

'''(4.)''' The database server reads the metadata from both websites,
and if one is indeed a remix of the other, then this information about
both sites is recorded in our database.

= Proposal 3: Hosted Scraped Data API =

Creative Commons already has two pieces of infrastructure that could
be adapted to be used for reuse tracking. When a website uses the
HTML provided by our license chooser to mark the page with attribution
information and metadata, the badge icon is hosted by us as well. We
are able to use the download statistics of these images to create an
estimation of license usage in the wild, using the referrer string in
requests for the image. We have a tool called Deedscraper which, when
a deed is opened, javascript on the page sends the referrer string to
the Deedscraper server, which reads the metadata on the referring
page. This is used so that the deed can be safely updated after page
load with information for attributing the linked work.

This version proposes that when we get the referring string from the
download request for a license badge, deedscraper reads the metadata
from that page, and takes note of it in a database. Thus, we can
build a bi-directional graph of remixes. This data could be made
available through a simple API or dashboard.

This service would yield significantly better data than the first two
proposals, would be straight forward to set up, but would require
ongoing maintenance by the tech team, and make Kinkade very grumpy.

Reuse tracking

2012-08-09T19:57:09Z

Jonathan Palecek: /* Proposal 2: Hosted Refback Tracking */

RDF metadata presents information about a work's ancestry in a machine readable way. The websites of users who properly used our license chooser tool already have this setup. While it is possible to trace backwards to find a derived work's source, it is impossible to trace forwards to find all of a source work's derivatives without the aid of extra infrastructure.

In this page, you will find proposals for several ethical (respects user's privacy, does not involve radio-tagging people with malware or drm) solutions to this problem. These may either be systems that Creative Commons would prototype with the intention of being a reference for other organizations to build their own infrastructure; or systems that we would build an maintain our self, and provide an api to interested parties (either free in the spirit of open, or for a small fee to help offset hosting costs). All of the proposed systems below have their own advantages and disadvantages; none of them the silver bullet.

= Proposal 1: Independent Refback Tracking =

When a user opens a webpage, the browser sends some information to the
server. Of particular interest is the /referrer string/. To put it
simply, the referrer string contains the URL of the webpage that
linked the user to the page they are currently viewing.

The Refback Tracking framework would be hosted by respective content
providers, and served independently from CC. This advantage means
that once a working system is prototyped, it would have no hosting
(potentially none). cost for us, and therefor require the minimal
amount of maintenance.

The disadvantage to this approach is it is only able to trace direct
remixes of a work, but not remixes of remixes.

Here is how it works:

[[File:Proposal_1a.png]]

The above picture describes the sequence of events that triggers the
tracking mechanism, shown from the user's perspective. The steps are
like so:

'''1.''' The user opens Website A. Website A contains a remixed work.
The work provides proper attribution to the work which it is derived
from, both visually for the user and invisibly with metadata.

'''2.''' The curious user clicks on the link to the original work, and
is taken to Website B as expected.

Here is what happens behind the scenes:

[[File:Proposal_1b.png]]

'''1.''' The user opens a website. The user's browser requests a page
from a server. The website has a remixed work on it, and is
attributed with metadata. The server replies to the user's request
with the website.

'''2.''' The curious user clicks on the link to the original work.
The user's browser sends a request to the server hosting the page of
the original work. This request's referrer string contains the url of
the webpage with the remixed work on it. The server replies to the
user's request as expected, and takes note of the url in the referrer
string (this can happen either using javascript embedded in the page,
or with special code running on the webserver itself).

'''3.''' The server hosting the original work downloads the page of
the remixed work (as noted from the referrer string). The server of
the remixed work replies as expected. The server hosting the original
work reads the metadata on the download page to verify that it indeed
contains a remixed of the original work. The server notes the url in
a database, to be used for generating reuse statistics.

= Proposal 2: Hosted Refback Tracking =
This approach is a variation of the first proposal, where CC runs an
instance of the serverside component described in the first proposal.
The advantage, is that if the service sees significant adoption, the
aggregated data could be used to construct a better tree of derivative
work. However, this advantage is '''only''' possible if use of this
service is sufficiently widespread. Otherwise, this proposal has the
same disadvantage as the first version, with the additional cost and
liability to CC as it would lack the advantage to the first version.

Hosted Refback Tracking is a variation of Independent Refback
Tracking, in which CC runs the server-side database component
described in the first proposal, and the refback is sent to us via
javascript embedded on the website hosting the original work.

[[File:Proposal_2.png]]

This version requires that we host an maintain a special service, thus
adding the disadvantages of both cost and liability. There are two
advantages this version has over the first proposal. The fist
advantage is that all that needs to be done to the website hosting the
original content is to include a bit of javascript that we would
provide (which is far easier than requiring the 3rd part to setup a
nginx module, apache module, wsgi middleware, or roll their own
backend). The other advantage is that '''if''' there is significant
adoption, it might be possible to construct a better graph, as the
data would be aggregated in one place.

= Proposal 3: Hosted Scraped Data API =

Creative Commons already has two pieces of infrastructure that could
be adapted to be used for reuse tracking. When a website uses the
HTML provided by our license chooser to mark the page with attribution
information and metadata, the badge icon is hosted by us as well. We
are able to use the download statistics of these images to create an
estimation of license usage in the wild, using the referrer string in
requests for the image. We have a tool called Deedscraper which, when
a deed is opened, javascript on the page sends the referrer string to
the Deedscraper server, which reads the metadata on the referring
page. This is used so that the deed can be safely updated after page
load with information for attributing the linked work.

This version proposes that when we get the referring string from the
download request for a license badge, deedscraper reads the metadata
from that page, and takes note of it in a database. Thus, we can
build a bi-directional graph of remixes. This data could be made
available through a simple API or dashboard.

This service would yield significantly better data than the first two
proposals, would be straight forward to set up, but would require
ongoing maintenance by the tech team, and make Kinkade very grumpy.

File:Proposal 2.png

2012-08-09T19:56:44Z

Jonathan Palecek: 1. User requests a website containing a remixed work. The website uses proper attribution & metadata. 2. The curious user clicks on a link to the website featuring the original work. 3. The page with the original work on it has a bit of CC-provided ja...

1. User requests a website containing a remixed work. The website uses proper attribution & metadata.
2. The curious user clicks on a link to the website featuring the original work.
3. The page with the original work on it has a bit of CC-provided javascript that recognizes that there is a referrer string, and sends that to a CC-run server via XHR.
(4.) The CC-run database server notes the urls for both the page of the original work and the page of the remixed work; downloads both to read the respective metadata. If everything checks out, the server stores the information in a database that can be used to generate reuse tracking information.

Reuse tracking

2012-08-09T19:42:50Z

Jonathan Palecek: /* Proposal 3: Hosted Scraped Data Api */

RDF metadata presents information about a work's ancestry in a machine readable way. The websites of users who properly used our license chooser tool already have this setup. While it is possible to trace backwards to find a derived work's source, it is impossible to trace forwards to find all of a source work's derivatives without the aid of extra infrastructure.

In this page, you will find proposals for several ethical (respects user's privacy, does not involve radio-tagging people with malware or drm) solutions to this problem. These may either be systems that Creative Commons would prototype with the intention of being a reference for other organizations to build their own infrastructure; or systems that we would build an maintain our self, and provide an api to interested parties (either free in the spirit of open, or for a small fee to help offset hosting costs). All of the proposed systems below have their own advantages and disadvantages; none of them the silver bullet.

= Proposal 1: Independent Refback Tracking =

When a user opens a webpage, the browser sends some information to the
server. Of particular interest is the /referrer string/. To put it
simply, the referrer string contains the URL of the webpage that
linked the user to the page they are currently viewing.

The Refback Tracking framework would be hosted by respective content
providers, and served independently from CC. This advantage means
that once a working system is prototyped, it would have no hosting
(potentially none). cost for us, and therefor require the minimal
amount of maintenance.

The disadvantage to this approach is it is only able to trace direct
remixes of a work, but not remixes of remixes.

Here is how it works:

[[File:Proposal_1a.png]]

The above picture describes the sequence of events that triggers the
tracking mechanism, shown from the user's perspective. The steps are
like so:

'''1.''' The user opens Website A. Website A contains a remixed work.
The work provides proper attribution to the work which it is derived
from, both visually for the user and invisibly with metadata.

'''2.''' The curious user clicks on the link to the original work, and
is taken to Website B as expected.

Here is what happens behind the scenes:

[[File:Proposal_1b.png]]

'''1.''' The user opens a website. The user's browser requests a page
from a server. The website has a remixed work on it, and is
attributed with metadata. The server replies to the user's request
with the website.

'''2.''' The curious user clicks on the link to the original work.
The user's browser sends a request to the server hosting the page of
the original work. This request's referrer string contains the url of
the webpage with the remixed work on it. The server replies to the
user's request as expected, and takes note of the url in the referrer
string (this can happen either using javascript embedded in the page,
or with special code running on the webserver itself).

'''3.''' The server hosting the original work downloads the page of
the remixed work (as noted from the referrer string). The server of
the remixed work replies as expected. The server hosting the original
work reads the metadata on the download page to verify that it indeed
contains a remixed of the original work. The server notes the url in
a database, to be used for generating reuse statistics.

= Proposal 2: Hosted Refback Tracking =
This approach is a variation of the first proposal, where CC runs an
instance of the serverside component described in the first proposal.
The advantage, is that if the service sees significant adoption, the
aggregated data could be used to construct a better tree of derivative
work. However, this advantage is '''only''' possible if use of this
service is sufficiently widespread. Otherwise, this proposal has the
same disadvantage as the first version, with the additional cost and
liability to CC as it would lack the advantage to the first version.

Hosted Refback Tracking is a variation of Independent Refback
Tracking, in which CC runs the server-side database component
described in the first proposal, and the refback is sent to us via
javascript embedded on the website hosting the original work.

This version requires that we host an maintain a special service, thus
adding the disadvantages of both cost and liability. There are two
advantages this version has over the first proposal. The fist
advantage is that all that needs to be done to the website hosting the
original content is to include a bit of javascript that we would
provide (which is far easier than requiring the 3rd part to setup a
nginx module, apache module, wsgi middleware, or roll their own
backend). The other advantage is that '''if''' there is significant
adoption, it might be possible to construct a better graph, as the
data would be aggregated in one place.

= Proposal 3: Hosted Scraped Data API =

Creative Commons already has two pieces of infrastructure that could
be adapted to be used for reuse tracking. When a website uses the
HTML provided by our license chooser to mark the page with attribution
information and metadata, the badge icon is hosted by us as well. We
are able to use the download statistics of these images to create an
estimation of license usage in the wild, using the referrer string in
requests for the image. We have a tool called Deedscraper which, when
a deed is opened, javascript on the page sends the referrer string to
the Deedscraper server, which reads the metadata on the referring
page. This is used so that the deed can be safely updated after page
load with information for attributing the linked work.

This version proposes that when we get the referring string from the
download request for a license badge, deedscraper reads the metadata
from that page, and takes note of it in a database. Thus, we can
build a bi-directional graph of remixes. This data could be made
available through a simple API or dashboard.

This service would yield significantly better data than the first two
proposals, would be straight forward to set up, but would require
ongoing maintenance by the tech team, and make Kinkade very grumpy.

Reuse tracking

2012-08-09T19:40:47Z

Jonathan Palecek: /* Proposal 3: Hosted Scraped Data Api */

RDF metadata presents information about a work's ancestry in a machine readable way. The websites of users who properly used our license chooser tool already have this setup. While it is possible to trace backwards to find a derived work's source, it is impossible to trace forwards to find all of a source work's derivatives without the aid of extra infrastructure.

In this page, you will find proposals for several ethical (respects user's privacy, does not involve radio-tagging people with malware or drm) solutions to this problem. These may either be systems that Creative Commons would prototype with the intention of being a reference for other organizations to build their own infrastructure; or systems that we would build an maintain our self, and provide an api to interested parties (either free in the spirit of open, or for a small fee to help offset hosting costs). All of the proposed systems below have their own advantages and disadvantages; none of them the silver bullet.

= Proposal 1: Independent Refback Tracking =

When a user opens a webpage, the browser sends some information to the
server. Of particular interest is the /referrer string/. To put it
simply, the referrer string contains the URL of the webpage that
linked the user to the page they are currently viewing.

The Refback Tracking framework would be hosted by respective content
providers, and served independently from CC. This advantage means
that once a working system is prototyped, it would have no hosting
(potentially none). cost for us, and therefor require the minimal
amount of maintenance.

The disadvantage to this approach is it is only able to trace direct
remixes of a work, but not remixes of remixes.

Here is how it works:

[[File:Proposal_1a.png]]

The above picture describes the sequence of events that triggers the
tracking mechanism, shown from the user's perspective. The steps are
like so:

'''1.''' The user opens Website A. Website A contains a remixed work.
The work provides proper attribution to the work which it is derived
from, both visually for the user and invisibly with metadata.

'''2.''' The curious user clicks on the link to the original work, and
is taken to Website B as expected.

Here is what happens behind the scenes:

[[File:Proposal_1b.png]]

'''1.''' The user opens a website. The user's browser requests a page
from a server. The website has a remixed work on it, and is
attributed with metadata. The server replies to the user's request
with the website.

'''2.''' The curious user clicks on the link to the original work.
The user's browser sends a request to the server hosting the page of
the original work. This request's referrer string contains the url of
the webpage with the remixed work on it. The server replies to the
user's request as expected, and takes note of the url in the referrer
string (this can happen either using javascript embedded in the page,
or with special code running on the webserver itself).

'''3.''' The server hosting the original work downloads the page of
the remixed work (as noted from the referrer string). The server of
the remixed work replies as expected. The server hosting the original
work reads the metadata on the download page to verify that it indeed
contains a remixed of the original work. The server notes the url in
a database, to be used for generating reuse statistics.

= Proposal 2: Hosted Refback Tracking =
This approach is a variation of the first proposal, where CC runs an
instance of the serverside component described in the first proposal.
The advantage, is that if the service sees significant adoption, the
aggregated data could be used to construct a better tree of derivative
work. However, this advantage is '''only''' possible if use of this
service is sufficiently widespread. Otherwise, this proposal has the
same disadvantage as the first version, with the additional cost and
liability to CC as it would lack the advantage to the first version.

Hosted Refback Tracking is a variation of Independent Refback
Tracking, in which CC runs the server-side database component
described in the first proposal, and the refback is sent to us via
javascript embedded on the website hosting the original work.

This version requires that we host an maintain a special service, thus
adding the disadvantages of both cost and liability. There are two
advantages this version has over the first proposal. The fist
advantage is that all that needs to be done to the website hosting the
original content is to include a bit of javascript that we would
provide (which is far easier than requiring the 3rd part to setup a
nginx module, apache module, wsgi middleware, or roll their own
backend). The other advantage is that '''if''' there is significant
adoption, it might be possible to construct a better graph, as the
data would be aggregated in one place.

= Proposal 3: Hosted Scraped Data Api =

Creative Commons already has two pieces of infrastructure that could
be adapted to be used for reuse tracking. When a website uses the
HTML provided by our license chooser to mark the page with attribution
information and metadata, the badge icon is hosted by us as well. We
are able to use the download statistics of these images to create an
estimation of license usage in the wild, using the referrer string in
requests for the image. We have a tool called Deedscraper which, when
a deed is opened, javascript on the page sends the referrer string to
the Deedscraper server, which reads the metadata on the referring
page. This is used so that the deed can be safely updated after page
load with information for attributing the linked work.

This version proposes that when we get the referring string from the
download request for a license badge, deedscraper reads the metadata
from that page, and takes note of it in a database. Thus, we can
build a bi-directional graph of remixes. This data could be made
available through a simple API or dashboard.

This service would yield significantly better data than the first two
proposals, would be straight forward to set up, but would require
ongoing maintenance by the tech team, and make Kinkade very grumpy.

Reuse tracking

2012-08-09T19:40:16Z

Jonathan Palecek:

RDF metadata presents information about a work's ancestry in a machine readable way. The websites of users who properly used our license chooser tool already have this setup. While it is possible to trace backwards to find a derived work's source, it is impossible to trace forwards to find all of a source work's derivatives without the aid of extra infrastructure.

In this page, you will find proposals for several ethical (respects user's privacy, does not involve radio-tagging people with malware or drm) solutions to this problem. These may either be systems that Creative Commons would prototype with the intention of being a reference for other organizations to build their own infrastructure; or systems that we would build an maintain our self, and provide an api to interested parties (either free in the spirit of open, or for a small fee to help offset hosting costs). All of the proposed systems below have their own advantages and disadvantages; none of them the silver bullet.

= Proposal 1: Independent Refback Tracking =

When a user opens a webpage, the browser sends some information to the
server. Of particular interest is the /referrer string/. To put it
simply, the referrer string contains the URL of the webpage that
linked the user to the page they are currently viewing.

The Refback Tracking framework would be hosted by respective content
providers, and served independently from CC. This advantage means
that once a working system is prototyped, it would have no hosting
(potentially none). cost for us, and therefor require the minimal
amount of maintenance.

The disadvantage to this approach is it is only able to trace direct
remixes of a work, but not remixes of remixes.

Here is how it works:

[[File:Proposal_1a.png]]

The above picture describes the sequence of events that triggers the
tracking mechanism, shown from the user's perspective. The steps are
like so:

'''1.''' The user opens Website A. Website A contains a remixed work.
The work provides proper attribution to the work which it is derived
from, both visually for the user and invisibly with metadata.

'''2.''' The curious user clicks on the link to the original work, and
is taken to Website B as expected.

Here is what happens behind the scenes:

[[File:Proposal_1b.png]]

'''1.''' The user opens a website. The user's browser requests a page
from a server. The website has a remixed work on it, and is
attributed with metadata. The server replies to the user's request
with the website.

'''2.''' The curious user clicks on the link to the original work.
The user's browser sends a request to the server hosting the page of
the original work. This request's referrer string contains the url of
the webpage with the remixed work on it. The server replies to the
user's request as expected, and takes note of the url in the referrer
string (this can happen either using javascript embedded in the page,
or with special code running on the webserver itself).

'''3.''' The server hosting the original work downloads the page of
the remixed work (as noted from the referrer string). The server of
the remixed work replies as expected. The server hosting the original
work reads the metadata on the download page to verify that it indeed
contains a remixed of the original work. The server notes the url in
a database, to be used for generating reuse statistics.

= Proposal 2: Hosted Refback Tracking =
This approach is a variation of the first proposal, where CC runs an
instance of the serverside component described in the first proposal.
The advantage, is that if the service sees significant adoption, the
aggregated data could be used to construct a better tree of derivative
work. However, this advantage is '''only''' possible if use of this
service is sufficiently widespread. Otherwise, this proposal has the
same disadvantage as the first version, with the additional cost and
liability to CC as it would lack the advantage to the first version.

Hosted Refback Tracking is a variation of Independent Refback
Tracking, in which CC runs the server-side database component
described in the first proposal, and the refback is sent to us via
javascript embedded on the website hosting the original work.

This version requires that we host an maintain a special service, thus
adding the disadvantages of both cost and liability. There are two
advantages this version has over the first proposal. The fist
advantage is that all that needs to be done to the website hosting the
original content is to include a bit of javascript that we would
provide (which is far easier than requiring the 3rd part to setup a
nginx module, apache module, wsgi middleware, or roll their own
backend). The other advantage is that '''if''' there is significant
adoption, it might be possible to construct a better graph, as the
data would be aggregated in one place.

= Proposal 3: Hosted Scraped Data Api =

Creative Commons already has two pieces of infrastructure that could
be adapted to be used for reuse tracking. When a website uses the
HTML provided by our license chooser to mark the page with attribution
information and metadata, the badge icon is hosted by us as well. We
are able to use the download statistics of these images to create an
estimation of license usage in the wild, using the referrer string in
requests for the image. We have a tool called Deedscraper which, when
a deed is opened, javascript on the page sends the referrer string to
the Deedscraper server, which reads the metadata on the referring
page. This is used so that the deed can be safely updated after page
load with information for attributing the linked work.

This version proposes that when we get the referring string from the
download request for a license badge, deedscraper reads the metadata
from that page, and takes note of it in a database. Thus, we can
build a bi-directional graph of remixes. This data could be made
available through a simple API or dashboard.

This service would yield significantly better data than the first two
proposals, would be straight forward to set up, but would require
ongoing maintenance by the tech team.

Reuse tracking

2012-08-09T18:54:47Z

Jonathan Palecek:

Reuse tracking

2012-08-09T18:53:59Z

Jonathan Palecek: /* Proposal 1: Independent Refback Tracking */

Reuse tracking

2012-08-09T18:38:32Z

Jonathan Palecek: /* Proposal 1: Independent Refback Tracking */

Reuse tracking

2012-08-09T18:37:24Z

Jonathan Palecek:

File:Proposal 1b.png

2012-08-09T18:35:00Z

Jonathan Palecek: 1. The user's browser requests a website. This website has a remixed work on it, and has proper metadata and attribution. The server replies to the user's request with the website. 2. The user's clicks on the link to the original work. The user's b...

1. The user's browser requests a website. This website has a remixed work on it, and has proper metadata and attribution. The server replies to the user's request with the website.

2. The user's clicks on the link to the original work. The user's browser sends a request to the server that hosts it. This request's referrer string contains the url of the first website. The server replies to the user's request as expected, and takes note of the url in the referrer string.

3. The server of the original work downloads the page of the remixed work. The server of the remixed work replies as expected. The server of the original work reads the metadata on the page, and verifies that it indeed contains a remix. The server notes the url in a database, to be used for generating reuse statistics.

File:Proposal 1a.png

2012-08-09T18:30:46Z

Jonathan Palecek: 1. The user opens a webpage which has a remix on it, has proper attribution, and contains metadata. 2. The user sees a link to the original work, clicks on it, and is taken to the page of the original work.

1. The user opens a webpage which has a remix on it, has proper attribution, and contains metadata.
2. The user sees a link to the original work, clicks on it, and is taken to the page of the original work.

Reuse tracking

2012-08-08T21:40:39Z

Jonathan Palecek: /* Reuse Tracking */

Reuse tracking

2012-08-08T21:39:59Z

Jonathan Palecek:

= Reuse Tracking =

RDF metadata presents information about a work's ancestry in a machine readable way. The websites of users who properly used our license chooser tool already have this setup. While it is possible to trace backwards to find a derived work's source, it is impossible to trace forwards to find all of a source work's derivatives without the aid of extra infrastructure.

In this page, you will find proposals for several ethical (respects user's privacy, does not involve radio-tagging people with malware or drm) solutions to this problem. These may either be systems that Creative Commons would prototype with the intention of being a reference for other organizations to build their own infrastructure; or systems that we would build an maintain our self, and provide an api to interested parties (either free in the spirit of open, or for a small fee to help offset hosting costs). All of the proposed systems below have their own advantages and disadvantages; none of them the silver bullet.

== Proposal 1: Independent Refback Tracking ==

The Refback Tracking framework could be served independently from CC, having the chief advantage of having no hosting or maintenance cost to CC. The chief disadvantage of this approach, is that it can only capture immediate derivatives. For larger organizations, this will still yield useful data; but would this not be terribly useful for smaller organizations and individuals.

== Proposal 2: Hosted Refback Tracking ==

This approach is a variation of the first proposal, where CC runs an instance of the serverside component described in the first proposal. The advantage, is that if the service sees significant adoption, the aggregated data could be used to construct a better tree of derivative work. However, this advantage is '''only''' possible if use of this service is sufficiently widespread. Otherwise, this proposal has the same disadvantage as the first version, with the additional cost and liability to CC as it would lack the advantage to the first version.

== Proposal 3: Hosted Scraped Data Api ==

Reuse tracking

2012-08-08T21:39:19Z

Jonathan Palecek:

= Reuse Tracking =

RDF metadata presents information about a work's ancestry in a machine readable way. The websites of users who properly used our license chooser tool already have this setup. While it is possible to trace backwards to find a derived work's source, it is impossible to trace forwards to find all of a source work's derivatives without the aid of extra infrastructure.

In this page, you will find proposals for several ethical (respects user's privacy, does not involve radio-tagging people with malware or drm) solutions to this problem. These may either be systems that Creative Commons would prototype with the intention of being a reference for other organizations to build their own infrastructure; or systems that we would build an maintain our self, and provide an api to interested parties (either free in the spirit of open, or for a small fee to help offset hosting costs). All of the proposed systems below have their own advantages and disadvantages; none of them the silver bullet.

== Proposal 1: Independent Refback Tracking ==

The Refback Tracking framework could be served independently from CC, having the chief advantage of having no hosting or maintenance cost to CC. The chief disadvantage of this approach, is that it can only capture immediate derivatives. For larger organizations, this will still yield useful data; but would this not be terribly useful for smaller organizations and individuals.

== Proposal 2: Hosted Refback Tracking ==

This approach is a variation of the first proposal, where CC runs an instance of the serverside component described in the first proposal. The advantage, is that if the service sees significant adoption, the aggregated data could be used to construct a better tree of derivative work. However, this advantage is '''only''' possible if use of this service is sufficiently widespread. Otherwise, this proposal has the same disadvantage as the first version, with the additional cost and liability to CC, as it would lack the advantage to the first version.

== Proposal 3: Hosted Scraped Data Api ==

Reuse tracking

2012-08-08T21:24:58Z

Jonathan Palecek: Created page with "= Reuse Tracking = RDF metadata presents information about a work's ancestry in a machine readable way. The websites of users who properly used our license chooser tool alre..."

Translation tooling

2012-07-13T19:21:52Z

Jonathan Palecek: /* Extracting translations */

= Adding or changing strings =

For details on this, read the "structure of our translation toolchain"

== Extracting translations ==

Instead of providing a master.po file, the same information is pulled automagically from cc.engine's templates, in the content of the trans tags.

# Make modifications to cc.engine templates, commit, push, etc.
# In cc.i18n (using either buildout or virtualenv):
# git pull origin master
# run ./runcheckout.sh && ./extract.sh
# git add cc/i18n/po/en/cc_org.po
# git commit -m "Extracting new strings for translation"
# git push origin master

...done!

== Push source file up to transifex ==

# ssh a7.creativecommons.org
# sudo su cronuser
# cd /home/cronuser/transifex.net_i18n_checkout/
# git pull
# tx push -s

That last command will push the source file (english .po file you committed) up to transifex.

= Structure of our translation toolchain =

== Where are our translations? ==

First of all, we maintain our translations on Transifex. Our
affiliates mostly handle our translations.

https://www.transifex.net/projects/p/CC/resource/deeds-choosers/

== What tools do we use? ==

Translations are in gettext format.

We used to use zope's i18n toolchain for translations. Things used to
be in "logical key" format, where there was a symbolic representation
of each translation (almost like a variable that mapped to the
string). We switched to english keys because that's what most of the
world does, and doing otherwise required an insanely complex and
fragile system that we spent a ton of time maintaining.

These days it's pretty simple... just mark a string for translation by
wrapping it in gettext() or _() or whatever. Then we can auto-extract
things.

If you read the "extracting translations" section above, or even ran
the commands, you may have wondered, "Whoa, that ran like magic! All
of these translations just got pulled out! How the hell did that
work?"

The answer is pretty simple! We use [http://babel.edgewall.org Babel]
to extract strings.

When you run ./runcheckouts.sh, it checks out all the packages we
extract translations from. And ./extract.sh extracts all the
translations from them by reading babel.ini to find out all the stuff
it should extract.

Most of the extractors are pretty standard (jinja2 and python are
bundled by jinja2 and babel respectively), but we've defined our own
for extracting from RDF in cc/i18n/tools/extractors.py (defined as an
entry point in setup.py)

So anyway, transifex has a client that we use to push up the new
translations with. Anyway, just see above for that.

There are actually two cronjobs that run, translations related. A few
times an hour new translations are pulled down, and a new translation
tarball is built. (They're currently separate scripts but maybe they
could be merged?

These commands can be found in the cronuser crontab.

# Pull changes from Tx.net and push them to our repos
5 * * * * ~/bin/sync_i18n_with_transifex.sh > /dev/null
10 * * * * ~/bin/sync_i18n-ccsearch_with_transifex.sh > /dev/null

# Update cc.i18n tarball
*/15 * * * * /usr/bin/ionicer && nice -n 19 bash /var/www/staging.creativecommons.org/make_i18n_sdist.sh > /dev/null

One more thing to note: we have a translations statistics tool that's
run every time the sdist is built. It writes out a csv file that
keeps several bits of information, including percentages. We have a
translation threshold at the top of cc/i18n/util.py ... translations
have to be above this level to show up in the "available languages"
box on various pages of cc.engine!

Interactive license chooser

2012-02-23T03:44:56Z

Jonathan Palecek: /* UI Draft Images */

= Proposed Interactive License Chooser =
== Proposal ==

The chooser right now is functional as a tool for the selection of licenses
and generating the appropriate metadata, but does so with ui conventions that
contradict its actual purpose. The first problem is that the user fills out a
form, presses a button, and receives a license and metadata; this suggests that
it is a registry or license generator of some kind - of which it is neither.
The second problem is that while the deeds convey information about if a license
is free culture approved or not; the user does not know to look for this
information. The chooser can easily unintrusively provide this same
information, enabling the user to make a more informed decision about their
license choice. In the interest of objectivity, the UI changes should be
informative and not "make NC scary".

It also may be useful to include some means of making CC0 accessible to
individuals who would prefer that sort of thing. (I personally like a
"don't care" option that ends up with CC0 instead of a license, but that would
be the wrong way to go about it).

== Visual Implementation ==

The "registry / generator" problem can be solved by having the chooser page
also be the results page. If javascript is enabled, when the user makes a
selection of some kind or changes something in a field, the chooser updates the
metadata on the page as well as something like "based on the current selection,
you get the CC-BY-SA, here is the metadata & badge to copy into your page" or
something to that effect. Depending on the license, the "free culture
approved" logo should appear or fade into a dotted outline. Accompanying text
will say something like "CC-BY is a free culture approved license. Click here
to find out why." Or "CC-BY-NC-ND" is not a free culture approved license.
Click here to find out why."

If javascript is enabled, there is no need for some kind of form submit button,
since the effect is accomplished transparently by javascript. If javascript is
not enabled, then a button labeled something to the effect of "update page"
will be visible; pushing the button will be similar to how the chooser
currently works, except that the page the user is directed to next is the same
url + cgi inputs.

In execution, this should be a process that should allow the user to refine
their input easily without backtracking. The current manifestation of the
chooser uses a design that suggests that the user has to get it right on the
first try.

The current results page isn't well organized. There is a lot of information
that most users will ignore, such as the entire contents of the sidebar on the
right. Everything does not need to be presented at once; the box containing
the html fragment could also have tabs above it so the user may select which
format they want (such as XMP). Visual elements on the current page could be
easily consolidated without making the tool seem cluttered.

== Technical Implementation ==

Currently, one goes to http://creativecommons.org/choose/ to open the chooser,
and then hits "select a license" to be directed to
http://creativecommons.org/choose/results-one to view the result. This second
url will be kept as it is now, as people will some times link to that instead
of the deed. The "select a license" equivalent in the new version will direct
back to http://creativecommons.org/choose/ + the cgi string to produce the new
results.

When javascript is available; when the user changes a radio button or when a
text field has been sufficiently altered; the chooser will use XHR to poll the
server for page updates. As to not make overly redundant requests,
"sufficiently altered" means either when the field no longer has input focus
(and contains a new value than before), or a small delay after a key press. The
keyup event will start a timeout, the keydown event will clear that timeout; so
if the timeout is uninterrupted, then the request will be sent out. It could
also be that we implement this so that the client receives a metadata template
based on the fields that actually have content, and that the page script itself
fills in the blanks. This would greatly reduce the possible server responses,
and therefor let them all be cached.

In both cases, CSS transitions may be used to fluidly change elements on the
page and to make the new workflow very intuitive.

== UI Draft Images ==

The above describes a different design philosophy, in which the chooser behaves
more like an application which the user uses to explore the license options,
than something bearing a confusing resemblance to a registration tool.

As with the "4.0" errata tool, fancy diagrams will appear below soon to give you
a better idea of what we're after with this. Note, I forgot a few things in the pictures below, namely incorporating "the color of freedom" thing into the chooser (green / yellow depending on license). I also forgot to add a radio button for offline works, which changes the content of the bottom right quadrant of the ui, and what it would look like with javascript disabled. I make another draft that addresses these scenarios tomorrow.

== [[File:New_chooser_cc-by.jpg]] ==

== [[File:New_chooser_cc-by-nc-nd.jpg]] ==

File:New chooser cc-by-nc-nd.jpg

2012-02-23T03:41:16Z

Jonathan Palecek: UI draft for proposed changes to the license chooser

UI draft for proposed changes to the license chooser

File:New chooser cc-by.jpg

2012-02-23T03:40:48Z

Jonathan Palecek: UI draft for proposed changes to the license chooser

UI draft for proposed changes to the license chooser

Interactive license chooser

2012-02-23T00:01:46Z

Jonathan Palecek: /* Proposal */

Interactive license chooser

2012-02-23T00:01:07Z

Jonathan Palecek:

= Proposed Interactive License Chooser =
== Proposal ==

The chooser right now is functional as a tool for the selection of licenses
and generating the appropriate metadata, but does so with ui conventions that
contradict its actual purpose. The first problem is that the user fills out a
form, presses a button, and receives a license and metadata; this suggests that
it is a registry or license generator of some kind - of which it is neither.
The second problem is that while the deeds convey information about if a license
is free culture approved or not; the user does not know to look for this
information. The chooser can easily unintrusively provide this same
information, enabling the user to make a more informed decision about their
license choice. In the interest of objectivity, the UI changes should be
informative and not just "make NC scary".

It also may be useful to include some means of making CC0 accessible to
individuals who would prefer that sort of thing. (I personally like a
"don't care" option that ends up with CC0 instead of a license, but that would
be the wrong way to go about it).

== Visual Implementation ==

The "registry / generator" problem can be solved by having the chooser page
also be the results page. If javascript is enabled, when the user makes a
selection of some kind or changes something in a field, the chooser updates the
metadata on the page as well as something like "based on the current selection,
you get the CC-BY-SA, here is the metadata & badge to copy into your page" or
something to that effect. Depending on the license, the "free culture
approved" logo should appear or fade into a dotted outline. Accompanying text
will say something like "CC-BY is a free culture approved license. Click here
to find out why." Or "CC-BY-NC-ND" is not a free culture approved license.
Click here to find out why."

If javascript is enabled, there is no need for some kind of form submit button,
since the effect is accomplished transparently by javascript. If javascript is
not enabled, then a button labeled something to the effect of "update page"
will be visible; pushing the button will be similar to how the chooser
currently works, except that the page the user is directed to next is the same
url + cgi inputs.

In execution, this should be a process that should allow the user to refine
their input easily without backtracking. The current manifestation of the
chooser uses a design that suggests that the user has to get it right on the
first try.

The current results page isn't well organized. There is a lot of information
that most users will ignore, such as the entire contents of the sidebar on the
right. Everything does not need to be presented at once; the box containing
the html fragment could also have tabs above it so the user may select which
format they want (such as XMP). Visual elements on the current page could be
easily consolidated without making the tool seem cluttered.

== Technical Implementation ==

Currently, one goes to http://creativecommons.org/choose/ to open the chooser,
and then hits "select a license" to be directed to
http://creativecommons.org/choose/results-one to view the result. This second
url will be kept as it is now, as people will some times link to that instead
of the deed. The "select a license" equivalent in the new version will direct
back to http://creativecommons.org/choose/ + the cgi string to produce the new
results.

When javascript is available; when the user changes a radio button or when a
text field has been sufficiently altered; the chooser will use XHR to poll the
server for page updates. As to not make overly redundant requests,
"sufficiently altered" means either when the field no longer has input focus
(and contains a new value than before), or a small delay after a key press. The
keyup event will start a timeout, the keydown event will clear that timeout; so
if the timeout is uninterrupted, then the request will be sent out. It could
also be that we implement this so that the client receives a metadata template
based on the fields that actually have content, and that the page script itself
fills in the blanks. This would greatly reduce the possible server responses,
and therefor let them all be cached.

In both cases, CSS transitions may be used to fluidly change elements on the
page and to make the new workflow very intuitive.

== UI Draft Images ==

The above describes a different design philosophy, in which the chooser behaves
more like an application which the user uses to explore the license options,
than something bearing a confusing resemblance to a registration tool.

As with the "4.0" errata tool, fancy diagrams will appear below soon to give you
a better idea of what we're after with this.

Interactive license chooser

2012-02-23T00:00:04Z

Jonathan Palecek: Created page with "* Proposed Interactive License Chooser ** Proposal The chooser right now is functional as a tool for the selection of licenses and generating the appropriate metadata, but..."

* Proposed Interactive License Chooser

** Proposal

The chooser right now is functional as a tool for the selection of licenses
and generating the appropriate metadata, but does so with ui conventions that
contradict its actual purpose. The first problem is that the user fills out a
form, presses a button, and receives a license and metadata; this suggests that
it is a registry or license generator of some kind - of which it is neither.
The second problem is that while the deeds convey information about if a license
is free culture approved or not; the user does not know to look for this
information. The chooser can easily unintrusively provide this same
information, enabling the user to make a more informed decision about their
license choice. In the interest of objectivity, the UI changes should be
informative and not just "make NC scary".

It also may be useful to include some means of making CC0 accessible to
individuals who would prefer that sort of thing. (I personally like a
"don't care" option that ends up with CC0 instead of a license, but that would
be the wrong way to go about it).

** Visual Implementation

The "registry / generator" problem can be solved by having the chooser page
also be the results page. If javascript is enabled, when the user makes a
selection of some kind or changes something in a field, the chooser updates the
metadata on the page as well as something like "based on the current selection,
you get the CC-BY-SA, here is the metadata & badge to copy into your page" or
something to that effect. Depending on the license, the "free culture
approved" logo should appear or fade into a dotted outline. Accompanying text
will say something like "CC-BY is a free culture approved license. Click here
to find out why." Or "CC-BY-NC-ND" is not a free culture approved license.
Click here to find out why."

If javascript is enabled, there is no need for some kind of form submit button,
since the effect is accomplished transparently by javascript. If javascript is
not enabled, then a button labeled something to the effect of "update page"
will be visible; pushing the button will be similar to how the chooser
currently works, except that the page the user is directed to next is the same
url + cgi inputs.

In execution, this should be a process that should allow the user to refine
their input easily without backtracking. The current manifestation of the
chooser uses a design that suggests that the user has to get it right on the
first try.

The current results page isn't well organized. There is a lot of information
that most users will ignore, such as the entire contents of the sidebar on the
right. Everything does not need to be presented at once; the box containing
the html fragment could also have tabs above it so the user may select which
format they want (such as XMP). Visual elements on the current page could be
easily consolidated without making the tool seem cluttered.

** Technical Implementation

Currently, one goes to http://creativecommons.org/choose/ to open the chooser,
and then hits "select a license" to be directed to
http://creativecommons.org/choose/results-one to view the result. This second
url will be kept as it is now, as people will some times link to that instead
of the deed. The "select a license" equivalent in the new version will direct
back to http://creativecommons.org/choose/ + the cgi string to produce the new
results.

When javascript is available; when the user changes a radio button or when a
text field has been sufficiently altered; the chooser will use XHR to poll the
server for page updates. As to not make overly redundant requests,
"sufficiently altered" means either when the field no longer has input focus
(and contains a new value than before), or a small delay after a key press. The
keyup event will start a timeout, the keydown event will clear that timeout; so
if the timeout is uninterrupted, then the request will be sent out. It could
also be that we implement this so that the client receives a metadata template
based on the fields that actually have content, and that the page script itself
fills in the blanks. This would greatly reduce the possible server responses,
and therefor let them all be cached.

In both cases, CSS transitions may be used to fluidly change elements on the
page and to make the new workflow very intuitive.

** UI Draft Images

The above describes a different design philosophy, in which the chooser behaves
more like an application which the user uses to explore the license options,
than something bearing a confusing resemblance to a registration tool.

As with the "4.0" errata tool, fancy diagrams will appear below soon to give you
a better idea of what we're after with this.

4.0 License Errata Annotation Tool

2012-02-10T22:09:14Z

Jonathan Palecek:

= Proposed Legalcode Errata Tool =
== Proposal ==
Despite our best efforts, spelling errors and other errata are sometimes included in the published legal code for
licenses. Creative Commons publishes SHA1 checksums for legal code, which allows people who receive a copy of the
license to easily verify this it has not been tampered with. Therefore Creative Commons does not amend legal code
once published.

With the upcoming 4.0 licenses brings the opportunity to include an annotation tool in the published legal code.
This would still allow for SHA1 checksums for verifying authenticity, but would allow for non-intrusive annotations
to be added after the page has loaded (assuming javascript is available).

== Visual Implementation ==
The errata tool would appear as a small margin on the left hand side of the page. When the page is
loaded, a script in the legal code page would then fetch the errata data for the license. The script would then
add small speech bubble icons into the margin. For every section with errata info, there is a corresponding speech
bubble. When a speech bubble has been clicked on or perhaps on mouseover; a bulleted list of errata appears, and
the corresponding parts of the legal code page are highlighted.

== Technical Implementation ==
When the deed is loaded, a script is executed. An XHR is used to fetch the errata data from one of our servers.
The return value will probably be a json structure which is a list of errata objects. Errata objects would appear
like so:

{id : "corresponding html_id", ch : "character offset", length : "erratum length", text : "errata text"}

The callback function for the errata XHR sorts the list by id, and then populates the page with the needed UI
elements. Text could easily be modified using character offsets irrespective of child html elements by way of
DOM transversal.

== UI Draft Images ==

===[[File:Errata_tool_a.jpg]]===
The above image demonstrates how the bubbles might appear in the margine, and how they line up with the text block for which they correspond.

===[[File:Errata_tool_b.jpg]]===
The above image demonstrates how the UI might change when one of the bubbles is clicked on (or maybe on mouseover). The block is isolated, errors are noted with numbers, and enumerated below (keeping alterations and adjustments isolated from the original draft).

= Alternate UI Proposal =
The visual implementation above is fairly simple to implement, but may not be the most intuitive. An alternative
version has the script fetch the errata table as before, but instead of speech bubbles and margins and stuff; if
there is errata, then a button or link is shown that has a label reading (in whatever appropriate language)
"Show errata for this license." And "hide errata for this license", whichever is applicable. When the 'show' state
is active; areas to be subtracted would be highlighted in red, with the 'strike through' text decoration. The
corrections to be added would follow their subtractions, probably highlighted in yellow. Additional comments could
be given a speech bubble icon that contains the text in a tooltip.

== Alternate UI Draft Image ==
===[[File:Errata_tool_alternate.jpg]]===
The above demonstrates how errata is expressed by highlighting text with errors with red, and their substitutions with green. Additionally, it might make sense to have some way of overlaying a comment or explanation (maybe on mouseover?) in such a way that it does not read as part of the license. In this case, such a comment appears in the black box as an example, but not likely to be a good way to implement it in practice. Also, the above doesn't sugest that those are the only ways to annotate, but rather demonstrates the look and feel abstractly from a UI perspective.

4.0 License Errata Annotation Tool

2012-02-10T22:07:42Z

Jonathan Palecek:

= Proposed Legalcode Errata Tool =
== Proposal ==
Despite our best efforts, spelling errors and other errata are sometimes included in the published legal code for
licenses. Creative Commons publishes SHA1 checksums for legal code, which allows people who receive a copy of the
license to easily verify this it has not been tampered with. Therefore Creative Commons does not amend legal code
once published.

With the upcoming 4.0 licenses brings the opportunity to include an annotation tool in the published legal code.
This would still allow for SHA1 checksums for verifying authenticity, but would allow for non-intrusive annotations
to be added after the page has loaded (assuming javascript is available).

== Visual Implementation ==
The errata tool would appear as a small margin on the left hand side of the page. When the page is
loaded, a script in the legal code page would then fetch the errata data for the license. The script would then
add small speech bubble icons into the margin. For every section with errata info, there is a corresponding speech
bubble. When a speech bubble has been clicked on or perhaps on mouseover; a bulleted list of errata appears, and
the corresponding parts of the legal code page are highlighted.

== Technical Implementation ==
When the deed is loaded, a script is executed. An XHR is used to fetch the errata data from one of our servers.
The return value will probably be a json structure which is a list of errata objects. Errata objects would appear
like so:

{id : "corresponding html_id", ch : "character offset", length : "erratum length", text : "errata text"}

The callback function for the errata XHR sorts the list by id, and then populates the page with the needed UI
elements. Text could easily be modified using character offsets irrespective of child html elements by way of
DOM transversal.

== UI Draft Images ==

[[File:Errata_tool_a.jpg]]
The above image demonstrates how the bubbles might appear in the margine, and how they line up with the text block for which they correspond.

[[File:Errata_tool_b.jpg]]
The above image demonstrates how the UI might change when one of the bubbles is clicked on (or maybe on mouseover). The block is isolated, errors are noted with numbers, and enumerated below (keeping alterations and adjustments isolated from the original draft).

= Alternate UI Proposal =
The visual implementation above is fairly simple to implement, but may not be the most intuitive. An alternative
version has the script fetch the errata table as before, but instead of speech bubbles and margins and stuff; if
there is errata, then a button or link is shown that has a label reading (in whatever appropriate language)
"Show errata for this license." And "hide errata for this license", whichever is applicable. When the 'show' state
is active; areas to be subtracted would be highlighted in red, with the 'strike through' text decoration. The
corrections to be added would follow their subtractions, probably highlighted in yellow. Additional comments could
be given a speech bubble icon that contains the text in a tooltip.

== Alternate UI Draft Image ==
[[File:Errata_tool_alternate.jpg]]
The above demonstrates how errata is expressed by highlighting text with errors with red, and their substitutions with green. Additionally, it might make sense to have some way of overlaying a comment or explanation (maybe on mouseover?) in such a way that it does not read as part of the license. In this case, such a comment appears in the black box as an example, but not likely to be a good way to implement it in practice. Also, the above doesn't sugest that those are the only ways to annotate, but rather demonstrates the look and feel abstractly from a UI perspective.

File:Errata tool b.jpg

2012-02-10T22:00:02Z

Jonathan Palecek: UI draft for the proposed errata tool.

UI draft for the proposed errata tool.

File:Errata tool a.jpg

2012-02-10T21:59:32Z

Jonathan Palecek: UI draft for the proposed errata tool.

UI draft for the proposed errata tool.

File:Errata tool alternate.jpg

2012-02-10T21:59:00Z

Jonathan Palecek: UI draft for the proposed errata tool.

UI draft for the proposed errata tool.

4.0 License Errata Annotation Tool

2012-02-10T00:59:08Z

Jonathan Palecek: Created page with "= Proposed Legalcode Errata Tool = == Proposal == Despite our best efforts, spelling errors and other errata are sometimes included in the published legal code for licenses. ..."

Translation tooling

2012-01-30T22:47:51Z

Jonathan Palecek: /* Extracting translations */

This currently describes the translation tooling as exists in the i18noverhaul branches. Hopefully in a couple of weeks this will be the case for the normal next/master branches!

== Extracting translations ==

Instead of providing a master.po file, the same information is pulled automagically from cc.engine's templates, in the content of the trans tags.

# Make modifications to cc.engine templates, commit, push, etc.
# In cc.i18n (using either buildout or virtualenv) run ./runcheckout.sh && ./extract.sh
# git add cc/i18n/po/en/cc_org.po
# git commit -m "Extracting new strings for translation"
# git push origin master

...done!

== Push source file up to transifex ==

# ssh a7.creativecommons.org
# sudo su cronuser
# cd /home/cronuser/transifex.net_i18n_checkout/
# git pull
# tx push -s

That last command will push the source file (english .po file you committed) up to transifex.

CC License Rdf Overview

2011-08-02T21:45:05Z

Jonathan Palecek: Created page with "The purpose of this article is basic documentation of the directories within the cc.licenserdf project. == cc/licenserdf/licenses/ == === License RDF Files === This directory c..."

The purpose of this article is basic documentation of the directories within the cc.licenserdf project.

== cc/licenserdf/licenses/ ==

=== License RDF Files ===
This directory contains an rdf file for every license we have. Each file is named to match the url path to it on the cc website, where underscores are replaced by slashes. An example of this is so:

* cc/licenserdf/licenses/creativecommons.org_publicdomain_zero_1.0_.rdf

Which corresponds to [http://creativecommons.org/publicdomain/zero/1.0/ this page].

=== The cc:legalcode Node(s) ===

If the jurisdiction for one of these licenses has one translation available for its legal code; then there is only one instance of this node in the rdf file for that license. This node contains the url to the legal code's page in its rdf:resource attribute.

If the jurisdiction has multiple translations available, there will be multiple instances of this node within the RDF file. There will also be instances of an additional node, called rdf:Description. The rdf:Description instances also contain the same url to the legal code, but under their rdf:about attribute. The rdf:Description instances each all have a child node dcq:language, who's inner text is the locale abbreviation for that translation.

It is the cc:legalcode and rdf:Description nodes that directly impact what links to legal code will appear on the deed's page.

=== The dc:title Nodes ===

These nodes are generated automatically by scripts in the project's tools directory.

=== d:title xml:lang="i18n" ===

This is a special instance of the dc:title node, identified by having "i18n" as the language name, instead of a locale abbreviation. The contents of this node is a python string template, and is used by a script to generate the other translation nodes for the subject predicate combination described by the string template.

The presence of this is a hack, not a standard practice; and may be unique to our codebase.

=== foaf:logo ===

In the rdf:resource attribute, each instance of this node contains a link to a different button graphic for the license, which ideally one displays proudly with the licensed content whatever webpage it appears upon. While many licenses will use the same images, each license variation contains a different url for its images. This is so we can use traffic statistics to get a good picture on the actual usage of our licenses, and which versions there of.

== cc/licenserdf/rdf/ ==

=== images.rdf ===

To quote Chris, "too be honest, I've never touched it."
...
Alright then =)

=== index.rdf ===

This file is automatically generated by a script. It is the combination of all of the rdf files in the cc/licenserdf/license folder.

=== jurisdictions.rdf ===

This file used to be for determining which languages to use for jurisdictions, but it may be no longer in use.

=== ns.html ===

Same as http://creativecommons.org/ns
Outlines the terms in the namespace for [http://wiki.creativecommons.org/CC_REL CC REL]. Contains a link to schema.rdf.

=== schema.rdf ===

The RDFa contents of http://creativecommons.org/ns (ns.html), but in the RDF/XML format. This would only ever need to be modified if we add more terms in our namespace.

== cc/licenserdf/tests/ ==

Unit tests for this project.

== cc/licenserdf/tools/ ==

=== add.py ===

This tool might not be in use anymore.

=== gen_i18n_titles.py ===

This tool automatically generates the <dc:title xml:lang="i18n"> nodes in the various rdf files in the cc.licenserdf/license/ directory. This was implemented during the sanity project.

=== __init__.py ===

Empty.

=== jurisdiction.py ===

This file contains tools for adding, launching & getting info about jurisdictions. Details on usage are out of the scope of this article.

=== merge.py ===

This tool generates the index.rdf file.

=== rebuild_images.py ===

To quote Chris again, "Looks interesting, but I've never touched it".

=== support.py ===

Contains miscellaneous tools for the project, much as cc/licenserdf/util.py also does. This separation between the two files is not due to any particular design decision, but rather is a quirk. The two files probably could be merged together at some point. (Is this accurate?)

=== translate_rdf.py ===

Automatically generates translations via the xml:lang="i18n" string template nodes.