💾 Archived View for rawtext.club › ~sloum › geminilist › 005575.gmi captured on 2023-12-28 at 16:30:56. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
PJ vM pjvm742 at disroot.org
Wed Feb 24 16:25:19 GMT 2021
- - - - - - - - - - - - - - - - - - -
On 24/02/2021 15:26, John Cowan wrote:
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.
It is maybe important to note that much Gemini content is written withjust a text editor, by people who might not want to neatly structuretheir metadata according to the convention. I'm not sure it would be agood thing for search engines to rely much on metadata - the term"search engine optimisation" comes to mind.
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.
The user can also look for a line that says "This work is licensedunder...". Metadata need not be structured for human users to understand it.
Anyway, I think there are uses for in-file metadata, particularly forsearching a large collection of documents. And sure, it could be usefulto adopt a convention (either the "-:" line thing or the key-value pairsat the end of the file thing, or something else entirely) just so thatpeople would have one way to do this that is commonly understood, and sothat 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 beused in places where there isn't a need for it. I definitely think weshould avoid it becoming an expectation for people who write stuff, orfor Gemini clients.
I also think we should choose a convention that is simple and not easilyextensible. The key-value pairs at the end of the file thing seems a bitbetter on non-extensibility - it's definitely better on readability.
-- pjvm