[spec] [tech] Companion Specification Proposal for Metadata

Omar Polo op at omarpolo.com
Thu Feb 25 21:31:08 GMT 2021


Gary Johnson <lambdatronic at disroot.org> writes:

> Howdy Geminauts,
>
> [snip]
>
> # Proposal
>
> Considering that:
>
> 1. Metadata /within/ a Gemtext file carries a number of liabilities that
>    make some of our community members nervous (understandably so IMO).
>
> 2. The subset of metadata that is meant to be read and understood by a
>    human reader using a typical Gemini client can already be expressed
>    in natural language without any community-approved tag
>    standardization.
>
> 3. The main value to attaching standardized metadata tags to Gemtext
>    pages is likely to simply aid automated bots supporting search
>    engines and archiving.
>
> 4. Geminispace is filled with files in more formats than just Gemtext,
>    many (all?) of which could benefit from similar bot-assisting
>    metadata.
>
> 5. Both aggregators and proxies already have companion specifications
>    that have been (somewhat) adopted by the community and seem to fare
>    better in our community than direct changes to the Gemini protocol or
>    Gemtext specifications.
>
> We propose a companion specification for metadata, in which all the
> metadata about the static files and/or dynamic endpoints (of any format)
> in a capsule be included in a separate file accessible at a well-known
> location that a bot could check as it crawls through Geminispace.
>
> As placeholders, let's put forward these candidates for discussion:
>
> 1. $DOCUMENT_ROOT/.metadata.gmi
> 2. $DOCUMENT_ROOT/.well-known/metadata.gmi

Thanks for putting into words exactly what I had in mind, way better
than I could ever do.  Your proposal is exactly what I was trying to
describe in the other thread.

I loved your proposal, but only until here.  I think that what follows
is overly-complicated by the fact that you're trying to provide a way to
define the meaning of the metadata, something that can be avoided, at
least in the scope of Gemini.

Let's keep the metadata generic.  We'll then start using common keys
because, well, they're widespread (like Author, Date, ...) or expressive
enough (`Tags: music punk-rock' is pretty self-exlpanatory), while still
allowing authors to add whenever they want extra fields if they feel
like (there are people writing poetry, maybe they want to add a metadata
about the metrics?  or about a particular style?)

(as other pointed out several time in the past, $DOCUMENT_ROOT is not
something set in stone.  We have single-user capsules, multi user
capsule with different URLs style -- example.com/~op/ vs
example.com/users/op vs ... -- etc)


More information about the Gemini mailing list