[{"content":"I have now migrated a library discovery layer twice in two years. At my previous institution I finished an EBSCO Discovery Service update just before leaving. Then I arrived at my current job, assessed the environment, and realized that the Primo instance I\u0026rsquo;d inherited was still running Classic — not Primo VE, not NDE, but the original, pre-Angular, pre-modern-stack Primo that Ex Libris has been nudging libraries away from for years. Nobody had upgraded it because, until I arrived, there was no dedicated systems administrator to do it.\nSo I skipped VE entirely and went straight to NDE. Here\u0026rsquo;s what that was like.\nSome context on the Primo landscape For readers outside the library systems world: Primo is Ex Libris\u0026rsquo;s discovery layer, the search interface that sits in front of an institution\u0026rsquo;s catalog, licensed databases, and other resources. Over the past several years Ex Libris has moved through three distinct generations of the product. Primo Classic was the original, a Java-based system with a customization model built around XML configuration and a front-end that predates the current era of JavaScript frameworks. Primo VE (View Editor) was a transitional version, introducing a new Angular-based front-end while retaining much of the underlying architecture. Primo NDE (New Discovery Experience) is the current generation, fully cloud-managed, with a different customization model and a significantly different operational relationship between the library and Ex Libris.\nThe typical migration path was Classic to VE, then eventually VE to NDE. My institution never made the first hop, which meant I was starting from further back than most, but also that I didn\u0026rsquo;t have to manage two transitions sequentially.\nWhat skipping the middle version actually meant The practical consequence of jumping directly to NDE was that I had no institutional muscle memory for how the new system worked. Libraries that went through VE at least had staff who had touched the Angular interface, who understood the new customization approach in outline even if they hadn\u0026rsquo;t gone deep. We had none of that. The Classic instance had been configured over years by people who were no longer at the institution, in ways that weren\u0026rsquo;t always documented, and the task was to understand what we had, decide what needed to survive the migration, and rebuild it in an environment that works completely differently.\nIn Classic, heavy customization happens through XML pipes, tiles, and template overrides. The system is extremely flexible and, correspondingly, extremely easy to turn into an unmaintainable tangle of local changes that nobody fully understands. NDE moves the customization model toward a CSS/JavaScript injection approach with a more constrained sandbox, which sounds like a step backward in flexibility but in practice tends to produce more maintainable configurations. It\u0026rsquo;s harder to shoot yourself in the foot. It\u0026rsquo;s also harder to do some of the things Classic made possible, and you spend a fair amount of time figuring out which category a given requirement falls into.\nDiscovery migrations are metadata migrations One thing that both the EDS update and this migration reinforced: discovery layer projects are mostly metadata projects. The interface work gets the attention, and the interface work is genuinely important, but the bulk of the consequential decisions are about what you\u0026rsquo;re surfacing and how.\nAt the EDS institution, the main challenge was reconciling holdings data between the ILS and the discovery index, making sure that what EBSCO thought we had licensed matched what we actually had licensed, and that full-text links were resolving correctly. At my current institution, the Primo migration involved similar questions about the Central Discovery Index (CDI), Ex Libris\u0026rsquo;s shared metadata pool, and how our local holdings mapped onto it. When something isn\u0026rsquo;t findable after a migration, the problem is almost never the interface. It\u0026rsquo;s almost always a metadata mismatch somewhere in the pipeline.\nThis is why discovery migrations require someone who can think across layers. You need to understand the front-end well enough to configure and customize it, but you also need to understand the data flows underneath: how records get into the index, how availability information gets attached to them, how the link resolver connects a discovery result to full text. A migration that gets the interface right but leaves the metadata in a degraded state is a migration that users will experience as a regression, even if the new UI is objectively better.\nBeing the first dedicated sysadmin There\u0026rsquo;s a particular kind of institutional archaeology that happens when you\u0026rsquo;re the first person with a dedicated systems role. The systems exist. They work, more or less. But the decisions that shaped them are embedded in the configuration rather than in any documentation, and the people who made those decisions may have left years ago.\nSome of what I found in the Classic instance was intentional and worth preserving. Some of it was accumulated workarounds for problems that no longer existed. Some of it was configurations that had probably never worked correctly, quietly doing nothing, because nobody had the access or the context to remove them. Disentangling those categories takes time, and it means accepting that you will sometimes make the wrong call.\nWhat it doesn\u0026rsquo;t mean is being paralyzed by the history. At some point you have to decide what the system should do for your users now, document your reasoning, and build toward that. The goal isn\u0026rsquo;t to perfectly reconstruct what was there before. The goal is a discovery layer that works reliably, that library staff can maintain without heroics, and that the next person to inherit it can understand without having to excavate.\nWhat I\u0026rsquo;d tell someone starting this process Two migrations in two years is a reasonable sample size for a few observations. First, budget more time for the metadata audit than you think you need and less time worrying about the UI. Users notice when things are missing; they adapt to interface changes faster than you expect. Second, get staff involved early, not just for buy-in, but because the people who answer reference questions know things about how patrons search that you will not discover from system logs alone. Third, document as you go, even imperfectly. A Markdown file with rough notes about why you made a particular configuration choice is worth more than a comprehensive document you plan to write after the migration is done and never actually write.\nAnd fourth: if you\u0026rsquo;re the first dedicated sysadmin, accept that you will spend part of your first year on work that looks like maintenance but is actually foundation. You\u0026rsquo;re not just running the systems. You\u0026rsquo;re building the conditions under which the systems can be properly run. That\u0026rsquo;s a different thing, and it takes longer, but it\u0026rsquo;s worth it.\n","permalink":"https://katzir.xyz/posts/discovery-layer/","summary":"\u003cp\u003eI have now migrated a library discovery layer twice in two years. At my previous institution I finished an EBSCO Discovery Service update just before leaving. Then I arrived at my current job, assessed the environment, and realized that the Primo instance I\u0026rsquo;d inherited was still running Classic — not Primo VE, not NDE, but the original, pre-Angular, pre-modern-stack Primo that Ex Libris has been nudging libraries away from for years. Nobody had upgraded it because, until I arrived, there was no dedicated systems administrator to do it.\u003c/p\u003e","title":"From Classic to NDE: Upgrading Primo When nobody did it before you"},{"content":"A few years ago I co-created a digital archive. The Victorian Jewish Writers Project began as a scholarly problem: nineteenth-century Jewish writers in Britain had been systematically excluded from the literary canon, their work scattered across out-of-print volumes, digitized newspaper runs, and institutional collections that had no particular reason to surface them together. The project was an attempt to do something about that, to gather, describe, and make discoverable a body of writing that existing finding tools were not built to find.\nBuilding the VJWP was a crash course in library infrastructure, and it raised a question I keep coming back to in my own line of work and one I see digital humanities scholars grappling with constantly: who actually keeps the archive, and what does \u0026ldquo;keeping\u0026rdquo; require?\nThe Canon as a discovery problem Literary canons get discussed in scholarship mostly in terms of taste, power, and critical judgment, and those conversations are important. But there\u0026rsquo;s a systems dimension that gets less attention. A writer disappears from literary history not only because critics stopped writing about them, but because the infrastructure of literary culture stopped indexing them. Their books go out of print. Their names don\u0026rsquo;t appear in the reference works that later scholars use to build reading lists. The bibliographic record gets thin, and once it gets thin enough, they become genuinely hard to find even if you\u0026rsquo;re looking.\nThis is a metadata problem as much as it is a cultural one. The Victorian Jewish writers I work with weren\u0026rsquo;t hidden exactly; their work was published, reviewed, and read in their own time. What happened was that the systems that organize literary knowledge, the indexes, the anthologies, the library catalogs, the reference databases, were built by people with particular assumptions about what mattered, and those assumptions had consequences that compounded over decades.\nRecovery work, the scholarly project of bringing marginalized writers back into critical view, is in part a project of rebuilding metadata. You\u0026rsquo;re not just arguing that a writer deserves attention. You\u0026rsquo;re creating the bibliographic infrastructure that makes attention possible.\nBuilding the thing The Victorian Jewish Writers Project involved the kinds of decisions that feel literary and curatorial on the surface but turn out to be deeply technical underneath. How do you handle a writer who published under multiple names, or whose name was anglicized differently in different sources? How do you represent a text that exists in a serialized newspaper version and a later collected edition that differs substantially from it? How do you describe work that sits at the intersection of multiple traditions, British, Jewish, immigrant, women\u0026rsquo;s writing, without flattening it into a single category that loses something important?\nThese are cataloging questions. They\u0026rsquo;re the same questions that library metadata professionals deal with in any complex collection, just with a particular set of historical and cultural stakes attached. The choices you make about how to describe something determine whether it\u0026rsquo;s findable, and by whom, and in what context.\nOn the technical side, building a usable public-facing archive means making decisions about platforms, schemas, and long-term sustainability that most literary scholars are not trained to think about. A project that lives on a faculty member\u0026rsquo;s departmental web hosting has a lifespan tied to that person\u0026rsquo;s institutional affiliation. A project built on a well-intentioned but unsupported custom CMS can become inaccessible within a decade as dependencies go unmaintained. The scholarly work and the infrastructure work have to be thought about together, or the archive doesn\u0026rsquo;t last.\nCultural heritage as an infrastructure problem Institutions that do this work seriously, libraries, archives, digital humanities centers, understand that cultural heritage projects are fundamentally infrastructure projects. The content matters, obviously. But what makes it durable and discoverable is the layer underneath: the metadata schema, the persistent identifiers, the hosting environment, the commitment to maintenance over time.\nThis is why the library systems side of my work and the scholarly side feel continuous to me rather than separate. When I\u0026rsquo;m debugging why a discovery layer isn\u0026rsquo;t surfacing a particular collection, or writing a Python script to normalize inconsistent metadata exports, or thinking about how IIIF can make digitized manuscript images interoperable across institutions, I\u0026rsquo;m doing a version of the same thing I was doing with the Victorian Jewish Writers Project: trying to make something findable that would otherwise get lost.\nThe writers I work on were neglected in part because the systems of literary culture weren\u0026rsquo;t built to hold them. Building better systems, more thoughtful metadata, more robust infrastructure, more sustainable platforms, is one of the ways you push back against that. It\u0026rsquo;s not the only way, and it doesn\u0026rsquo;t substitute for the critical and historical work of reading and interpreting. But without it, the recovery is fragile. You\u0026rsquo;ve argued for the writer\u0026rsquo;s importance, but you haven\u0026rsquo;t made them findable. And findability, as any librarian will tell you, is most of the battle.\nWhat gets kept Every archive involves choices about what gets kept and what doesn\u0026rsquo;t, and those choices are never purely neutral. They reflect the priorities, resources, and blind spots of the people and institutions doing the keeping. The VJWP is a small intervention in a large pattern, an attempt to make one corner of literary history more navigable than it was.\nBut the question it raises, who keeps the archive, and what systems do they use, and who do those systems serve, is one that applies well beyond Victorian literature. It applies to every collection that gets built, every catalog that gets maintained, every discovery layer that decides what to surface and what to bury on page twelve of the results. The infrastructure of cultural memory is not neutral, and the people who build and maintain it are making consequential choices whether or not they frame them that way.\n","permalink":"https://katzir.xyz/posts/vjwp/","summary":"\u003cp\u003eA few years ago I co-created a digital archive. \u003ca href=\"https://vjwp.org\"\u003eThe Victorian Jewish Writers Project\u003c/a\u003e began as a scholarly problem: nineteenth-century Jewish writers in Britain had been systematically excluded from the literary canon, their work scattered across out-of-print volumes, digitized newspaper runs, and institutional collections that had no particular reason to surface them together. The project was an attempt to do something about that, to gather, describe, and make discoverable a body of writing that existing finding tools were not built to find.\u003c/p\u003e","title":"Who keeps the archive? Cultural heritage, forgotten writers, and the infrastructure behind recovery "},{"content":"What Actually Happens When You Request an Article You\u0026rsquo;re deep in a research rabbit hole. You find a citation that looks perfect, click the link, and instead of the article you get a paywall or a dead end. So you click \u0026ldquo;Request via Interlibrary Loan,\u0026rdquo; fill out a form, and wait. A day or two later the PDF lands in your inbox. Magic, right?\nNot magic. Infrastructure.\nI want to walk through what actually happens in that window between your click and your PDF, because it involves half a dozen systems talking to each other in ways that are genuinely interesting and almost entirely invisible to the people who depend on them every day.\nThe Click Let\u0026rsquo;s say you\u0026rsquo;re in your library\u0026rsquo;s discovery layer, something like Primo or Summon. You\u0026rsquo;ve found a citation for an article your library doesn\u0026rsquo;t have full-text access to. The discovery layer knows this because it has already checked your institution\u0026rsquo;s knowledge base, a database of every journal your library licenses, and matched it against the metadata for this article. No match. So instead of a \u0026ldquo;Download PDF\u0026rdquo; button, you get a different option: request it.\nThat request button is typically an OpenURL link. It encodes the article\u0026rsquo;s metadata (journal title, volume, issue, pages, DOI, author, year) as a string of parameters in a URL and hands that off to a link resolver. The link resolver\u0026rsquo;s job is to take that metadata and figure out what to do with it. It checks your licenses one more time, looks for any open-access copies it knows about, and if it still comes up empty, routes you to an ILL request form, usually pre-populated with the metadata it already has.\nThis is the first place things can silently go wrong. If the OpenURL is malformed, if the knowledge base is out of date, or if the link resolver is misconfigured, you might get a form with missing fields, or get routed incorrectly, or just hit an error page. From the patron\u0026rsquo;s perspective it looks like the library is broken. From the systems side it\u0026rsquo;s usually a metadata problem.\nThe Request You submit the form. On the other end, a system like ILLiad receives it and creates a transaction record. ILLiad is the workhorse of resource sharing at most academic libraries: it tracks every request, manages communication with patrons and lending libraries, handles copyright compliance, and routes work to staff queues.\nFor an article request, ILLiad will typically try to fulfill it automatically before a human ever looks at it. It queries OCLC WorldCat to find libraries that own the journal and are willing to lend, ranks them by factors like geographic proximity, lending speed, and reciprocal borrowing relationships, and fires off a request to the first one on the list. If that library declines or doesn\u0026rsquo;t respond within a set window, ILLiad moves to the next one. This cycling through potential lenders is called \u0026ldquo;rota\u0026rdquo; processing, and it happens without any staff intervention.\nThis is where NCIP (NISO Circulation Interchange Protocol) sometimes enters the picture, a protocol that allows different library systems to talk to each other about item availability and transactions. It\u0026rsquo;s one of those standards that works well when everyone implements it the same way and causes subtle, maddening failures when they don\u0026rsquo;t.\nThe Lending Side The lending library receives the request, usually through OCLC\u0026rsquo;s resource sharing system or a direct ILL protocol. A staff member (or, at larger institutions, an automated workflow) locates the article, scans it or exports a PDF from their own licensed access, and uploads it back through the system. Copyright compliance gets checked here: the CONTU guidelines put limits on how many articles from a single journal issue a library can supply in a given period without triggering royalty payments, and most ILL systems track this automatically.\nThe article travels back through OCLC to your ILLiad instance, which receives it, marks the transaction as delivered, and triggers a notification to the patron. At many libraries this final step involves a small document delivery system that either emails the PDF directly or posts it to a secure patron portal with a time-limited download link.\nWhat Can Go Wrong Quite a lot, is the honest answer, and most of it is invisible to patrons.\nThe OpenURL metadata is wrong or incomplete, so the ILL form is pre-populated with bad data and the request goes out with the wrong volume number or year. The rota exhausts all willing lenders without finding a copy. The lending library has the journal but their licensed access doesn\u0026rsquo;t cover that particular year. A NCIP message gets malformed in transit and the transaction stalls silently in a queue somewhere. The PDF gets delivered but the patron notification email lands in spam.\nNone of these failures announce themselves loudly. They show up as slow requests, as staff noticing something stuck in a queue, or as a patron emailing to ask why they haven\u0026rsquo;t heard anything after four days. Triaging them means reading logs, checking transaction histories in ILLiad, and sometimes emailing a counterpart at another institution to ask what their system thinks is happening.\nWhy This Is Worth Understanding The whole chain I just described, from OpenURL to link resolver to ILLiad to OCLC to lending library and back, is mostly invisible not because it was designed to be opaque, but because it works often enough that nobody looks at it until it breaks. That\u0026rsquo;s what infrastructure does.\nBut the people who maintain it need to understand the whole pipeline, not just the piece they directly touch. A cataloger who understands OpenURL is better at diagnosing why certain requests fail. A systems administrator who understands the ILL workflow is better at configuring the link resolver. And an ILL staff member who understands what happens at the systems level can give patrons much better answers than \u0026ldquo;it\u0026rsquo;s still processing.\u0026rdquo;\nThe article that lands in your inbox is the product of about six different systems agreeing on something. When it doesn\u0026rsquo;t land, the reason is almost always in the handoffs.\n","permalink":"https://katzir.xyz/posts/article-requests/","summary":"\u003ch3 id=\"what-actually-happens-when-you-request-an-article\"\u003eWhat Actually Happens When You Request an Article\u003c/h3\u003e\n\u003cp\u003eYou\u0026rsquo;re deep in a research rabbit hole. You find a citation that looks perfect, click the link, and instead of the article you get a paywall or a dead end. So you click \u0026ldquo;Request via Interlibrary Loan,\u0026rdquo; fill out a form, and wait. A day or two later the PDF lands in your inbox. Magic, right?\u003c/p\u003e\n\u003cp\u003eNot magic. Infrastructure.\u003c/p\u003e\n\u003cp\u003eI want to walk through what actually happens in that window between your click and your PDF, because it involves half a dozen systems talking to each other in ways that are genuinely interesting and almost entirely invisible to the people who depend on them every day.\u003c/p\u003e","title":"What actually happens when you request an article"},{"content":"Sometimes sysadmin work can seem relatively thankless\u0026ndash;you can be three layers deep in a log file, tracing why a resource-sharing request silently failed at 2am, even while you realize that nobody noticed. That\u0026rsquo;s not because the service doesn\u0026rsquo;t matter, but because when infrastructure works, it\u0026rsquo;s invisible. When it breaks, it\u0026rsquo;s a crisis. Just as most of us don\u0026rsquo;t regularly think of the pipes carrying water in and out of home unless something goes awry, digital infrastructure is invisible to most people most of the time. To use a tired phrase, that\u0026rsquo;s a feature, not a bug.\nIf you think about it, libraries are infrastructure. Not metaphorically, bu tliterally. And I think the clearest way I\u0026rsquo;ve come to understand this is by spending my days in front of a terminal.\nWhat infrastructure actually means In computing, we distinguish between applications (the things users see and interact with) and infrastructure (the systems that make those applications possible). Your researchers search a discovery layer. What they don\u0026rsquo;t see is the Solr index humming behind it, the nightly API harvest pulling metadata from the ILS, the Python script normalizing MARC records that were last touched in 1987, the Go service brokering NCIP requests between your ILL system and a lending institution three states away.\nLibraries have always been infrastructure in this sense. The catalog, the stacks, the loan policies, the interlibrary networks: these are not amenities. They are the connective tissue of scholarship. A researcher who finds the article they need thinks about the idea in the article, not about the OpenURL resolver that routed them there, or the license negotiation that made full-text available, or the systems administrator who spent a Tuesday afternoon debugging why EZproxy was mangling authentication tokens.\nThat invisibility is the measure of success.\nThe epistemic CLI Working at the command line has made me a better thinker about libraries, and I want to try to explain why.\nWhen you interact with a system through a GUI, the interface makes decisions for you about what matters. Buttons appear, options are presented, and the underlying model is hidden beneath a surface designed to feel intuitive. This is not a criticism, since good UX is a genuine achievement. But it shapes how you think about the system. You learn the interface rather than the thing itself.\nThe CLI inverts this. When you ssh into a server, open a Python REPL, or pipe the output of one tool into another, you are forced to construct a mental model of what the system actually does. You learn that a \u0026ldquo;request\u0026rdquo; is a socket connection, that a \u0026ldquo;user\u0026rdquo; is an authenticated token, that \u0026ldquo;saving\u0026rdquo; is a write to a filesystem that may or may not be the filesystem you think it is.\nThis maps directly onto library work. Most patrons, and honestly many librarians, interact with the library through its interface: the search box, the catalog record, the request button. But if you want to understand why a discovery system surfaces irrelevant results, or why holdings data is wrong, or why a particular workflow breaks under load, you have to go deeper. You have to read the config, trace the log, and think like a systems person.\nPython, Go, and the craft of library automation One of the things I find most satisfying about this work is that it demands polyglot thinking. In a given week I might write a Python script to batch-process MARC data exported from the ILS, a small Go binary to handle a high-throughput webhook endpoint, and a Bash pipeline to reconcile two CSV exports that should match but don\u0026rsquo;t.\nEach language has a character suited to different problems. Python excels at the messy, humanistic work of data: manipulating bibliographic records, calling REST APIs, transforming one schema into another. It reads almost like prose, which suits the fundamentally textual nature of library metadata. Go rewards you for thinking about systems at a lower level, asking what a process is doing, how much memory it\u0026rsquo;s using, what happens under concurrent load. Writing Go for library infrastructure forces a kind of rigor that Python gently lets you defer.\nThis isn\u0026rsquo;t unlike the distinction between close reading and structural analysis in literary criticism, a parallel I find myself returning to more than I expected when I left the English department.\nWhy this blog I spent years as a literature professor before moving into library systems administration. People sometimes treat this as an odd career turn, but I\u0026rsquo;ve come to think it\u0026rsquo;s actually coherent: both fields are fundamentally about organizing knowledge and making it findable. The methods differ, and the stakes feel different day-to-day, but the core problem is the same. How do you help someone find what they need?\nThis blog is where I think through that problem in public. Expect posts about Linux, Python, Go, library systems like Alma and Primo, the occasional digression into the history of cataloging, and probably more than one post where I notice that a Victorian novelist anticipated a modern information architecture problem by about 150 years.\nInfrastructure doesn\u0026rsquo;t get written about enough. This is a small step toward remedying that.\n","permalink":"https://katzir.xyz/posts/intro/","summary":"\u003cp\u003eSometimes sysadmin work can seem relatively thankless\u0026ndash;you can be three layers deep in a log file, tracing why a resource-sharing request silently failed at 2am, even while you realize that \u003c!-- raw HTML omitted --\u003enobody noticed\u003c!-- raw HTML omitted --\u003e. That\u0026rsquo;s not because the service doesn\u0026rsquo;t matter, but because when infrastructure works, it\u0026rsquo;s invisible. When it breaks, it\u0026rsquo;s a crisis. Just as most of us don\u0026rsquo;t regularly think of the pipes carrying water in and out of home unless something goes awry, digital infrastructure is invisible to most people most of the time. To use a tired phrase, that\u0026rsquo;s a feature, not a bug.\u003c/p\u003e","title":"Library as Infrastructure"},{"content":"I\u0026rsquo;m a library systems administrator at an academic research library. Before that, I was a literature professor. People sometimes find that combination surprising, but the more time I spend in both worlds, the more coherent it seems: both are fundamentally about organizing knowledge and making it findable. The methods are just very different.\nOn the technical side, my work lives at the intersection of library systems (Alma, Primo, ILLiad), Linux infrastructure, and the scripting and tooling that holds it all together. I spend a lot of time in terminals, writing Python and Go, debugging integrations between systems that were never quite designed to talk to each other, and thinking about why library infrastructure is so chronically under-documented.\nThat last part is more or less why this blog exists. There\u0026rsquo;s good writing about library technology at the policy and trends level, and there\u0026rsquo;s good technical documentation for individual systems. What\u0026rsquo;s harder to find is practitioner-level writing that treats library infrastructure as a serious engineering problem while also caring about what it\u0026rsquo;s actually for. That\u0026rsquo;s the gap I\u0026rsquo;m trying to write into.\nExpect posts about resource sharing workflows, discovery systems, automation, Linux, Python, Go, the occasional deep dive into a protocol nobody talks about, and probably some detours into the history of cataloging or the nineteenth-century novel. The connections are more direct than they sound.\n","permalink":"https://katzir.xyz/about/","summary":"\u003cp\u003eI\u0026rsquo;m a library systems administrator at an academic research library. Before that, I was a literature professor. People sometimes find that combination surprising, but the more time I spend in both worlds, the more coherent it seems: both are fundamentally about organizing knowledge and making it findable. The methods are just very different.\u003c/p\u003e\n\u003cp\u003eOn the technical side, my work lives at the intersection of library systems (Alma, Primo, ILLiad), Linux infrastructure, and the scripting and tooling that holds it all together. I spend a lot of time in terminals, writing Python and Go, debugging integrations between systems that were never quite designed to talk to each other, and thinking about why library infrastructure is so chronically under-documented.\u003c/p\u003e","title":"About me"}]