Reuse tracking - Revision history

Iris Brest: /* Proposal 3: Hosted Scraped Data API */

2012-09-04T23:58:28Z

Proposal 3: Hosted Scraped Data API

← Older revision		Revision as of 23:58, 4 September 2012
Line 107:		Line 107:
	In this proposal, when a license badge is downloaded, the referrer URL		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		is stored in a queue. While the queue is not empty, a service
	periodically selects a URL from the queue, downloads the page, ~~reads~~		periodically selects a URL from the queue, downloads the page,
	and reads the metadata on the page. If the metadata indicates a		and reads the metadata on the page. If the metadata indicates a
	source work URL, that page would be downloaded and read as well.		source work URL, that page would be downloaded and read as well.
Line 116:		Line 116:

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

Iris Brest at 23:03, 4 September 2012

2012-09-04T23:03:13Z

← Older revision		Revision as of 23:03, 4 September 2012
Line 1:		Line 1:
	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.		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.		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 and 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.

Jonathan Palecek at 21:16, 9 August 2012

2012-08-09T21:16:14Z

← Older revision		Revision as of 21:16, 9 August 2012
Line 131:		Line 131:
	'''1.''' User requests a webpage (either one)		'''1.''' User requests a webpage (either one)

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

	'''3.''' The license badge is (usually) served directly by CC. This allows		'''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)
	us to build estimated adoption of the different licenses (and of
	which versions)

	'''4.''' On request of a license badge, a CC server could		'''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.
	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		Note that steps one through three are how things already are. Some of
	our existing infrastructure could be adapted to provide step four,		our existing infrastructure could be adapted to provide step four,
	making this proposal fairly easy to implement		making this proposal fairly easy to implement

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

2012-08-09T21:15:23Z

Proposal 3: Hosted Scraped Data API

