💾 Archived View for rawtext.club › ~sloum › geminilist › 005640.gmi captured on 2024-03-21 at 16:39:17. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
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 betterthan I could ever do. Your proposal is exactly what I was trying todescribe in the other thread.
I loved your proposal, but only until here. I think that what followsis overly-complicated by the fact that you're trying to provide a way todefine the meaning of the metadata, something that can be avoided, atleast in the scope of Gemini.
Let's keep the metadata generic. We'll then start using common keysbecause, well, they're widespread (like Author, Date, ...) or expressiveenough (`Tags: music punk-rock' is pretty self-exlpanatory), while stillallowing authors to add whenever they want extra fields if they feellike (there are people writing poetry, maybe they want to add a metadataabout the metrics? or about a particular style?)
(as other pointed out several time in the past, $DOCUMENT_ROOT is notsomething set in stone. We have single-user capsules, multi usercapsule with different URLs style -- example.com/~op/ vsexample.com/users/op vs ... -- etc)