Why Your Book Data Should Be Portable

Your book data should be portable because a reading history is more than a list of titles. It can hold years of decisions, notes, ratings, dates, formats, edition details, lending context, and the record of what you meant to read next. You should be able to keep a usable copy of that history even if an app changes, a format evolves, or you decide to move on.

But “portable” does not mean “every export is a complete backup.” A download can be readable without being re-importable. A file can be structured without preserving every field. And a legal data-portability right, where one applies, is not a universal promise that every book record must be delivered in every format. The useful goal is simpler: know what you can take with you, what will be lost, and how to check the copy before you need it.

Five related ideas with five different jobs

These terms are often used as if they were interchangeable. They are not.

The distinction is practical. NIST describes cloud portability as moving data from one system to another and running applications elsewhere at an acceptable cost; it also points to common formats and protocols as conditions for interoperability. A personal book tracker is smaller than a cloud platform, but the same logic applies. A CSV download demonstrates exportability. It becomes more portable when another tool can understand the columns, preserve the values, and avoid duplicating or silently changing your records.

CSV itself is not a magic interoperability standard. RFC 4180 documents a common format and the text/csv media type, while also noting that CSV implementations vary. Two files can both be called CSV and still disagree about dates, separators, multiple values, identifiers, or what a column means.

What should be portable?

For a book record, portability is not just title, author, and ISBN. Those are useful anchors, but a personal library usually also contains:

• status and queue position;
• format, edition, narrator, and other publication details;
• start and finish dates;
• ratings and notes;
• tags, location, condition, and purchase details;
• lending or borrowing context; and
• a stable identifier for the row or copy, so two copies of one ISBN do not collapse into one.

Not every person needs every field. The point is to identify the details you would regret reconstructing from memory. A responsible export should make those fields visible, describe their types and date conventions, and preserve empty values distinctly from values that were never part of the system.

That is where backups and portability meet. NIST storage guidance emphasizes copies and restore testing. For a personal library: keep two independent copies in separate places, open them, and test a small reconstruction.

What lock-in looks like in a reading app

Lock-in is not only a dramatic shutdown. It can be the slow accumulation of friction:

• your notes are trapped in a visual page with no structured export;
• your dates or ratings are exported in a way another tool cannot interpret;
• multiple copies share a title but have no stable identity;
• an import creates duplicates instead of restoring the original rows; or
• the app’s metadata and your personal annotations cannot be separated.

An app can offer exports and still leave lock-in if the files are incomplete or difficult to use. A simple HTML archive can still be valuable without being a migration file. Portability is a spectrum of practical effort.

What Nook & Spine exports today

Nook & Spine currently offers CSV, HTML, and a button labeled PDF from the Settings page. Each serves a different purpose.

CSV: the closest thing to a migration file

The current library CSV includes title, author, ISBN, status, formats, format-detail JSON, edition type and label, content and narrator ratings, narrators, start and finish dates, notes, collector status, TBR position, page count, publisher, and publication date. That is substantially more useful for moving a library than a screenshot or a list of titles.

It is not a complete account backup. The current export omits the library-entry identifier, cover and description, much book metadata, purchase details, tags, location, condition, lending/borrowing fields, recommendation source, wishlist priority, and timestamps. Wishlist data has a separate export route; the library CSV is not a combined account archive.

Dates are also formatted for people to read rather than emitted as a stable machine-readable timestamp. That is friendly for a spreadsheet, but it can create ambiguity across systems and locales.

HTML: a browsable snapshot

The HTML export groups entries into Currently Reading, TBR, Completed, and Did Not Finish. Each entry shows the title, author, formats, content-rating stars, and ISBN, with a cover image when the stored URL is an allowed HTTP or HTTPS address.

That makes HTML useful for browsing or sharing. It omits notes, dates, editions, narrator information, tags, location, condition, purchase/lending context, and most metadata. Covers refer to external URLs, so the file is not necessarily self-contained offline, and it is not designed for re-import.

PDF: currently a print-to-PDF workflow

The Settings button says PDF, but the current /api/export/pdf implementation returns print-optimized HTML. The page tells you to use your browser’s Print command and choose Save as PDF; its response is labeled text/html and is downloaded with an .html filename.

The resulting print view is a human-readable snapshot: status sections, a title/author/format/rating/ISBN table, and summary statistics. It does not preserve migration fields or support re-import. “Print-ready export” is more precise than “complete PDF backup.”

Is the CSV a round trip?

No—not today. The importer recognizes many general and BookBuddy-style columns, including title, author, ISBN, status, formats, format details, edition fields, ratings, notes, pages, several metadata fields, tags, location, condition, purchase details, and lending details. But it does not map every column that the current library exporter emits. In particular, narrator rating, narrators, start date, finish date, TBR position, and several identity or timestamp fields are not restored from the export schema.

