This is a follow up thread of what folks are thinking around reviews for books (and what could be general reviews in the Atmosphere). Some points to view include:
I’m also curious about how we can consider NeoDoc from @al9000.com as mentioned in their comment: In Which A Book Lexicon is Born - #15 by al9000.com
I’m in for the working group. wish I could help you out with the co-chair, but that’s out of scope for me.
Expanding on notes from the other thread:
Using this approach to help with gating a review as a spoiler is a great idea and allows for optional hydration of a review when showing it to a user.
I also have some ongoing work on a proposal for a common rating lexicon. Will share when its more developed.
see below - didn’t know about lack of deletion on here, heh
You’re effectively in! It’s pretty open (self-electing). I’m eager to get us to a shape of (first) what would a review look like (eager to see why @tynanpurdy.com has cooking) as well as thoughts from @nickthesick and @adamfortuna who have developed active solutions for the such.
I’ve proposed a review lexicon in Part 2 of my Road to a book lexicon series: Road to a book lexicon (Part 2) - Nick The Sick - pckt
Back after a couple of weeks away and there’s a lot to catch up on (apologies as this will be the norm for me - work and training). Nick, Parts 1 and 2 are the clearest anyone’s framed this. Jacky, thanks for putting five concrete records up.
Three things I had wrong in pub.byline.*, since it seems fair to lead with those.
seriesPosition needs to be a string. “1.5” and “Vol. II” both happen and my integer can’t hold either.
Contributor identifiers beat a bare DID. That’s guido’s point in the other thread and Nick’s too. Most authors will never have a DID and the ones who do shouldn’t be a separate path.
And Jacky’s publishedYear as a plain integer is better than my format: datetime. Publication dates are years. Nick’s ISO 8601 has the same problem mine does, we both over-spec’d something that’s usually four digits.
byline’s lexicon isn’t heavily used and I’m not attached to it. If a better rationale comes out of this thread I’ll change byline to match rather than defend whatever I happened to ship first.
Now the bit I got stuck on reading both proposals back to back.
I think there are two identifier shapes on the table that can’t both work, and I want to check I’m reading them right.
Jacky’s is {uri, resource}, where uri is a vendor URL or a URN. Nick’s is {type, value, url?}, where value is the raw identifier in canonical form and matching is exact string equality on (type, value).
That equality rule only works because value is canonicalized, hyphenless ISBN-13, which ISBN-10 converts to losslessly. I don’t think {uri, resource} can support it. The searchEditions example in Jacky’s post shows one book with three id params: a URN and two vendor URLs that don’t seem to align. Compare those as strings and you’ve got three books. Compare them any other way and you’re back to per-AppView normalization, which is what the quote from Nick in that same post says we shouldn’t be doing.
So I’d take {type, value, url} forward, with a required canonical form per type, and url kept for display and human disambiguation but out of the matching path entirely.
Jacky, am I missing something about how uri was meant to normalize? You may have had a resolution step in mind that I’ve skipped past.
The other place the two point in opposite directions is contributors as separate records joined by strongRef versus denormalized inline. Nick’s “the PDS is not a database” and Jacky’s contributor and publisher records can’t both be right, and I don’t think anyone’s picked.
For what it’s worth I don’t think it has to be either/or. pub.byline.defs#seriesMembership carries a strongRef and a denormalized name, so the record renders standalone and the ref is pure enrichment. If the target vanishes you lose depth of the record, not meaning. Editions could carry inline contributors for the day-after test and still point at richer contributor records where an AppView has them. Costs you a duplicated string.
Last thing, and this is support rather than argument. community.lexicon.book.compatibility is the best idea in Jacky’s post and I haven’t seen anyone pick it up. Progressive discovery beats probing endpoints and eating 501s, and it’s what lets a partial implementer join in honestly instead of claiming a surface it doesn’t have. I’d keep it mandatory as proposed.
Enjoying these threads. I want to stay involved in it, though my schedule’s unreliable and I’ve already dropped out once for two weeks. Don’t wait on me, carry on and I’ll catch up where I can and voice what I can.
I’ve got a longer argument about the supply side of this, authors rather than catalogues, but it’s a slightly different conversation and this is long enough already. I’ll try to pull it together and post later tonight.
I think ISO 8601 is actually kind of ideal here, we want to preserve fidelity if we can. So if you know that a book was published in August, that is fine in ISO 8601: 2026-08 or if you just know the year, that is fine too: 2026.
I think a contributor in my version could have an optional ref to another record, but it is the same argument that I made in Part 2 of my articles: a book has no canonical ID and neither do people (except in atproto accs of course). So, I’d prefer the contributors denormalized into the record, as people are very easy to confuse with just names (which is all that most book sources have).
In my Part 3, I’ll talk about my XRPC idea that I’ve mentioned in the other thread. But to not leave you on a cliffhanger, I think that we can do with a smaller set of XRPC methods that would need to be implemented. It would essentially only need a search route for unbounded queries & resolve route for exact matches on identifiers. So, given that it is only 2 routes to implement, I don’t think I need to worry about partial implementation support which is why I didn’t engage with the idea.
Interested to hear more about this. I think that what I’ve proposed shouldn’t really preclude authors for claiming books or anything. But, I’ve not thought too much about the needs of authors for this, so I wonder if there is anything on that side which you think is important to this?
Curious if you’ve seen A micro-review lexicon "is/not" as it’s a nice and simple starter rating lexicon.
I’m glad you think so! I built it as a way to allow classifying opinions on things in an expressive rather than reductive way, and so people can represent their multiple personas.
I helped build Deliveroo’s (now DoorDash) categorisation system, and it always bugged me that you can’t express that Date-night meals and hangover meals can both have 5 stars but be wholly inappropriate at the wrong time!
I’ve not done much with is/not yet, but I’d happily develop further if there’s interest!
I had not thanks for sharing. I’ll have more to share eventually, but the approach I’m taking for a ratings lexicon is a layer of abstraction above where anyone can define a rating system as a record and then separately individual ratings refer which scale they’re using and then what they are rating. So this is/not rating system could itself be defined as a rating scale and then anybody could use it to rate anything.
just had a conversation about ratings in a more general sense. from what you describe for a higher level lexicon, I’m guessing I could make a 6star rating system instead of 5stars, right?
The other thing that came up in the conversation is applying labels to the individual positions on the scale. For example, my six star system is:
Having those labels available in the lexicon to use for display would be great so folks can consolidate on a specific definition instead of whatever they their personal language is for each level.
I’ll throw that over the wall in case you aren’t already thinking about it.
I’m generally curious about all these systems. I have two paths converging in my mind:
So I’ve been noodling ideas on how an AT Proto-based approach could help solve for that. Both defining the lexicon and building an app (or apps) for these sorts of things. I’ll follow along here but also have at least a little capacity to help or build something if people are looking for that sort of thing.