Abstract
Two books can be equally finished and unequally public. Both may have undergone editorial work, design, production, and launch. Yet one can be correctly named, distinguished from a related edition, found through relevant catalogues or searches, connected to an available access route, and recognized by more than one organization. The other exists primarily where its publisher announces it. The difference is not necessarily merit, publicity budget, or reader demand. It is often the condition of the information that allows a work to be expressed, exchanged, transformed, indexed, and displayed beyond the publisher’s own environment.
This paper calls that condition the discoverability dependency chain. A publication’s identity, descriptive data, contributor information, classifications, rights or access terms, availability state, and relationships do not automatically travel intact from an editorial document to a reader-facing result. They have origins, owners, formats, transformations, receiving systems, update cycles, and failures. An identifier is indispensable but is not the whole record. A structured supply-chain message is not a public catalogue. A catalogue record is not necessarily an access route. A search result is not proof of current availability. Metadata becomes distribution infrastructure precisely because it moves—or fails to move—across those dependencies.
The paper follows the fictional title Saltwater Margins: A Field Guide to Estuary Stories through six handoffs. It then provides the Discoverability Dependency Trace, a field instrument that records a publication field, its authoritative source, its downstream recipient, its transformation, its visibility point, its failure signal, its correction owner, and its verification state. The instrument does not make data omnipotent. It helps a publisher, librarian, or editor locate where public existence becomes fragile—and distinguish a correctable record problem from the larger problems of attention, access, institutional power, and reader choice.
1. The book that cannot be named
Imagine two small-press books released in the same month. Both have a cover, an interior file, a credited author, and a careful announcement. A reader hears about the first book in a conversation. The reader can enter the title into a catalogue or search interface, distinguish a print version from a digital one, see who issued it, identify an appropriate subject route, and determine whether a local or remote access path exists. The reader may still decide not to read it. It may still be unavailable, unaffordable, unreviewed, or poorly suited to the reader’s need. But it has become a recognizable public object.
The second book is harder to handle. A title search returns an old announcement but no stable record. The author’s name is rendered differently in two places. A reader cannot tell whether a download is the work itself, a sample, or an unrelated version. A librarian has no dependable description from which to build a record. A bookseller or educator cannot determine what edition, format, subject, or availability state is being discussed. The book may be real, accomplished, and ethically produced. It is not yet reliably legible to the systems through which other people find, identify, select, and reach it.
The gap between a finished publication and a public object is frequently described as a problem of “metadata.” That label is accurate but too passive. It makes a live infrastructure appear like a form completed at the end of production. A better question is:
Which facts about this publication must survive which handoffs before a reader can recognize the right work and reach a relevant route to it?
This question separates four things that are routinely collapsed.
| Term | What it means in this paper | What it does not guarantee |
|---|---|---|
| Visibility | A trace of a publication can be seen somewhere. | That the trace is accurate, complete, current, or useful. |
| Discoverability | A user can retrieve a relevant, intelligible representation through a stated system or route. | That the user can access, afford, or choose the work. |
| Access | A reader has an actionable route to an appropriate copy, holding, purchase, loan, or permitted reading environment. | That the work is prominent, read, understood, or desired. |
| Attention | A work receives notice, interpretation, recommendation, or sustained readership. | That a record was exchanged correctly or that all readers had equal opportunity to encounter it. |
Metadata matters in all four, but it does not collapse them into one outcome. A dependable record can make a book more intelligible to the systems that receive it. It cannot create demand on command, erase unequal institutional coverage, make every result transparent, or replace editorial quality.
2. The discoverability dependency chain
The discoverability dependency chain is the linked sequence through which a publication’s identity, description, status, access terms, and relationships are created, communicated, transformed, indexed, omitted, and finally presented. It is a Wexley analytical construct, not a universal data model.
The chain begins before any standard message is sent. An editorial team may hold a working title, contributor names, a description, planned formats, a subject idea, a provisional date, a rights or access condition, and a cover asset. Those facts do not carry equal authority. A proposed subtitle and a finalized subtitle should not have the same status; a price planned for a season is not the same as a current availability statement; an author’s preferred name and a normalized name form may be related but do different work.
Crossref’s 2024 account of scholarly metadata offers a useful vocabulary for this division of labor: creators provide descriptive information, curators normalize and standardize it, custodians store and maintain it, and consumers use it to find, connect, or cite works.[1] The words matter because they interrupt a familiar fiction: that a publisher “has metadata” in a single place and then simply releases it. In practice, a field can be created by one role, verified by another, exchanged in a third system, mapped into a fourth, and made visible—or invisible—through a fifth.
EDItEUR defines ONIX for Books as an international XML-based standard for representing and communicating book-industry product information in electronic form.[2] The organization is explicit that ONIX is a way of communicating data between databases, not a database design in itself.[2] That distinction is central. A title-information sheet, a publisher’s internal record, an ONIX message, a distributor’s data store, a library’s bibliographic record, and a reader-facing display are related objects, but they are not identical objects. They can differ in field set, timing, vocabulary, authority, and presentation.
The dependency chain therefore asks seven questions before it asks whether a book is “discoverable”:
| Dependency | Operational question |
|---|---|
| Identity | Which exact publication or edition is being described? |
| Authority | Who can confirm that a field is current and correct? |
| Expression | In which structured record or message is the fact represented? |
| Handoff | Which recipient receives it, and when? |
| Transformation | Is the field normalized, mapped, selected, supplemented, delayed, replaced, or omitted? |
| Exposure | Where, if anywhere, can a reader or intermediary encounter the resulting representation? |
| Maintenance | Who notices a mismatch and who has standing to correct it? |
A dependency chain is not a linear conveyor belt. A record can move in parallel to several recipients; a recipient can retain an older version; an internal correction can fail to reach a public display; a library can supplement a publisher record; and a visible record can point to a route that no longer works. The chain is valuable because it identifies these differences without assuming that every problem is a publisher error.
3. An identifier is not the whole record
Identifiers are often mistaken for metadata completed. The error is understandable. A number can be stable, concise, machine-readable, and useful for ordering, listing, matching, reporting, and distinguishing versions. But a number does not by itself explain a book’s title, contributors, subject, relationship to another edition, availability, access condition, descriptive summary, or intended audience.
International ISBN Agency guidance makes both sides of the distinction visible. Publishers applying through an appropriate national ISBN agency must supply specified publication metadata—examples include title, author, and format—and the relevant metadata specifications are established through the International ISBN Agency and national agencies.[3] Its FAQ materials explain that the publication element identifies a particular edition and format of a specific title, and that separately identifiable formats or materially different user-experience versions may require distinct treatment in the ISBN system.[4]
The teaching point is not that every product difference generates a simple answer. It is that identity must be specific enough for a downstream actor to know what the reader is being offered. A hardback, a paperback, a digital edition, a revised edition, or a version with a materially different access condition may create a reader-relevant distinction. The identifier helps state the identity; accompanying description makes that identity intelligible.
The same International ISBN Agency FAQ warns against magical thinking. Obtaining an ISBN does not automatically place a book into every national catalogue or search environment; further steps may be necessary for listing in particular contexts.[4] This limitation is productive. It turns the question from “Do we have a number?” to “Which record receives the number with enough associated information to make the correct version visible in a specified route?”
A useful field distinction follows.
| Field family | Illustrative question | Why an identifier alone does not settle it |
|---|---|---|
| Identity | Which edition or format is this? | It can identify the version, but not describe it fully to a human reader. |
| Description | What is the work about, and how is it presented? | A number has no synopsis, subject language, or table of relationships. |
| Contribution | Who wrote, translated, edited, illustrated, or otherwise contributed? | A number does not clarify roles or name forms. |
| Classification | Through which subjects or categories might it be retrieved? | An identifier is not a subject route. |
| Availability / access | Can a reader obtain or reach this version now, and under what condition? | Identity does not confirm a live route or current status. |
| Relationship / provenance | Is this a revision, related format, series item, successor, or version of record? | A number alone cannot explain the relation. |
4. The record as a handoff, not a database
A structured exchange record carries information because other systems can process an agreed form. EDItEUR explains that ONIX releases specify the content of a standard message and provide associated schemas that can support validation.[2] Its account also identifies controlled vocabularies as part of the shared semantics of an ONIX message and describes complete records, replacement records, and granular update approaches.[2] These are not merely technical details. They show why a supply-chain record has time as well as content: a description can be current, superseded, incomplete, or incorrectly mapped.
Consider the fictional title used in this paper:
Saltwater Margins: A Field Guide to Estuary Stories, by Mira Vale, issued by the fictional Lantern Bend Press.
The title begins as a set of editorial facts. It may have planned print and digital formats, a finalized contributor statement, a series relationship, a synopsis, classifications, an access statement, a cover, and a publication state. The author and press are invented; the case models no actual company’s process. It asks only what must happen for a reader eventually to distinguish the correct version and reach the appropriate path.
The following six-handoff anatomy keeps the answer observable.
| Handoff | What moves | What may change | What a failure looks like |
|---|---|---|---|
| 1. Editorial title-information sheet | Working/final title, contributors, description, planned formats, subjects, release state. | Draft facts become approved facts; internal terms may be normalized. | The subtitle or contributor order differs across internal sources. |
| 2. Identity / registration record | Edition/format identity and minimum associated bibliographic information. | A specific version becomes distinguishable in the identifier system. | A reader-relevant format distinction cannot be reliably named. |
| 3. Authoritative publisher product record | Structured product fields, relationships, status, and approved assets. | An internal source becomes a record intended for exchange. | An old availability or edition statement remains after a state change. |
| 4. Distribution / aggregation feed | Exchanged record or recipient-specific transformation. | Fields may be selected, mapped, validated, delayed, or omitted. | A classification, cover, or access term does not reach a recipient as intended. |
| 5. Library / cataloguing transformation | Receiving bibliographic record, subject/relationship treatment, holding or access representation. | Record structure and cataloguing practice change what is retained or supplemented. | The book is described but has no usable local access or subject route. |
| 6. Discovery / reader-facing result | Indexed and configured presentation plus possible resolver/knowledge-base connection. | System configuration determines exposed fields, filters, links, and display. | A search result shows the wrong edition, stale state, incomplete record, or failed route. |
This is not an assertion that every press uses precisely six systems. It is an analytical map. Its main insight is that a book’s public representation is distributed. An update in handoff 3 may not be visible in handoff 6 if the later systems retain, transform, or schedule updates differently.
5. Library discovery makes the middle visible
Library workflows make the middle of the chain unusually legible because their record architectures and access mechanisms are explicit. The Library of Congress’s current MARC 21 bibliographic format enumerates distinct families for title-related data, edition and imprint information, physical description, notes, subject access, added entries, linking entries, holdings or location, local data elements, and provenance subfields.[5] A library record is thus visibly more than a title plus identifier. It is a structured representation that can organize several relationships and access conditions.
A Penn State University Libraries account of Open Access book metadata illustrates one possible transformation path: publisher ONIX data is transformed into MARC for library use, and MARC records are loaded into discovery systems to facilitate search and retrieval.[6] The source concerns OA books and libraries, so it cannot stand in for every trade-book pathway. It does, however, demonstrate the analytical point: a source record can be useful in one ecosystem only after it is translated into a record form another ecosystem can receive.
The 2013 Insights article “How libraries use publisher metadata” extends the view of that middle territory through academic-library and electronic-resource examples. It describes MARC-based catalogues, OpenURL link resolvers, and library discovery systems as distinct environments that can rely on publisher-supplied metadata. Its University of Washington examples describe record-set loads, conversion of non-MARC metadata, pre-indexed discovery rather than live searching, and source-to-target resolution.[7] It also names ordinary but consequential failure families: incorrect identifiers, incomplete fields, mismatched resource genre, and metadata that does not accurately reflect the described resource.[7]
These examples reveal why “the book is in the catalogue” is not the end of a diagnosis. A discovery system may use a pre-indexed set of descriptive data and a link resolver or knowledge base to translate a search result into an access route.[7] Crossref similarly describes discovery systems through a user interface, metadata index, and link resolver or knowledge base, while noting that providers and systems can select or manipulate data elements during integration and that changes are not always communicated to all parties.[1]
The word middle matters. Publishers may know their own source record. Readers may see a result. Between them are transformations, configurations, update rhythms, and institutional policies. The work of the Discoverability Dependency Trace is to make that middle diagnosable.
6. Teaching instrument: the Discoverability Dependency Trace
A trace begins with a reader task, not with a generic demand for richer metadata. For example: “A reader needs to tell whether the result is the digital edition of Saltwater Margins, identify whether it can be reached through a stated route, and distinguish it from the print edition.” The trace then follows the particular fields required for that task.
| Trace field | Prompt | Example entry for the fictional title |
|---|---|---|
| Publication field | What exact identity, description, contributor, classification, access, availability, or relationship field is at issue? | “Digital-edition label and access statement.” |
| Authoritative source | Who confirms it at origin? | “Lantern Bend Press product-record owner after editorial approval.” |
| Downstream recipient | Which recipient or process receives it? | “An unnamed distributor feed; a receiving library record workflow; a discovery index.” |
| Transformation / rule | Is the field mapped, selected, normalized, delayed, or omitted? | “Digital-edition wording is normalized for a receiving record; availability update is scheduled separately.” |
| Visibility point | Where would someone encounter the outcome? | “A reader-facing discovery result and its detailed record view.” |
| Failure signal | What observable mismatch suggests a break? | “The result identifies only the print form or presents an old access status.” |
| Correction owner | Who can change the source or configuration? | “Publisher for the originating field; recipient or library configuration owner for local display.” |
| Last verified / escalation | When was the path checked, and who must be contacted if the break is outside local control? | “Verification date recorded; recipient follow-up required if a correct feed is not reflected.” |
The Trace has one discipline: it does not allow a reviewer to say simply, “metadata is wrong.” That phrase conceals the action needed. Is the source field wrong? Is the source right but unsent? Was it sent but not transformed? Was it transformed but not indexed? Was it indexed but filtered from display? Is the result accurate but lacking a route to the relevant copy? Does the correction belong to the publisher, a data recipient, a library configuration owner, or a specialist workflow?
The instrument also avoids the opposite error: assuming the publisher controls every public representation. A recipient may select fields according to its system requirements. Crossref’s account notes that different recipients can need different fields and formats and that delivery frequencies vary.[1] A trace makes the boundary visible. It identifies a correction owner without claiming that the owner must grant a request or that a system will expose a desired field.
7. The conditions metadata cannot solve
A dependency chain is not a demand machine. It can reveal that a meaningful field is absent, stale, mismapped, or trapped behind a governance boundary. It cannot on its own decide what readers value, compel a third party to change an opaque system, or compensate for unequal access to cultural attention.
The International ISBN Agency’s warning about non-automatic listing provides the first limit: identity is necessary in many systems but does not itself complete international discovery.[4] Crossref’s lifecycle account provides a second: even careful publishers work with changing standards, recipient requirements, integration choices, and maintenance burdens. It explicitly notes that direct effects of richer metadata on revenue or discoverability can be difficult to quantify because other factors are involved.[1]
A third limit concerns power and reuse. In a coalition policy statement, the International Coalition of Library Consortia argues that restrictions on the use, adaptation, aggregation, and sharing of bibliographic metadata can constrain libraries’ ability to collaborate and innovate; it treats this as a public-interest and library-mission issue.[8] This is a policy position, not a legal finding. Its importance here is conceptual: the ease with which a record moves is partly governed by rights, contracts, market concentration, organizational capacity, and systems that a small publisher or individual librarian may not control.
Good metadata is therefore neither cosmetic nor sovereign. It is a condition of legible handoff. It can reduce ambiguity, make updates more traceable, support appropriate matching, and give recipients better material with which to build records or routes. It cannot promise equal treatment in all discovery infrastructures, eliminate exclusion, replace trusted recommendation, or guarantee that a relevant reader will encounter a title.
8. A repair-ownership decision rule
When a publication seems absent or misrepresented, begin with a bounded sequence rather than with a campaign for “better metadata.”
Name the reader task; name the necessary field; locate the field’s authoritative source; identify the last successful handoff; and assign the next correction or escalation to the party able to act.
This rule produces questions that can be answered. If readers cannot distinguish editions, is the identity or edition field clear at origin? If a title search works but an access route fails, is the problem in the record, the resolver or knowledge base, the access target, or a local configuration? If an old description persists, when did the authoritative record change, which recipient should have received the update, and has the public result been checked? If a record is accurate but invisible in a particular environment, is the missing step a field, a feed, an index, a configuration, a licensing condition, or a recipient policy?
The final action can be modest: correct the authoritative source, document the sent update, identify a recipient’s support path, record that an external configuration is outside local control, or state that a particular discoverability route cannot be verified. The value of the Trace is not that it guarantees repair. It prevents the false confidence of a finished book that cannot yet be recognized beyond its birthplace.
Boundary statement
This paper does not provide retailer-specific optimization, a platform ranking, SEO or sales promises, investment advice, legal counsel on identifiers or rights, or a guarantee of library, retail, search, or reader inclusion. It teaches a traceable model of identity, handoff, transformation, visibility, and corrective ownership. Metadata is distribution infrastructure because it carries a publication’s public description across systems—but it becomes useful only when its dependencies, limits, and custodians are named.
References
[1] Crossref, “Metadata beyond discoverability” (2024)
[2] EDItEUR, “Overview: ONIX for Books Product Information Format”
[3] International ISBN Agency, “How to get an ISBN”
[4] International ISBN Agency, “ISBN FAQs,” 7th-edition Users’ Manual companion
[5] Library of Congress, MARC 21 Format for Bibliographic Data
[6] Jeffrey Edmunds, “Open Metadata and Libraries,” Open Access Books Network / Penn State University Libraries (2023)
[7] “How libraries use publisher metadata,” Insights (2013)
[8] International Coalition of Library Consortia, “Statement on the Metadata Rights of Libraries” (2022–23)