Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
To: "mieum" <mieum@namu.blue>, "Callum Brown" <callum@calcuode.com>,
 <~mieum/booksin.space@lists.sr.ht>
Subject: Re: The brick and mortar
From: "Arav K." <nothien@uber.space>
Date: Fri, 30 Oct 2020 09:37:54 +0100
Message-Id: <C6Q38D0C6NVK.GE6OFX73DOKR@gux>
In-Reply-To: <C6Q15NBLOOC9.1YGJLIY62ZXX5@maclibre>

On Fri Oct 30, 2020 at 9:00 AM UTC, mieum wrote:
> 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.

Agreed.

> 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.

These are all good ideas.  I think we can keep a centralized repository
of all the texts we collect, but then as texts are received they can be
added at different locations (for each classification by category /
author / etc., and for each language the interface exists in).  I think
the centralized repo should also be made available, perhaps at a
different subdomain (e.g. 'repo.booksin.space' or 'content.<...>' etc.),
so that others can freely keep copies of the same main content.

> When a text is added, the metadata will be read, and the relevant
> indexes across the capsule will be rebuilt. The files that result from
> this process would be, for example:
>
> 1. The whole text in Gemtext format including a table of contents made
> 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.

This is a good idea.  However, I don't know if keeping individual .gmi
files for each chapter is possible or wanted.  I suppose it would depend
upon the size of the text (e.g. it may be viable for books, but not for
shorter stories).  Even if individual .gmi files for chapters are
provided, I would also like a singular .gmi file containing the entire
text, for completeness.  As such, it may be best to require a singular
complete .gmi, but also allow for splitting the text into multiple .gmi
files which would automagically (or manually) be linked to in a
table-of-contents page.

Unless too many complications arise, the main build system could simply
be a Makefile, which could refer to more complex commands (in C, Python,
whatever) to do stuff like index generation.

> 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 the metadata remain with the source files/be included
> separately as a .yml or .bib file?

I think, because the files may contain somewhat repetitive content (due
to having translations of the main text), the metadata should be a
separate .yml / .bib file (or both .yml and .bib).  That may also be
slightly easier to parse (as you don't need to find the metadata
embedded inside a file, and there is a singular location for the
metadata).

Also, we should probably explicitly specify some terms, e.g. 'text'
refers to any content being held by the library (book, play, etc.), in
case confusion about terms ever arises.

~aravk | ~nothien