In Which A Book Lexicon is Born

[nickthesick]

@xardex.dev

I chose to build Dracome’s lexicons around a WorkTarget (bag of identifiers) and a CatalogSnapshot. I don’t publish Dracome’s entire catalog, because this would be way too much data. But all logged progress, every state, review, marker is tied to a snapshot that is refreshed on save.

I can’t really tell what you mean by this exactly from this description alone. Would you mind explaining further?

@xardex.dev

A bag of identifiers is one way to solve this, because in Dracome’s case, it includes ISBNs, Open Library keys, Wikidata keys etc. The snapshot itself is a way to make sense of these keys without having to do lookups, and to ensure a record still makes sense if there aren’t any external keys.

Sure, but how does BookHive, or another app contribute to this bag of identifiers? Where does the identifiers live?

You might be able to do this with BookHive given my dataset is public, but another application which is not, will be impossible to do.

@xardex.dev

I’ll enrich those datasets with HiveIds as well, so it’s easier to connect them to BookHive. Though, I’ll have to build some matching logic for that.

This will be very hard, I would even say firmly, it should not be done. There will always be mismatches between datasets, and it will be an MxN problem. Exponentially hard when you account for other providers’ datasets.

I think that the local optimum solution here is for the user to have the power to make this mapping on their own case-by-case basis. Like, for example, given a book record in their PDS like:

title: "ABC", authors: ["XYZ"], identifiers: [{ type: 'hiveId', src: 'bookhive.buzz', id: 'h_123'}]
And an XRPC method, implemented across services, to search for books like:
id: 'community.book.search', type: 'query', params: { q: { type: 'string' }, output: { title: string, authors: string[], cover: string, identifiers: [{type: string, id: string}] } }

then each application would be able to make a book matching UI for migrating books across services (if multiple services implement the same XRPC method shape). While also giving the user agency in 1) how to map that book (since the record may not be valid in one dataset or inaccurate in another) 2) freedom for independent services for migrating between accounts (similar to those spotify < - > apple music migrators).
This would move the burden of mapping between datasets on the user & if an application wanted to have a more friction-free experience it is up to them to implement that if they so choose to. Applications can even build up datasets of previously mapped books to offer as suggestions.

@xardex.dev

I initially thought about solving this as translations, but that’s is too limiting. One may love a book in English but despise its translation. So a simple translation model may be bad UX. If there are multiple translations in the same language, this becomes even worse. Maybe a new translation is great; only the original one is despised.

I can’t speak to how often such a thing would happen, but given the complexity of this as is, I’d lean towards reducing scope than trying to account for every situation. But, “to each, their own”.