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 awhomped-up client or server, in which case it has to be really super-duperto 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 aresult.
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 BellLabs where someone signed a letter by mentioning what the recipient atelast week at their shared lunch. Nevertheless, people do find it handy tohave 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 likelyto 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 aline and then the next character responds with the next line or part of aline; 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 nothingBiron: Something then in rhyme.author: John Cowanauthor: William Shakespearetitle: Stichomythia definition and illustrationtitle: Love's Labor's Lost I.i=====CUT HERE=====
It's obvious to a human that the last four lines are metadata and the restis content. But a metadata processor's job is much simplified if the lastfour 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 isLars's proposal. To it I add the convention that a link name beginningwith =: contains metadata applicable to the linked resource. And that'sit. I don't see that this is particularly more extensible than the"unmarked key-value pairs at the end" convention. As for readability, ifwe can get used to seeing "=
" as a link, we can get used to "=: " asmetadata.-------------- next part --------------An HTML attachment was scrubbed...URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210224/5fa2e72e/attachment-0001.htm>