More importantly, importing the same CSV creates new library-entry rows rather than restoring by stable entry ID. TBR entries receive new queue positions, and ISBN records may be enriched from external metadata services. A re-import can duplicate entries and alter metadata.

Treat the CSV as a useful migration starting point and a structured reference—not as a tested restore image. If you want to experiment, use a small sample or a separate test library. Do not re-import a full export into your active library casually.

Export is not account deletion

An export is a copy. Deletion is an action on the source account. Downloading a file does not remove the original record, and deleting a record does not automatically create a usable archive.

Some laws address data access or portability in specific circumstances. For example, Article 20 of the EU General Data Protection Regulation describes a right to receive certain personal data provided by a data subject in a structured, commonly used, machine-readable format and to transmit it in qualifying processing situations. California’s Civil Code section 1798.130 also contains jurisdiction-specific request and format provisions. These rules have conditions, exceptions, scope limits, and procedures. They do not mean that every reader, every book fact, or every app interaction carries a statutory portability right. This article is educational product and trust content, not legal advice.

A practical portability routine

Use this small checklist whenever your library changes enough that losing it would hurt.

1. Capture. Download the CSV for structured reference. Save the HTML for browsing. Use the print workflow if a human-readable PDF is useful to you.
2. Check. Open each file. Compare the entry count with the app. Inspect a few records with notes, multiple formats, an edition label, dates, and a TBR position. Confirm that commas, line breaks, and special characters survived.
3. Copy. Keep at least two independent copies in separate places, such as a local drive and a cloud or offline copy you control. Exports from reading products may contain sensitive notes or collection details. In the current Nook & Spine library CSV, Notes are included while purchase, location, condition, lending, and borrowing fields are omitted; handle any downloaded file as sensitive personal material. Do not assume the app has made a security or encryption guarantee for your downloaded copy.
4. Rehearse. Open the CSV in a spreadsheet or test importer. If you need a future migration, map the columns and record what does not carry over. A small test tells you more than the existence of a download button.
5. Repeat. Choose a cadence that matches how often your library changes and how much reconstruction you could tolerate: after a major cataloging session, monthly, quarterly, or another interval you will actually follow.

The Library of Congress gives similar advice: organize files, keep copies in separate places, and plan to move them as technology changes. You do not need an elaborate archive; you need more than one copy and enough testing to know what each contains.

The standard to aim for

Good portability is not a promise that every future app will import every field perfectly. It is a transparent handoff. You should be able to answer:

• What fields are included?
• Which values are human-readable versus machine-readable?
• What is the row or copy identifier?
• Can another tool distinguish two copies of the same ISBN?
• What does the importer preserve, ignore, enrich, or duplicate?
• Can I open the files without the original dashboard?

Nook & Spine gives you three different ways to keep a copy outside the dashboard, with CSV as the strongest current foundation for structured work. The honest next step is to pair that export with your own independent copies and a quick test. That is how an export becomes part of a portable reading life.

Keep your library portable

If you want a reading tracker that treats your library as data you should be able to take with you, you can keep your library portable. Export it, inspect it, and keep the copy where you can use it.

Sources and further reading

• European Parliament and Council, Regulation (EU) 2016/679 (General Data Protection Regulation), 2016, Article 20 and Recital 68 — primary legal source for the conditional EU data-portability right and the distinction between portability and erasure.
• California Legislative Information, California Civil Code § 1798.130, current text — jurisdiction-specific example of request procedures and a readily usable, structured, machine-readable format requirement.
• National Institute of Standards and Technology (NIST), NIST Cloud Computing Standards Roadmap, Special Publication 500-291 Revision 2, 2013, DOI 10.6028/NIST.SP.500-291r2 — official interoperability and portability definitions and the role of common formats and protocols; cloud-focused, so the book-tracker application is an analogy.
• National Institute of Standards and Technology (NIST), Security Guidelines for Storage Infrastructure, Special Publication 800-209, 2020, DOI 10.6028/NIST.SP.800-209 — official guidance on copies, locations, restore procedures, and testing recoverability; adapted here for personal-library use.
• Library of Congress, “Personal Digital Archiving” and “Reformatting,” Preservation Directorate — practical preservation guidance on keeping independent copies in separate locations and planning for future format changes.
• RFC Editor, RFC 4180, “Common Format and MIME Type for Comma-Separated Values (CSV) Files,” 2005 — documents common CSV conventions while explaining that implementations vary; informational rather than a universal CSV schema.
• WHATWG, HTML Living Standard, “text/html,” living standard — background on HTML labeling and browser-oriented interchange; it does not make an HTML export a structured library backup.
• Nook & Spine, public homepage — first-party product context for the current CSV, PDF, and HTML export promise; implementation details should be rechecked before publication.
• Nook & Spine, public privacy policy — first-party context for the kinds of library, notes, tags, and account data the service describes; it is not a promise of export completeness or a substitute for the product audit.