1.
share, reuse, and remix— legally

2.
Distributed & Decentralized Work Registrations

3.
or

4.
A Mid-Year Update in 3 Parts

5.
1

6.
RDFa Update <ul><li>Adoption continues to grow rapidly

7.
Google, Yahoo indexing

8.
Publishers: </li><ul><li>UK Office of Information publishing

9.
MySpace

10.
SlideShare

11.
Flickr </li></ul></ul>

12.
Google <ul><li>Recently announced support for RDFa in “Rich Snippets”

13.
They're exploring ways to make this easier for “webmasters” </li></ul>

14.
Yahoo <ul><li>Supports RDFa in many properties

15.
Search Monkey lets you build “info bars”

16.
BOSS lets you query for presence of metadata </li></ul>

17.
2

19.
CC Network <ul><li>Launched October 2008

20.
A place creators to collect work references

21.
A platform for digital copyright registry exploration

22.
Built on ccREL

23.
Free Software: AGPL 3, available from code.creativecommons.org </li></ul>

25.
CC Network <ul><li>Growth

26.
Standardization

27.
Development </li></ul>

28.
Growth

29.
Standardization <ul><li>Goal: make it easy to integrate with our tools

30.
Solution: use RDFa to bind deeds + Network

31.
We'll never be the only registry

32.
Needed to document our practices

33.
Did a thorough review of what we developed

34.
Sent to OSCRI as RFC in May </li></ul>

35.
http://bit.ly/work-registrations

36.
Goals of the Specification <ul><li>Consistency </li><ul><li>Can a client follow one path and always arrive at an answer? </li></ul><li>Simplicity </li><ul><li>When choosing between Registries and Consumers, favor simplicity for Consumers </li></ul><li>Documentation </li><ul><li>How do we implement and test our work?

37.
What do other registries do to work with the deeds? </li></ul></ul>

38.
Describing Ownership User Work

39.
Describing Ownership <ul><li>Three entities involved </li><ul><li>Work

40.
User

41.
Registration </li></ul><li>Two ways to work: </li><ul><li>Users own Works directly

42.
Users own Registrations, which contain Works </li></ul></ul>

43.
Ownership Model User Work Registration

44.
Why Two Paths? <ul><li>Works are identified by URI

45.
Users may Register “patterns” </li><ul><li>http://creativecommons.org/* </li></ul><li>Registrations may contain multiple Works </li><ul><li>Multiple versions

46.
Multiple portions </li></ul><li>Registrations provide a “container”

47.
Supported direct ownership for simplicity </li></ul>

48.
Single Ownership Model <ul><li>Registries must publish the “Registration” metadata

49.
Simplifies verification model for clients

50.
Provides clear direction for adding features </li><ul><li>You may want to publish hashes, fingerprints, keys etc

51.
Registration is clearly the place for most of those </li></ul></ul>

52.
Lookup Service <ul><li>Previously only used to link to the Registration

53.
Envisioned as a complement to Regsistration

54.
Now part of the core specification

55.
Used as part of the Client verification process

56.
Richer results </li></ul>

57.
Lookup Service: Results <ul><li>Re-use approach for describing registrations

58.
Registries can just redirect to the Registration

59.
Use HTTP status to indicate high level result </li><ul><li>Success (200 or 302)

60.
Multiple matches (300)

61.
Failure (404) </li></ul></ul>

62.
Resolution <ul><li>A Consumer needs to establish a Graph for Verification

63.
Previously: </li><ul><li>Retrieve the User document (has_owner)

64.
Extract any RDFa

65.
Follow any rdf:see_also or cc:owner_of

66.
Extract any RDFa

67.
Repeat up to some ill-defined limit </li></ul><li>Previously favored simplicity for Registry </li></ul>

68.
Resolution <ul><li>New approach favors Consumers

69.
Just use the lookup service

70.
Returned document guaranteed to contain the needed graph </li></ul>

71.
Specification Status <ul><li>Up for comment from OSCRI

72.
Looking for feedback from people here today

73.
CC Network / CC deeds will be updated later this summer </li></ul>

74.
CC Network Development <ul><li>Working on updating to support revised spec

75.
Developing support for group/org accounts

76.
Exploring citation service

77.
Exploring use a seed for better CC Search </li></ul>

78.
3

79.
Science Commons MTA <ul><li>An MTA describes how biological materials can be used by researchers, collaborators

80.
More complex than our copyright licenses </li><ul><li>Parameters for “engaging” the agreement

81.
The basic document may describe a class of restriction, need additional details to understand it

82.
May be layered with an “implementing letter” </li></ul></ul>

83.
Current MTA Developments <ul><li>First iteration developed in 2007 </li><ul><li>Used the URL query string to carry additional details </li></ul><li>Working on deploying 2.0 now </li><ul><li>MTA work informed by our Attribution and CC Network tools

84.
Changing our model for including “parameters” </li></ul></ul>

85.
Why Change? <ul><li>Current approach is only useful to CC/SC

86.
Exposing all the information enables reuse

87.
We can build common tools across domains </li></ul>

89.
New Tooling <ul><li>The deeds currently use a custom server-side proxy

90.
Return JSON encoded nested arrays

91.
Using WebBackplane's Ubiquity project to clean up the code </li><ul><li>Possible to use without server side proxy

92.
Write lookups as SPARQL instead of array access

93.
Easily translate from our spec to code

94.
More easily test our code </li></ul></ul>

95.
jSPARQL YAHOO.cc.mta.MTA_INFO = { select: [ &quot;offer&quot;, &quot;material&quot;, &quot;disease&quot;, &quot;offer_permits&quot;], where: [ { pattern: [ &quot;?offer&quot;, &quot;http://www.w3.org/1999/02/22-rdf-syntax-ns#type&quot;, &quot;http://mta.sciencecommons.org/ns#Offer&quot; ] }, { pattern: [ &quot;?offer&quot;, &quot;http://mta.sciencecommons.org/ns#agreement&quot;, document.URL ] }, ... }

96.
Conclusion <ul><li>CC Network was a new way to develop for us </li><ul><li>Ignore the database, drive things with metadata </li></ul><li>Our experience there is informing other work

97.
MTA, CC Network will both help us improve our core “business” – the licenses

98.
Continue to see evidence that RDFa was a smart bet </li></ul>

99.
Nathan R. Yergler Chief Technology Officer Creative Commons [email_address] @nyergler {twitter | identi.ca} http://wiki.creativecommons.org/Tech_Summit_3_Update