← Older revision		Revision as of 21:15, 9 August 2012
Line 96:		Line 96:
	= Proposal 3: Hosted Scraped Data API =		= Proposal 3: Hosted Scraped Data API =

	Creative Commons already has two pieces of infrastructure that could		Creative Commons already has two pieces of infrastructure set up that
	be adapted to ~~be used for~~ reuse tracking. ~~When a website uses~~ the		could be adapted to collect reuse tracking information. These
	HTML provided by ~~our~~ license chooser to ~~mark~~ the page ~~with attribution~~		components are the license badges (when the HTML provided by the
	~~information and metadata,~~ the ~~badge icon~~ is ~~hosted by us as well~~. We		license chooser is used), and the deed scraper (a tool that is used to
	~~are able to~~ use the ~~download statistics of these images~~ to ~~create an~~		show attribution information on the deed page when the user is linked
	~~estimation of license~~ usage ~~in the wild, using the referrer string in~~		there from another site). We currently use the license badges to
	~~requests~~ for ~~the image~~. ~~We have a tool called Deedscraper which, when~~		estimate the usage statistics for our license. Both the license
	a deed ~~is opened, javascript on the page sends the~~ referrer ~~string~~ to		badges and deed scraper use referrer information to their work.
	~~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~~		In this proposal, when a license badge is downloaded, the referrer URL
	~~download request for~~ a license badge, ~~deedscraper reads~~ the ~~metadata~~		is stored in a queue. While the queue is not empty, a service
	~~from that page, and takes note of it~~ in a ~~database~~. ~~Thus~~, ~~we can~~		periodically selects a URL from the queue, downloads the page, reads
	~~build~~ a ~~bi-directional graph of remixes~~. ~~This data could~~ be ~~made~~		and reads the metadata on the page. If the metadata indicates a
	~~available through a simple API or dashboard~~.		source work URL, that page would be downloaded and read as well.

	This ~~service~~ would ~~yield significantly better~~ data ~~than~~ the ~~first two~~		This information would allow us to build a bi-directional graph of
	proposals, would ~~be straight forward to set up~~, ~~but~~ would require		usage data, which could be made accessible to 3rd parties via an API
	ongoing maintenance by the tech team, and ~~make Kinkade very grumpy~~.		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]]		[[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

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

2012-08-09T20:56:18Z

Proposal 3: Hosted Scraped Data API

← Older revision		Revision as of 20:56, 9 August 2012
Line 117:		Line 117:
	proposals, would be straight forward to set up, but would require		proposals, would be straight forward to set up, but would require
	ongoing maintenance by the tech team, and make Kinkade very grumpy.		ongoing maintenance by the tech team, and make Kinkade very grumpy.

			[[File:Proposal_3.png]]

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

2012-08-09T20:18:12Z

Proposal 2: Hosted Refback Tracking

← Older revision		Revision as of 20:18, 9 August 2012
Line 90:		Line 90:
	information to the database server run by CC.		information to the database server run by CC.

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

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

2012-08-09T20:17:41Z

Proposal 2: Hosted Refback Tracking

← Older revision		Revision as of 20:17, 9 August 2012
Line 61:		Line 61:

	= Proposal 2: Hosted Refback Tracking =		= Proposal 2: Hosted Refback Tracking =
	~~This approach~~ is a variation of the ~~first proposal, where CC runs an~~		Hosted Refback Tracking is a variation of the system described in the
	~~instance of the serverside component~~ described in the first proposal.		first proposal. In this version, Creative Commons hosts the database
	The ~~advantage,~~ is ~~that if the service sees significant adoption,~~ the		server. The page which contains the work that is the target of re-use
	~~aggregated data could be used to construct~~ a ~~better tree~~ of ~~derivative~~		tracking will include a small bit of JavaScript, which CC would
	~~work. However~~, ~~this advantage is '''only''' possible if use of this~~		provide. This approach requires no changes to the 3rd party servers.
	~~service is sufficiently widespread~~. ~~Otherwise, this proposal has~~ the		Our license chooser could include an opt-in option, which would
	~~same disadvantage as the first version~~, ~~with the additional cost and~~		automatically add the JavaScript to the HTML+rdfa license mark.
	~~liability to CC as it would lack~~ the ~~advantage~~ to the ~~first version~~.

	~~Hosted Refback Tracking is~~ a ~~variation~~ of ~~Independent Refback~~		This approach requires that CC host a service, thus losing the main
	~~Tracking~~, ~~in which CC runs~~ the ~~server-side database component~~		advantage of the first proposal. However, this version is easier for
	described in the first proposal, ~~and~~ the ~~refback is sent to us via~~		content creators to opt-in, as it requires no modifications to 3rd
	~~javascript embedded on the website hosting the original work~~.		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]]		[[File:Proposal_2.png]]

	~~This version requires that we host an maintain~~ a ~~special service~~, ~~thus~~		'''1.''' The user opens a website. The website contains a remixed
	~~adding~~ the ~~disadvantages of both cost and liability~~. ~~There are two~~		work, which is attributed properly and contains the relevant metadata.
	~~advantages this version has over the first proposal~~. The ~~fist~~
	~~advantage is that all that needs to be done~~ to the ~~website hosting~~ the		'''2.''' The user clicks on the link to the original work; the
	~~original content is to include~~ a ~~bit of javascript that we would~~		corresponding web page opens in the user's browser.
	~~provide (which is far easier than requiring~~ the ~~3rd part to setup a~~
	~~nginx module, apache module, wsgi middleware, or roll their own~~		'''3.''' When the page loads, a script on the page sends the referrer
	~~backend). The other advantage is that~~ '''if''' ~~there~~ is ~~significant~~		information to the database server run by CC.
	~~adoption, it might be possible to construct~~ a ~~better graph~~, ~~as the~~
	~~data would be aggregated~~ in ~~one place~~.		'''(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 =		= Proposal 3: Hosted Scraped Data API =

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

2012-08-09T19:57:09Z

Proposal 2: Hosted Refback Tracking

← Older revision		Revision as of 19:57, 9 August 2012
Line 74:		Line 74:
	described in the first proposal, and the refback is sent to us via		described in the first proposal, and the refback is sent to us via
	javascript embedded on the website hosting the original work.		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		This version requires that we host an maintain a special service, thus
Line 85:		Line 87:
	adoption, it might be possible to construct a better graph, as the		adoption, it might be possible to construct a better graph, as the
	data would be aggregated in one place.		data would be aggregated in one place.


	= Proposal 3: Hosted Scraped Data API =		= Proposal 3: Hosted Scraped Data API =

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

2012-08-09T19:42:50Z

Proposal 3: Hosted Scraped Data Api

← Older revision		Revision as of 19:42, 9 August 2012
Line 87:		Line 87:


	= Proposal 3: Hosted Scraped Data ~~Api~~ =		= Proposal 3: Hosted Scraped Data API =

	Creative Commons already has two pieces of infrastructure that could		Creative Commons already has two pieces of infrastructure that could

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

2012-08-09T19:40:47Z

Proposal 3: Hosted Scraped Data Api

← Older revision		Revision as of 19:40, 9 August 2012
Line 109:		Line 109:
	This service would yield significantly better data than the first two		This service would yield significantly better data than the first two
	proposals, would be straight forward to set up, but would require		proposals, would be straight forward to set up, but would require
	ongoing maintenance by the tech team.		ongoing maintenance by the tech team, and make Kinkade very grumpy.