[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
result.

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
metadata.
-------------- 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