[SPEC] Backwards-compatible metadata in Gemini

[John Cowan]

On Wed, Feb 24, 2021 at 9:08 AM <nothien at uber.space> wrote:

Let me make my argument more specific: author and date and related
> metadata isn't useful to a receiving /client/ because there's nothing it
> can do with it.


That is true, provided you understand "client" as "client for human use"
only.  A search engine is a server with respect to its users, but a client
(of a special kind) with respect to the servers it is indexing.

However, it does not mean that metadata is useless to the *user*.  For
example, a user who wishes to do something more with the document than just
read it can look for "rights" metadata to see what is and isn't allowed.
This can be a Creative Commons or FSF/OSI license name or tag, or just
plain text.  (On this basis, I now think that recommending clients to hide
metadata is wrong unless the client provides a way of displaying it.  If
your client doesn't understand metadata, it will display it anyway, and
that's fine.)

hese can certainly be helpful for stored gemtext files
> (although there are other places metadata can be stored, e.g. in a
> database), as they provide this information to the /server/ to which it
> is useful (particularly for searching and categorizing).
>

By keeping metadata in-band it is much easier to make sure it is not lost
as documents are mirrored and otherwise passed around.  My extensive
example provides a link to formal RDF metadata for those who understand it.



John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
SAXParserFactory [is] a hideous, evil monstrosity of a class that should
be hung, shot, beheaded, drawn and quartered, burned at the stake,
buried in unconsecrated ground, dug up, cremated, and the ashes tossed
in the Tiber while the complete cast of Wicked sings "Ding dong, the
witch is dead."  --Elliotte Rusty Harold on xml-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailing-list-archive.gemi.dev/www/attachments/20210224/583d386d/attachment.htm>