[SPEC] Backwards-compatible metadata in Gemini

John Cowan cowan at ccil.org
Wed Feb 24 19:07:10 GMT 2021

On Wed, Feb 24, 2021 at 11:25 AM PJ vM <pjvm742 at disroot.org> wrote:

> It is maybe important to note that much Gemini content is written with
> just a text editor, by people who might not want to neatly structure
> their metadata according to the convention. I'm not sure it would be a
> good thing for search engines to rely much on metadata - the term
> "search engine optimisation" comes to mind.

Yes, and the Geminisphere may come to that too.  But that depends on us.
Since there's no obvious way to commercialize it (except by selling a
whomped-up client or server, in which case it has to be really super-duper
to beat the free competition), there aren't those kinds of pressures.

Hits, after all, aren't a benefit to the server owner: they are a cost.
The only way to benefit monetarily from a hit is if you sell something as a

The user can also look for a line that says "This work is licensed
> under...". Metadata need not be structured for human users to understand
> it.

Of course.  Digital signatures aren't either: there was one case at Bell
Labs where someone signed a letter by mentioning what the recipient ate
last week at their shared lunch.  Nevertheless, people do find it handy to
have their computers help them along.

Anyway, I think there are uses for in-file metadata, particularly for
> searching a large collection of documents. And sure, it could be useful
> to adopt a convention (either the "-:" line thing or the key-value pairs
> at the end of the file thing, or something else entirely) just so that
> people would have one way to do this that is commonly understood, and so
> that broadly usable tools could be written for using metadata. However,
> I don't think it is useful in most of Geminispace, and it should not be
> used in places where there isn't a need for it. I definitely think we
> should avoid it becoming an expectation for people who write stuff, or
> for Gemini clients.

I agree 100%.

I also think we should choose a convention that is simple and not easily
> extensible. The key-value pairs at the end of the file thing seems a bit
> better on non-extensibility - it's definitely better on readability.

Part of the problem there is without a signal like "=: " that isn't likely
to be ordinary content, it's easy to get confused.  Consider this:

=====CUT HERE=====
This exchange of dialogue is an example of the rhetorical figure called
"stichomythia", where each character in a play says one line or part of a
line and then the next character responds with the next line or part of a
line; longer speeches are not allowed in such sequences.

Ferdinand: How well he's read, to reason against reading!
Dumain: Proceeded well, to stop all good proceeding!
Longaville: He weeds the corn and still lets grow the weeding.
Biron: The spring is near when green geese are a-breeding.
Dumain: How follows that?
Biron: Fit in his place and time.
Dumain: In reason nothing
Biron: Something then in rhyme.
author: John Cowan
author: William Shakespeare
title: Stichomythia definition and illustration
title: Love's Labor's Lost I.i
=====CUT HERE=====

It's obvious to a human that the last four lines are metadata and the rest
is content.  But a metadata processor's job is much simplified if the last
four lines are:

=: author John Cowan
=: author William Shakespeare
=: title Stichomythia definition and illustration
=: title Love's Labor's Lost I.i

That makes it clear that "Longaville", for example, is not a key.  This is
Lars's proposal.  To it I add the convention that a link name beginning
with =: contains metadata applicable to the linked resource.  And that's
it.  I don't see that this is particularly more extensible than the
"unmarked key-value pairs at the end" convention.  As for readability, if
we can get used to seeing "=> " as a link, we can get used to "=: " as
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210224/5fa2e72e/attachment-0001.htm>

More information about the Gemini mailing list