Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Subject: Re: The brick and mortar
From: "mieum" <mieum@namu.blue>
To: "Arav K." <nothien@uber.space>, "Callum Brown" <callum@calcuode.com>,
 <~mieum/booksin.space@lists.sr.ht>
Date: Fri, 30 Oct 2020 16:00:19 +0900
Message-Id: <C6Q15NBLOOC9.1YGJLIY62ZXX5@maclibre>
In-Reply-To: <C6PHXXPYLMI1.1Z91Y81JTHKFS@gux>

>I think it's best to leave space for some variation.

I agree. Rather than trying to confrom all books to an arbitrary format,
I think a reasonable consistency is enough. Some books will have nth
level of headings beyond the three available in Gemtext. One way to
provide context would be to number headings somehow (1., 1.1., 1.2,
etc.) But that may only be necessary where that hierarchy is crucial.
I think whatever makes sense for the particular text is fine.

>I'm imagining that a book lives at the URL
>booksin.space/<category>/<book short name>/<lang>.gmi, with images (and
>any other assets, such as original versions like PDFs) in the same
>directory, and with booksin.space/<category>/<book short name>.tar for
>an archive of the entire book.  Then metadata could be stored separately
>at booksin.space/<category>/<book short name>/metadata.yml.

I'm wondering what the best structure would be for the capsule itself,
which I suppose depends on how we want to source and build it. Drew had
mentioned using subdomains for different languages, which seems like a
straightfoward way to not only organize the different texts (and their
translations), but also potentially provide multilingual interfaces.=20

I do like the idea of URLs that are descripitve of their content, like
the ones Arav described in the previous quote, but I'm wondering if the
files themselves should actually live in these locations. Some texts
fall into multiple categories, and some have multiple authors. It seems
like indexes should be abstracted from where the actual files are stored
in order to allow for browsing the library in different ways (by author,
genre, language, title, etc.). If we build the site based on the
metadata of the books, it wouldn't be too dificult to just build out a
static representation of what exists in the library organized around
methods of accessing it.

When a text is added, the metadata will be read, and the relevant=20
indexes across the capsule will be rebuilt. The files that result from=20
this process would be, for example:

1. The whole text in Gemtext format including a table of contents made=20
   of links to:
2. Separate .gmi files of the individual chapters, which include links
   to facilitate navigating between chapters.
3. An index page for that particular text which includes these files,
   links pointing to indexes for the author, genre, etc. in question,
   a table displaying the bibliographic data, and perhaps a .bib file
   (or something similar) that readers can use to import the metadata.

One question I have is, should the metadata be "embedded" in the files,
or at least included before or after the body of the text, or should=20
the metadata remain with the source files/be included separately as a
.yml or .bib file?

This evening I will try to make a little prototype of how things might
be organized, that way we have something concrete to reference and
modify.

>I'm looking forward to a Gemini library!

Me too! :)

Thanks for your patience and interest everyone.

~mieum