The Site is the API

1,044 views
975 views

Published on

Published in: Technology, Education
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,044
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
3
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • The Site is the API

    1. 1. The Site is the API Nathan R. Yergler Creative Commons
    2. 2. share, reuse, and remix— legally
    3. 5. <a href=” http://creativecommons.org/licenses/by/3.0/ ” rel=”license”> Attribution 3.0 Unported </a>
    4. 6. Why do we care? Programs should be able to answer simple questions about licensed works. <ul><li>What is the work's license?
    5. 7. Does it allow commercial use?
    6. 8. Are derivative works allowed?
    7. 9. How do we attribute the work? </li></ul>
    8. 11. CC Network <ul><li>Launched October 2008
    9. 12. A place creators to collect work references
    10. 13. A platform for digital copyright registry exploration
    11. 14. Free Software: AGPL 3, available from code.creativecommons.org </li></ul>
    12. 15. Registry Requirements <ul><li>Allow users to “claim” a work </li><ul><li>Identify works by URL
    13. 16. Wildcard claiming: http://yergler.net/* </li></ul><li>Make registration information available to other applications/agents
    14. 17. Allow applications to query registrations
    15. 18. Allow creators to mark works as “registered” </li></ul>
    16. 19. Deed Requirements <ul><li>Integrate registration information on CC Deeds
    17. 20. Support registries other than CC Network </li></ul>
    18. 22. How do other registries “play”? <ul><li>Several commercial registries are CC Enabled
    19. 23. This is an exploratory project; we probably don't have all the answers
    20. 24. We should just get out of the way </li></ul>
    21. 25. Key Requirements <ul><li>Make registration information available to other applications/agents
    22. 26. Integrate registration information on CC Deeds
    23. 27. Allow others to play </li></ul>
    24. 28. Prior Art
    25. 29. Prior Art – Attribution Metadata <ul><li>Users can assert a name and URL for Attribution
    26. 30. We encode this in the generated HTML
    27. 31. Our deeds look at the Referrer to find this
    28. 32. “ Eating our own dogfood” </li><ul><li>We recommend RDFa
    29. 33. And we consume it </li></ul></ul>
    30. 34. Prior Art – Retrieving RDFa <ul><li>Same-domain restriction complicates things
    31. 35. We could parse the RDFa client side if not for that restriction
    32. 36. Developed a “scraper” application </li><ul><li>Takes a URL
    33. 37. Retrieves it and extracts RDFa
    34. 38. Returns a JSON serialization </li></ul><li>Python WSGI application makes deployment and integration with existing app easy </li></ul>
    35. 39. Registering Works
    36. 40. Exposing Registration Information <ul><li>We identify works by URI
    37. 41. We also record the license URI
    38. 42. Publish a single page per Registration
    39. 43. A Registration may include multiple Works
    40. 44. RDFa is used to encode the registration information </li></ul>
    41. 45. Interface Considerations <ul><li>Javascript is limited to progressive enhancement </li><ul><li>RDFa builds on the existing DOM
    42. 46. We could insert the RDFa with Javascript but that severely increases demand on consumers </li></ul></ul>
    43. 49. Published Assertions <ul><https://creativecommons.net/nathan/> <http://rdfs.org/sioc/ns#owner_of> <http://labs.creativecommons.org/ ~nathan/info/decoupling.html> . </ul>
    44. 50. Creator Identification <ul><https://creativecommons.net/nathan/> </ul><ul><http://rdfs.org/sioc/ns#name> </ul><ul>&quot;Nathan Yergler&quot;@en . <https://creativecommons.net/nathan/> <http://rdfs.org/sioc/ns#member_of> </ul><ul><https://creativecommons.net/> . </ul>
    45. 51. Registry Identification <ul><https://creativecommons.net/> </ul><ul><http://purl.org/dc/terms/title> </ul><ul>&quot;CC Network&quot;@en . </ul>
    46. 52. Testing <ul><li>At this point we've implemented a basic “API”
    47. 53. We want to make sure it doesn't break
    48. 54. We can use a stock RDFa parser to test this </li></ul>
    49. 55. Testing Example <ul>def testRegistration(self): # create a registration reg = Registration(url=”http://example.org/1”, title=”Test Registration”, license=”http://creativecommons.org/...”) # render & parse for RDFa triples = rdfdict.RdfaParser().parse_url( r.get_absolute_url()) # assert it contains the interesting triples assert “http://example.org/1” in triples[r.get_absolute_url()][SIOC(owner_of)] </ul>
    50. 56. Querying Registrations
    51. 57. Querying Registrations <ul><li>Look up registration by URI
    52. 58. Others may implement differently so useful to perform “discovery”
    53. 59. We can publish assertions about the service
    54. 60. Ideally the “protocol” assertion contains enough information for developers to build a client implementation </li></ul>
    55. 61. Service Identification <ul><https://creativecommons.net/> </ul><ul><sioc_services#has_service> <https://creativecommons.net/r/lookup/> . <https://creativecommons.net/r/lookup/> <http://rdfs.org/sioc/services#service_protocol> <http://wiki.creativecommons.org/work-lookup> . </ul>
    56. 62. Query Results <ul><li>We already have code for rendering the registration with RDFa
    57. 63. We can re-use this: </li><ul><li>On success, redirect to the actual Registration page
    58. 64. On failure, HTTP 404 </li></ul></ul>
    59. 65. “Validating” Registrations
    60. 66. Network Membership Badge <ul><li>Actually important!
    61. 67. How can other agents trust claims we publish?
    62. 68. Need an additional piece of “confirmation” </li></ul>
    63. 70. Published Assertions <ul><> <http://rdfs.org/sioc/ns#has_owner> <https://creativecommons.net/nathan/> . </ul>
    64. 71. Binding Work and Profile <ul><https://creativecommons.net/nathan/> <http://rdfs.org/sioc/ns#owner_of> <http://labs.creativecommons.org/ ~nathan/info/decoupling.html> . </ul><ul><http://labs.creativecommons.org/ ~nathan/info/decoupling.html> <http://rdfs.org/sioc/ns#has_owner> <https://creativecommons.net/nathan/> . </ul>
    65. 72. Reciprocal Ownership Metadata “ Identity” Work
    66. 73. The Deeds Are An Application
    67. 74. Network + License Badges
    68. 76. Metadata Instead of Coupling <ul><li>Deeds request metadata from the referring page </li><ul><li>Attribution Information
    69. 77. Ownership information </li></ul><li>Certain relationships are traversed </li><ul><li>rdf:seeAlso
    70. 78. sioc:memberOf </li></ul></ul>
    71. 79. Metadata Instead of Coupling
    72. 80. Metadata Instead of Coupling
    73. 81. Testing <ul><li>Test individual pieces: </li><ul><li>Make sure we're publishing assertions
    74. 82. Scraper/Proxy has its own test suite </li></ul><li>Remaining pieces to test: </li><ul><li>Client publication
    75. 83. Deed javascript </li></ul><li>Currently: </li><ul><li>Functional testing </li></ul></ul>
    76. 84. Challenges <ul><li>Requires additional server side proxy
    77. 85. Time outs </li></ul>
    78. 86. General Principles <ul><li>You're probably using templates already – make them useful for software, too.
    79. 87. Vocab mix-n-match is fine: use established vocabularies whenever possible (DC, etc).
    80. 88. If you're a market leader (or hope to be), commit to publishing a minimum set of information.
    81. 89. Think about your URIs – you're making a commitment to maintain them. </li></ul>
    82. 90. Ongoing Work & Improvements
    83. 91. Science Commons MTA <ul><li>Similar to our Attribution work
    84. 92. More complex model: </li><ul><li>Agreements are “parameterized”
    85. 93. Need to supply the details of a specific Offer
    86. 94. Want to do so in a machine readable way </li></ul><li>Forms the basis for a more generic Javascript implementation </li></ul>
    87. 95. Using SPARQL <ul><li>Currently do pre-processing server side, return JSON representing nested arrays
    88. 96. Would like to write assertions as SPARQL queries instead of JSON array traversal
    89. 97. Ubiquity (Mark Birbeck) has a Javascript SPARQL implementation (jSPARQL) </li><ul><li>http://code.google.com/p/ubiquity-rdfa/ </li></ul></ul>
    90. 98. 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 ] }, ... }
    91. 99. JSPARQL Querying 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 ] }, ... } var query = new RDFQuery(store); var results = query.query2(YAHOO.cc.mta.MTA_INFO); // iterate over our result set query.walk2(results, { action : function (obj) { // obj has attributes for each selected value document.write(obj.offer); }});
    92. 100. Aggregate Data Access <ul><li>Linked data provides a solution for individual level – tell me about this one thing
    93. 101. What if I want to know about all the records?
    94. 102. Sparken is a Python WSGI application that serves up SPARQL </li><ul><li>Simple web crawler for easy data injection
    95. 103. Easily deployed with WSGI
    96. 104. [real soon now] </li></ul></ul>
    97. 105. Nathan R. Yergler Chief Technology Officer Creative Commons [email_address] http://wiki.creativecommons.org/The_Site_is_the_API

    ×