Book Event Specification

[Anderson-Juhasc]

Summary

This proposal defines a new event kind for Nostr to represent and share book metadata. It aims to provide a standardized format for storing and transmitting information about books within the Nostr network.

Kind: XXXX

Event Structure

The event structure follows the standard Nostr event format, customized for books using tags to store metadata.

{
  "id": "<event_id>",
  "pubkey": "<author_pubkey>",
  "created_at": <unix_timestamp>,
  "kind": XXXX,
  "tags": [
    ["title", "<book_title>"],
    ["author", "<book_author>"],
    ["edition", "<edition_information>"],
    ["license", "<license_information_or_url>"],
    ["isbn", "<isbn_number>"],
    ["asin", "<amazon_standard_identification_number>"],
    ["doi", "<digital_object_identifier>"],
    ["genre", "<book_genre>"],
    ["publisher", "<book_publisher>"],
    ["published_date", "<yyyy-mm-dd>"],
    ["language", "<book_language>"],
    ["translator", "<translator_name>"],
    ["publisher_location", "<city_country>"],
    ["accessibility_features", "<list_of_features>"],
    ["cover_url", "<url_of_cover_image>"],
    ["tags", "<comma_separated_tags>"],
    ["rating", "<average_rating>"],
    ["format", "<format_type>"],
    ["pages", "<number_of_pages>"],
    ["pdf_link", "<url_to_pdf>"],
    ["torrent", "<magnet_link_for_torrent>"],
    ["content_warning", "<content_warning_description>"],
    ["e", "<related_event_id>", "book", "<relationship_description>"]
  ],
  "content": "<description_or_additional_content>",
  "sig": "<signature>"
}

Tag Descriptions

• title - The title of the book.
• author - The name(s) of the author(s).
• edition - Information about the specific edition of the book, e.g., "2nd Edition," "Revised Edition.".
• license - Useful for books that have specific licensing terms (e.g., Creative Commons).
• isbn - The International Standard Book Number, if applicable.
• asin - For books available on Amazon, adding an ASIN tag might be useful.
• doi - Useful for academic or research publications.
• genre - The genre(s) or category of the book.
• publisher - The name of the book's publisher.
• published_date - The original publication date in YYYY-MM-DD format.
• language - The primary language of the book (e.g., "en" for English).
• translator - Useful for translated works.
• publisher_location - Useful for geographical context or localization information.
• accessibility_features - To denote if the book has features such as audio versions, large text, etc., for accessibility purposes.
• cover_url - URL pointing to the book's cover image.
• tags - User-defined tags related to the book, for easier categorization.
• rating - An average rating (e.g., based on user reviews or a set scale).
• format - Specifies the format, such as "hardcover," "paperback," "ebook," etc.
• pages - Total number of pages, if applicable.
• pdf_link - Direct URL to a PDF version of the book, if available.
• torrent - Magnet link for torrenting the book, if applicable.
• content_warning - Could be used for mature content or books that may require disclaimers.
• related_event_id - Use e tag to reference related events (e.g., editions, author events, reviews, etc.).

[fiatjaf]

@SilberWitch

[SilberWitch]

What does this acomplish that 30040 doesn't do?

[fiatjaf]

What are the differences?

[SilberWitch]

This doesn't include the links to the events containing the actual book. It's just the metadata.

Like a catalog card, maybe.

[Anderson-Juhasc]

@SilberWitch with which tags I could use these events? I tried to generate an example of kind 30040 and it's very similar with the event that I wrote.

[SilberWitch]

We only defined the mandatory tags and suggested some optional ones. You can always add more tags.

[RydalWater]

So when I started working on my book app I thought about this similar problem, however, I decided that putting all the book metadata into nostr events didn't provide a massive amount of value. The good thing about books is they come with a universal identifier already. In the end I opted to just use that with the already well defined i tag (see NIP73) and then pull the data that is needed about the book from a central open database (for me OpenLibrary) that way you leverage all the opensource work that they are doing at the internet archive without needing for duplication.

When looking at your proposal though consider really drilling down and removing anything not essential and maybe re-use a bunch of existing recognized tags instead of creating new ones if possible.

For the reviews I would remove that completely. It makes no sense for the review to live with the book metadata when it can be a free floating object in its own right that can either reference another event or an i tag. Reviews that can be pulled alone provide much more universal value I think, as many clients could use them to build a WoT of book reviews.

If you're interested in the structure of the events I've built, and intend on building check out my OpenLibrarian on Github

[SilberWitch]

We have similarly "outsourced" most metadata (only title is mandatory), but we're planning on including that in labels, or measuring it by the way people interact with the event. I'm okay with the person creating the event using as many optional tags, as they like. We can just ignore them. Our event is also not only for books, but for any collection of documents, and they won't all have an ISBN. Even some books, don't have an ISBN, after all.

Even if I were to pull from an external database, I'd prefer to save in a label or my own database because I don't know how stable that database source will be. They keep shutting down such systems, or taking them private. That's a big problem with academic journals, especially.

[RydalWater]

You're [@SilberWitch] absolutely correct it is all down to use cases and what problem is attempting to be solved. In terms of "outsourcing" you raise a good point about stability, I'm thinking about this problem myself and will likely solve it with a mixture of a few things. Alternative API endpoints and as you say running my own DB to support the APIs, open library make a monthly data dump which I'll probably use to support my app for stability long term.

I'd push back a little on the idea of not trying to use other opensource projects when they exist for fear that they go private etc. It is true this is a risk but the OS ecosystem grows through co-operation and adoption. If we don't make use of the resources people put out there then they are more likely to go away in future. Better that we can cross pollinate if it is possible. You raise very valid arguments though particularly in the academic journal space.

To go back to the purpose for the book specification as @SilberWitch states folks are free to add a bunch of optional variables however they want and clients can ignore them as needed. Ideally, though for the purposes of creating a specification it would be good to reduce these data down to essential data that provides value to the Nostr network.

We're not going to get away from having to look outside of Nostr to pull data in because; 1. you cannot expect a user to enter all the details each time (either from a UX PoV or from an accuracy standpoint) and, 2. unless we were to build a massive repository of books on Nostr, these events will only be able to provide information on something within the network already, this makes Nostr native book discoverability difficult.

[SilberWitch]

Book metadata DBs are probably more stable than journals, since books are usually printed for public consumption.

I also like the idea of doing a monthly pull, to storage, to at least have a fallback, in case they rug. That's a good compromise.

[SilberWitch]

We actually are planning on building a massive repository of (out of copyright) books. Like Project Gutenberg, but with events.

We originally didn't even list metadata tags, beyond title and author, but people really like tags.

[RydalWater]

We actually are planning on building a massive repository of (out of copyright) books. Like Project Gutenberg, but with events.

We originally didn't even list metadata tags, beyond title and author, but people really like tags.

Keep me in the loop on this, be very interested in helping any way I can.

[Anderson-Juhasc]

Well, I think we just need to use kind 30040 for this case, don't need to create specified kind for books because this kind could be very generic.