Here's the spec. @PABLOF7z wants to change the stringified content to tags, I think. @liminal agreed to it, yesterday, but they haven't had time to update it. I'll fork it and correct it, after lunch, if they don't get to it, first.
https://wikifreedia.xyz/nkbip-01
I think there should be a way (a tag?) to find the root node, i.e. the Book. Currently a book and a chapter can not be distinguished when searching for 30040 events. Or am I mistaken?
Use case: I want to display all books on nostr.
I agree with using tags for the metadata.
Book = 30040
Chapter = 30041
Gets trickier, when you have nested 30040s, tho, like
Book = 30040
Section 1 = 30040
Chapter in section 1 = 30041
That's what I meant. How to find the books then.
Yes, the 30040s are then a second, parallel linked list. The lower ones need an "e" tag, so that we can tell the top ones by their lack of that tag.
What do you think @PABLOF7z and @liminal and @Michael J ?
i think search starts out identifying all the 30040s and searchable through their titles/authors. A high level contextual view, or how we generally look through books.
The interesting concept comes at the analysis/search level between individual zettles. Been thinking about a word embedding kind. Tags could "model" and the id of the referenced event with the coordinates in the note.
General dvms would have a field day with existing embeddings AND you can plot/organize through their embeddings forbthe users to find connections. Select individual zettles that are exactly what you are interested in.
We're given books and papers with an implicit task of finding the gold in the text. Here we have the coordinates of all raw materials. You find the zettle that you care about and read the surrounding context or insert it into the context of your ideas.
The same zettel can stand on its own, be used as a reference, or clicked on and viewed within the context of the original document. Very powerful modularity, yes.
But the question still stands that there's a sort of list and app designers would want to know where the top-level entry is. (Might be multiple top-levels.)
Like, if I publish a book, how can I ensure that the chapters aren't listed parallel to the book?
When you publish, the parser will have to create some top level 30040. If that's only what we want to see, we could have a tag in there to at least denote the highest level.
If someone else embedded that top-level 30040, then I guess we'd have to Display both as top-level.
Like, someone could print the New Testament and Old Testament as individual books, and someone else could join them into a Bible and add Luther's commentary.
That should be fine, because they are distinct articles on their own. I think a single user would be less likely to publish their incrementally growing book one in a way that clutters the feed, or the design can incentivize that behavior. Def would like to avoid the "nostr plays" type of cluttering.
Viral publications could unravel something like this:
1)user posts 🔥 article
2) many users share - nothing different
3) many users edit, fork and integrate the existing article.
But because these kinds are slower moving than kind1, i don't expect it to be a huge problem considering what is already being delt with.
Even better is when specialized clients connected to themed relays/communities use this. Members of that community can decide on best practices for posting and writing.
@liminal my point was that the 30040's have two uses. On the top level they are used as a book. On the second and deeper levels they are used as sections.
Imagine there are thousands of books and tens of thousands of sections (all 30040 events). How do I query for the list of books? IMHO there is a tag needed to identify the top level books.
I agree a distinguishing tag would be useful.
Top-level 30040s *should* have no e tags, but they definitely *must* have the top-level tag.
Yes, but the 30040 can be nested, right? For a structure like Book (30040) -> Sections (30040) -> Subsections (30040) -> Chapter (30041).