Download to read offline
Uploaded byMichael Cummings
Linked data for Libraries
The document discusses the use of schema.org for structuring library catalog records and its importance for web pages and email messages. It highlights the benefits of using schema markup for enhancing retrievability in search results and details about specific properties for books. Additionally, it addresses the consequences and potential uses of linking data on MARC records, including identifying high-value URIs.
More Related Content
Linked data for Libraries
- 1. schema.org markup ofweb pages representing library catalog records
- 2. schema.org Schema.org promotes schemasfor structured data on the Internet, on web pages, in email messages, and beyond. Over 10 million sites use Schema.org to markup their web pages and email messages. Schema for books: CreativeWork > Book > Properties author, contributor, datePublished, editor, genre, publisher, bookEdition, illustrator, etc.
- 3.
- 4. Schema.org markup isnot displayed to end users
- 5. Markup aids retrievalin Google Search results
- 6. URI’s on MARCcatalog records: consequences and potential use
- 7. Linked data onMARC records $0
- 8. Unintended results ofadding URI’s to MARC Screenshot of unintended inclusion of URI as part of the 710 tag contents.
- 9. Which URI’s arehigh value for MARC records? Actionable Interpreted http://d-nb.info/gnd/4020526-5/about/lds http://id.loc.gov/authorities/names/n80134620.madsrdf.json
- 10. Which URI’s arehigh value for MARC records?
Editor's Notes
- #2 This section will outline how we use schema.org markup on our custom catalog at George Washington University.
- #3 On the ground. The markup proposed by schema.org is a popular standard for creating structured data on the web. At GWU our software developers decided to add schema.org microdata to the pages generated by our customized library catalog.
- #4 On the ground: Software developers / library IT staff had to add code to embed markup like this example into the HTML source for pages in a custom catalog.
- #5 The markup is **not visible to the end user**. This is how the previous example looks. This page content along with the underlying schema.org markup is saved in a site map on our web server.
- #6 On the ground: Software developers on the Library IT staff had to develop processes to generate, and continually update site maps so that Google’s web crawler can index the pages. A Google search will find many of our catalog records as shown in this example.
- #7 This section will outline some consequences of adding URI’s to our MARC catalog records.
- #8 On the ground: Jackie Shieh outlined work she and her staff working with OCLC had to perform in order to add URI’s to the MARC records. Some records have only one or two URI’s, others have URI’s for names, subjects, and work id like this example.
- #9 On the ground: Although our custom catalog ignored most URI’s, we discovered that some “snuck through” and appeared in the user interface, as in this example with URI’s (on the 710 tag). The IT staff had to do some re-programming to compensate for the URI’s here and on other tags.
- #10 On the ground: Library of Congress names / subjects, and OCLC fast / workID are readily actionable. Developers can append one of many format options to the end of the given URI to get machine readable outout. Some references are not really URI’s but can be interpreted and converted to a link for machine readable output.
- #11 On the ground: Catalogers need guidance or a policy regarding what URI’s to add to the MARC records. The OCLC WorkID is a high value URI because there is quite a lot of information available. The work ID could be used to identify different instances of a work, like one electronic and the other print. On the other hand, there is little benefit from adding multiple URI’s for the same type of data, like names. Decisions will have consequences for software developers who might want to utilize the URI’s to create new user interfaces.