what i want from linked data
1 like542 views
The document discusses the importance of creating persistent and resilient linked data that is more effective in web accessibility without relying on software changes. It highlights the need to cache and proxy linked data to maintain its availability despite potential resource failures. The author emphasizes that a focus on lasting content will enhance the precision and recall of linked data, improving its overall utility.
what i want from linked data
- 1. what i want from Linked Data Dan Chudnov dchud at umich edu 2008-02-23 code4lib 2009 preconf
- 2. part one what i care about
- 3. i care about content that *lasts*
- 4. i care about persistence of precision resilience of recall
- 6. i care about doing web stuff better
- 7. i don’t care about data formats
- 8. i don’t care about the LOD cloud
- 9. the “LOD cloud” a “ready reference” collection
- 11. data for data’s sake selected data for a designated community
- 12. one isn’t useful the other is antiquated
- 14. part two the obvious step but first a disclaimer
- 15. MY OPINIONS DO NOT REFLECT THOSE OF: MY EMPLOYER THE US GOV’T PRES. BARACK OBAMA MOST OTHER HOOSIERS
- 16. the obvious step
- 17. picture if you will
- 28. the web is made of links
- 40. unless they know to look
- 41. so the obvious step is
- 42. LINK THIS DATA
- 43. resource URI rel=contents rel=contents rel=contents (already has) resource URI resource URI resource URI
- 48. recall improves with explicit links through authority recs
- 49. this is doing web stuff better
- 50. i care about doing web stuff better
- 51. just by doing HTML / HTTP
- 52. use URIs as names for things use HTTP URIs provide useful information include links to other URIs http://www.w3.org/DesignIssues/LinkedData.html
- 55. part three the not obvious step
- 56. two problems with the obvious step
- 57. 1. there’s more stuff
- 68. 2. stuff goes away
- 70. lcsh.info’s demise: what did it break?
- 71. nothing
- 72. we’d only just started thinking what to do with it
- 73. what if we had?
- 76. we’re not here to learn about 404’d data
- 77. if we apply linked data practices to this
- 78. resource URI rel=contents rel=contents rel=contents (already has) resource URI resource URI resource URI
- 79. when an lcsh.info goes away all that breaks
- 80. same for all of this but not any of this
- 81. a 404 web isn’t a better web
- 82. part four what i think we should work on
- 83. i care about content that *lasts*
- 84. i care about persistence of precision resilience of recall
- 85. i want linked data that lasts
- 87. to-do #1 cache linked data
- 88. if your site breaks when links break cache and link yourself
- 89. instead of this
- 91. just like we do in ILS/OPACs
- 92. but, yknow, the better web way
- 93. so if this happens your links still work
- 94. to-do #2 proxy linked data
- 95. if this happens your cache still work
- 97. dvcs lesson: no central server is better
- 98. make every cache its own linked data source
- 99. instead of just this UChicago cache same as
- 100. enable this UChicago cache same as same as same as same as same as
- 101. if one goes down the others live on
- 102. if others live on it’s all still linked
- 103. if it’s all still linked we can keep adding
- 104. so make your cached recs useful linked URIs too
- 105. #1 conventions for caching linked data
- 106. #2 conventions for proxying linked data
- 107. food for thought
- 108. but now, let’s eat!