Allison Ransom
Assistant Professor
Metadata and Discovery Librarian
Hunter College
Iris Finkel
Assistant Professor
Web and Digital Initiatives Librarian
Hunter College
Introduction
Hunter College Libraries launched a major weeding project starting in Spring 2025. By the end of the summer, subject librarians removed over 23,000 print books from the Libraries’ collections, which comprised approximately 450,000 print books. We deleted the books’ relevant item data and holdings information, along with any accompanying bibliographic metadata from ExLibris Alma, the Integrated Library System used by all City University of New York (CUNY) libraries. Hunter librarians recognized potential value in the withdrawn data and considered ways to productively use it. While withdrawn records remain queryable in Alma Analytics, the data are no longer available to the public through Primo, the public user interface of Alma, setting us on the path to search for other mechanisms to analyze the data in different contexts.
Other librarians at Hunter previously created data visualizations that reflected weeded library data, but they were static and could not display the breadth of the metadata reflecting the items that were weeded from the collections. Therefore, we turned to the semantic web and the structure behind knowledge graphs and experimented with translating MARC data into RDF to make it visually relational and represent connections within the data. This project, while not at the level of more sophisticated, larger and more nuanced knowledge graphs, borrows from the inherent structures and theories to create a simple queryable visualization that can help users engage with the data about our weeded collections in a different way.
Semantic Representation of Weeded Data
For our first project, we wanted to add value to the weeded data by connecting the titles no longer held by Hunter College Libraries to WorldCat records, thereby locating other libraries that hold those titles. With a use case in mind, we, the Metadata and Discovery Librarian and the Web and Digital Initiatives Librarian identified a knowledge graph—a visual, queryable representation of connected concepts and entities—as a potential solution for organizing, accessing and connecting data about withdrawn items. Following the frames of the “collections as data” movement, we aspired to make meaningful connections, document our process, and remain open to consider other ways to interrogate our growing dataset of weeded titles (Padilla, 2017). Below, we document the process we used to convert data extracted from Alma to RDF to visualize the data in a knowledge graph for a prototype of the weeded data project.
Connection of RDF to Library Metadata
Knowledge graphs are databases that represent entities and the relationships that connect them. They are built using RDF, or Resource Description Framework. Knowledge graphs represent concepts associated with the Semantic Web, which promotes the interchange of data across sources through employing URIs, or Uniform Resource Identifiers, to identify and make connections between entities. The underlying RDF structure of knowledge graphs relies on relationships between entities, which lends itself to how library metadata is already structured in MARC. For instance, books have subjects, classification numbers, titles, authors, and more that they share with other books. In an OPAC, MARC fields within a bibliographic record are indexed and allow users to find records for resources with similar attributes. RDF and MARC both structure bibliographic data by defining the relationships that entities have with their attributes. In both, the description of a work comprises data that describes subjects, creators, titles, and other entities that define the work. In MARC, the relationship between entities and their attributes is indirectly defined because the descriptions of what MARC fields and codes mean exists in external documentation, such as the Library of Congress’ MARC guidelines. But in RDF, relationships between entities and attributes are explicitly defined and connected to the data by way of connecting to schema by way of namespaces and URIs.
Both use controlled vocabularies and authority control to standardize data across records thereby helping them link together, but RDF’s reliance on namespaces and URIs for defining entities within the data itself, helps ensure authoritative relationships between entities and attributes that MARC can’t do. While MARC can encode data through fields, indicators, and subfields, what the fields, indicators, and subfields mean is not specifically stated in the data. For instance, the 100 field in a MARC record can be used to enter a personal name and display that information within the MARC record structure, but that relationship cannot be made with other works because that relationship isn’t represented by identifiers that can link data together. On the other hand, RDF imbues data with meaning by way of URIs and namespaces connecting the data to descriptive schema and links similar data together.
Data in RDF is composed in statements, called triples, that comprise a subject, predicate, and object. The triple has meaning, which allows the RDF data to link to other data.
For example, a RDF triple could look like this:
“This book has author [name of author]”
Wherein the subject is the “book”, or the thing being described, the predicate is “has author,” which links the subject to something else, and “[name of author]” is the object, which is the value of the predicate (Fig. 1).
On the other hand, the same relational meaning can’t be implied in MARC. For example, the same concept described by the RDF could look like this in MARC:
100 1_ $a [name of author], $e author.
245 10 $a [Title of book].
The MARC fields, subfields, and indicators describe the author of a work, but the attributes of that data, and therefore the relationship of the author to the book, isn’t explicitly stated within the data.
Applying RDF to Hunter Library’s Weeded Records
First, we queried Alma Analytics for item data reflecting the physical items that were weeded during the weeding project and exported the report as a .csv file. After installing RDFLib, we ran a Python script to convert the .csv file into a .ttl file (Fig. 2). We then published the .ttl file on TriplyDB, a platform that stores and validates RDF data, as well as provides a SPARQL endpoint that makes the data publicly accessible and queryable.
Next, we built an interactive knowledge graph explorer using Cytoscape.js, which facilitates the visualization of RDF data using JavaScript. We created a HTML webpage with a search function that sends the query to the SPARQL endpoint, transforms the results of the query from the RDF data into data that can be displayed as nodes and edges in a graph, and then visualizes the data. This webpage serves as the entry point to a database where users can search for books, click on and expand related entities, and progressively explore the graph by clicking through each node that expands to more related nodes.
Finally, we published the knowledge graph explorer as a test case publicly using GitHub, which provides free hosting for web applications. GitHub allowed us to publish a functioning prototype of a public, interactive knowledge graph explorer in which the data (TriplyDB), the interaction logic (Cytoscape.js with JavaScript), and the hosting (GitHub) work seamlessly as a single system. This helped us to visualize our proof of concept as we work further to develop it into a working model.
Results
We succeeded in developing a queryable visualization that represents relationships between attributes of weeded books. Users can search for a title, subject, or any field in the search bar. When prompted, the JavaScript in the code turns the text the user entered into a SPARQL query that searches the triples in the TriplyDB data store via the SPARQL endpoint for objects that contain the user’s search term. Cytoscape.js then renders the query results as a visual graph. For example, when a user searches the term “David Smith : a centennial,” under Title, the results render as a graph that shows a node for the title as well as a node for the subject of the book, which in the data is represented by the LC call number range N. When the user clicks on “N,” multiple nodes are revealed, each with the title of another book from the data that also has the subject “N” (Fig. 3).
Knowledge Graph Explorer: https://hunter-test-case.github.io/knowledge-graph-explorer/
Conclusion
The knowledge graph project enabled us to see what is possible using semantic data. While more work is required to establish connections to WorldCat, we are encouraged by the results thus far and will continue to interrogate weeded data dynamically and semantically.
