I'll be adding the Bitcoin Whitepaper (and handling the preface structure, that'll be a bug-fix to my upload utility), "The Rhetoric" by Aristotle, and Einstein's treatise on Relativity. And whatever else odd stuff I can think up, to challenge nostr:npub1wqfzz2p880wq0tumuae9lfwyhs8uz35xd0kr34zrvrwyh3kvrzuskcqsyn formatter and tag parser. 😅
Was thinking of having a "Catholic Daily Digest" entry, with audio and visio files incorporated, and saints' pictures, maps, and etc. As a test for making the daily Bible conglomeration that nostr:npub1njst6azswskk5gp3ns8r6nr8nj0qg65acu8gaa2u9yz7yszjxs9s6k7fqx was thinking up. We can pull very different types of information or data into each section, and then mix-and-match the sections for each day. Which audiobook was that, again? I can't find the hyperlink.
I can make an audiobook 30040, like I did for Peter Rabbit, and each audiofile gets a different section, and then we can just pull the relevant section for a 30040 for that day, along with the corresponding Bible excerpt section, and any commentary we can find in a separation section.
Also something like the Hours would be nice.
I'll be putting Einstein's plaintext formulas into their own sections, and when we get the Asciidoc LaTex parser working nicely, I'll change them out for LaTex.
I'll be doing the same with a PlantUML file, so that we can also test that plug-in eventually.
But that's all very much Next Version. 😅 First, we need to get the Asciidoc right and make it easy to upload things.
In a future version, we will be incorporating more of the various notes and articles events, like kind 01 and 1111, long-form, wiki pages, etc. Then you can add those to a 30040, instead of only using the 30041 events, and they will display correctly in Alexandria.
30041 is only for Asciidoc snippets/zetteln. It isn't mean to replace all other events. 30040 is linked-kind-agnostic. That means you can add anything to the list, that has an eventID, so that it can be added to the list of linked "e" tags. That includes other 30040s. Which means that we'll be creating hierarchical Table of Contents.
The initial Bible has only two levels (because that's all the viewer can handle, right now), so I'm publishing each book separated by chapters. Once we have more levels, we can have the hierarchy like
30040 Bible
- 30040 New Testament
-- 30040 Gospels
--- 30040 Mark
---- 30040 Chapter
----- 30041 Verse
and the actual text would be under "verse".
This thread includes an example of PlantUML and LaTex, for those who are wondering what those are.
Alexandria, however, is not a replacement for a long-form, microblogging, or wiki client, as those are specialized in navigating those event types, which is its own science. We will simply be displaying each individual one, listed in a 30040, as if it were a 30041.
And we will eventually have an ePaper version (tending toward PHP, on this one, like with the upload utility), that will allow you to download an ePUB of the 30040, or to navigate a 30040 offline, as HTML versions of the events (perhaps including the linked data, once removed, so if a wiki page included in the 30040 has internal wiki links, we'd download those wiki pages, too, so that you can click the links and see something). The switch to Asciidoc makes that easier to implement.
For those who aren't familiar with PlantUML, it allows you to describe a diagram in human-readable text, and then it displays it as a picture.
So, your text would contain code like this:
``` PlantUML
@startuml
left to right direction
skinparam packageStyle rectangle
actor Professor
actor Student
actor Staff
rectangle University-System {
Professor --> (Grade Exam)
Professor --> (Manage Course)
Professor ---> (Access Course Information)
Student ---> (Access Course Information)
Student ---> (Enroll in Course)
Staff ---> (Access Course Information)
Staff ---> (Manage Course)
}
@enduml
```
And that would give you a picture in Alexandria like this:
And LaTex is how you can write confusing text like in the picture below in blue, but get a pretty formula displayed. This allows us to use Nostr to store scientific journal articles, broken down into sections, that can be included in other articles directly or by forking the event and including your new cloned section.
Our idea, is that forking an event is more powerful than copy-pasting data, as you retain a programmatic connection to the original, without your version auto-updating or being deletable by the original event's author.
Then we can analyze the absolute and relative importance of a 30041 section, by checking how many other npubs have forked it, reacted or replied to it, highlighted it, bookmarked it, broadcasted it, labeled it, or embedded it in their own notes with a nostr address.
