Difference between revisions of "Reuse tracking"
| Line 13: | Line 13: | ||
== Proposal 2: Hosted Refback Tracking == | == 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 | + | 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 == | == Proposal 3: Hosted Scraped Data Api == | ||
Revision as of 21:39, 8 August 2012
Contents
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.
