Libraries and Linked Data: Looking to the Future (2)
Download as PPTX, PDF4 likes1,254 views
The document discusses options for new bibliographic frameworks after MARC. It describes three scenarios: 1) a relational/object-oriented RDA database, 2) linked bibliographic and authority records, and 3) flat files without links. It then discusses three approaches to implementing a new framework: 1) going native by using URIs for things, elements and values, 2) extracting data from existing MARC records, and 3) serializing data into key-value pairs, XML, or JSON. Advantages and disadvantages of each approach are outlined.
Libraries and Linked Data: Looking to the Future (2)
- 1. New bibliographic framework AFTER MARC: OPTIONS
- 2. Aside: what we need to do • Identify the resources we are describing, e.g. http://lccn.loc.gov/agr52000278 • Identify the data elements we are using, e.g. http://rdvocab.info/Elements/title • Identify (where possible) the information of our description, e.g. http://www.geonames.org/4984247/ann-arbor.html
- 3. Aside: what we need to do http://www.worldcat.org/oclc/474017053 http://viaf.org/viaf/27068555 http://purl.org/dc/terms/creator
- 4. RDA scenarios 5editor2rev.pdf 1. Relational/object-oriented RDA Database Implementation Scenarios 2. Linked bibliographic and authority records 3. Flat file (no links)
- 8. New bibliographic framework scenarios 1. Go native according to Coyle 2. Extract 3. Serialize
- 9. Serialize “To put data into a particular data format that can be stored or transmitted.”
- 10. Serialize dc:title=“Scheduling Ourselves to Death” dc:date=“2003” dc:description=“The use of office scheduling software has led to an increase in meetings, to the point that I am definitely scheduled for meetings after retirement, and probably even after death. The fault is in the basic premise of the software: you are either in a meeting, or available to be in a meeting.” dc:creator=“Karen Coyle” key/value pairs
- 11. Serialize <dc:title>Scheduling Ourselves to Death</dc:title> <dc:date>2003</dc:date> <dc:description>The use of office scheduling software has led to an increase in meetings, to the point that I am definitely scheduled for meetings after retirement, and probably even after death. The fault is in the basic premise of the software: you are either in a meeting, or available to be in a meeting.</dc:description> <dc:creator>Karen Coyle</dc:creator> XML
- 12. Serialize { "title": "Scheduling Ourselves to Death", "date": "2003", "description": "The use of office scheduling software has led to an increase in meetings, to the point that I am definitely scheduled for meetings after retirement, and probably even after death. The fault is in the basic premise of the software: you are either in a meeting, or available to be in a meeting.", "creator": "Karen Coyle" } JSON
- 13. MARC & MARCXML 100 $a Coyle, Karen <datafield tag="100" ind1="1" ind2=" "> <subfield code="a”>Coyle, Karen 245 $a Scheduling… </subfield> </datafield> <datafield tag="245" ind1="1" ind2="0"> <subfield code="a">Scheduling… </subfield> </datafield>
- 14. MARC to RDF 001 1234567 100 $a Coyle, Karen 245 $a Scheduling ourselves to death
- 15. MARC to RDF 1234567 100 $a Coyle, Karen 1234567 245 $a Scheduling ourselves to death
- 16. MARC to RDF 100 $a Coyle, Karen http://mystuff/123 4567 245 $a Scheduling http://mystuff/123 ourselves to death 4567
- 17. MARC to RDF http://mystuff/100 Coyle, Karen http://mystuff/123 $a 4567 http://mystuff/245 Scheduling http://mystuff/123 $a ourselves to death 4567
- 18. MARC to RDF http://mystuff/100 Coyle, Karen http://mystuff/123 $a 4567 http://mystuff/245 Scheduling http://mystuff/123 $a ourselves to death 4567 relationship subject URI “Text” URI
- 19. “things and strings” id:1234 id:abcd id:$%^& id:3n5b “Herman Melville”
- 20. MARC to RDF http://mystuff/100 Coyle, Karen http://mystuff/123 $a 4567 http://mystuff/245 Scheduling http://mystuff/123 $a ourselves to death 4567 http://mystuff/123 http://mystuff/830 457 4567 $v http://mystuff/123 http://mystuff/100 1949 4567 $d
- 21. advantages disadvantages • mechanical • doesn’t change the data • doesn’t change the data • keeps library data in a • doesn’t require system library-only silo changes • doesn’t link to any data outside of libraries
- 22. Extract database of MARC records id:1234 id:abcd id:$%^& id:3n5b “Herman Melville” “things and strings”
- 24. What’s a “thing”? Work Object Person Expression Place Family Manifestation Concept Corp Item Event FRBR
- 30. National Library of Spain (BNE)
- 36. OCLC “linked data” • Uses microformats (RDFa and schema.org) • Is embedded in the record display • Was announced June 20, 2012
- 37. Extract Advantages Disadvantages • Does not require library • Isn’t visible to catalogers, so system changes no human QC • Can be re-extracted as we • Key identifiers are not part learn more of the base metadata • Isn’t visible to catalogers • Limited by what we put into records today
- 38. “go native” • things, elements and values that have URIs • a data design that stores things and relationships • a creation interface that hides this from creators but maintains the integrity of the data
- 39. “go native” Advantages Disadvantages • Interoperability with web • Requries replacement of resources library systems • Interoperability with intent • Difficult to make the of RDA cost/benefit argument • Possibilities for a richer library catalog, and one that does not require the user to choose between the library and the web as information resources
- 40. … MORE THOUGHTS?