💾 Archived View for gemi.dev › gemini-mailing-list › 000735.gmi captured on 2023-12-28 at 15:51:59. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-11-04)
-=-=-=-=-=-=-
Many of us strongly believe in the one pageload generates one request
philosophy, including me, but metadata is also nice to have. While you
could put metadata in other files, that would result in multiple requests
being made. Instead, I am proposing a new file format,
text/gemini-metadata+json, to be used in data URIs in Gemtext. It would be
json (simply because it is popular and has wide support) with specified
keys. Possible things to include in the metadata could be a favicon (be it
emoji or otherwise), a theme color or color scheme to be used by the client
as it wishes, etc.
It would be used like this:
```
# My super cool gemsite
Welcome!
=> data:text/gemini-metadata+json;charset=utf-8,{"favicon":"?%E2%80%8D?"}
Page metadata
```
A Gemini client implementing this would add a check for links starting with
data:text/gemini-metadata+json to it's rendering code and when it
encounters one, decode it and take note of the metadata. Clients not
implenenting it will just see a link to the data, degrading (imo) quite
gracefully. I can't decide if the link should be hidden or not in browsers
with support though. If the link is hidden then the client should make sure
to expose the metadata elsewhere in the interface.
Please give all the feedback!
-- easrng
(Did I tag this right?)
--
? <https://www.google.com/teapot>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210221/e9da
64b2/attachment.htm>
On Sun, 21 Feb 2021 at 20:21, easrng <easrng at gmail.com> wrote:
>
> Many of us strongly believe in the one pageload generates one request
philosophy, including me, but metadata is also nice to have. While you
could put metadata in other files, that would result in multiple requests
being made. Instead, I am proposing a new file format,
text/gemini-metadata+json, to be used in data URIs in Gemtext. It would be
json (simply because it is popular and has wide support) with specified
keys. Possible things to include in the metadata could be a favicon (be it
emoji or otherwise), a theme color or color scheme to be used by the
client as it wishes, etc.
> It would be used like this:
>
> ```
> # My super cool gemsite
> Welcome!
>
> => data:text/gemini-metadata+json;charset=utf-8,{"favicon":"%E2%80%8D"} Page metadata
> ```
>
> A Gemini client implementing this would add a check for links starting
with data:text/gemini-metadata+json to it's rendering code and when it
encounters one, decode it and take note of the metadata. Clients not
implenenting it will just see a link to the data, degrading (imo) quite
gracefully. I can't decide if the link should be hidden or not in browsers
with support though. If the link is hidden then the client should make
sure to expose the metadata elsewhere in the interface.
> Please give all the feedback!
>
Whilst it does fallback gracefully, I think the method of putting it
in a link is a bit "hack-y" and using the data: URI may pave the way
for other things abusing it.
Also for people that don't have nice link parsing it would look a mess.
I think something like this would be nicer:
```
# Boop, a website :)
Free hugs for all!
^^^
favicon: ?
author: Bob McBobface
last-edited: 22nd Feb 2021
```
That is:
```
<PAGE>
^^^
<METADATA>
```
For the metadata format I think a simple key:value list would work
fine, nothing overcomplicated.
To someone without support for it it should just look like a human
list of metadata.
This way it would work with gemtext's current line-by-line method, and
parsing should be simple.
The delimiter would work similar to the opening ``` toggle and there
would be no closing one, enforcing placing it at the end of the file.
The delimiter needs to be 3 chars long (as per current spec), and
something people wouldn't want to use in their document elsewhere, I
think ^^^ would work good for this.
I think this is given, but the metadata would be entirely optional.
- Oliver Simmons (GoodClover)
Am Mo, 22. Feb 2021, um 01:46, schrieb Oliver Simmons: > I think something like this would be nicer: > ``` > # Boop, a website :) > Free hugs for all! > > ^^^ > favicon: ? > author: Bob McBobface > last-edited: 22nd Feb 2021 > ``` > > That is: > ``` > <PAGE> > ^^^ > <METADATA> > ``` > > For the metadata format I think a simple key:value list would work > fine, nothing overcomplicated. > To someone without support for it it should just look like a human > list of metadata. Giving my two cents, I agree with Oliver here. I don't think page metadata deserves it's own mime/type and shouldn't be JSON encoded in a data link. Goes against the human-friendly philosophy of Gemtext. Oliver's proposal seems to be quite right because it makes everything optional, very easy to parse and can also be displayed without any special rendering support by the client. This way it's purely conventional and would still work for clients with and without support. Regarding color schemes etc. Is it part of the plan that Gemtext pages will control the browser color scheme? Gemtext is a text-based markup, there should be no style information. The user should control the theme of their client/browser, not the page that is currently displayed. Lagrange is a great example how rendering of Gemtext can be very beautiful without CSS-like styling whatsoever. Louis
On Mon, Feb 22, 2021 at 12:46:22AM +0000, Oliver Simmons <oliversimmo at gmail.com> wrote a message of 69 lines which said: > Also for people that don't have nice link parsing it would look a > mess. Why? These people would only see the text at the end of the line, not the 'data:' link itself. > ^^^ > favicon: ? > author: Bob McBobface > last-edited: 22nd Feb 2021 > The delimiter would work similar to the opening ``` toggle and there > would be no closing one, enforcing placing it at the end of the file. I think that metadata are important, I find both easrng's and your proposal fine. I tend to prefer yours since it degrades better for people who don't have metadata support in their clients. (On the other end, easrng's is probably better for programs, while yours is better for humans, but both work for programs and humans, which I like.) Now, some details:
> On Feb 22, 2021, at 11:00, Louis Brauer <louis at brauer.family> wrote: > > human-friendly philosophy of Gemtex Meta... human-friendly, good...machine readable, better. MIME headers are very readable on their own. A preformatted MIME preamble ?or perhaps even an embedded data:message/rfc822 link? would do nicely. ?0?
On Mon, 22 Feb 2021 at 10:18, Stephane Bortzmeyer <stephane at sources.org> wrote: > > Why? These people would only see the text at the end of the line, not > the 'data:' link itself. Some clients show the links, most have an option to display it if they don't. Myself I like to have them shown so I know where I'm going. > * What set of characters in the key (except the colon, of course)? > LDH? ASCII letters or Unicode? Gemini follows UTF-8/Unicode encoding everywhere else, so sticking to that makes sense. A "best practice" will be to stick to regular ASCII characters if possible. > * What about the value? Completely unstructured and therefore > unparsable? Your own example for "last-edited" is useless for programs > since it does not fit any known standard for dates. last-edited was just a random example, I wasn't trying to propose keys or values. > * Will we need a list of standard keys, to avoid some people using > "last-modified", others "last-edited" and others "last-change"? A list of common keys/values should be a thing, without out it the metadata will be really impractical for any clients to use and will degrade into meaningless junk. However this should NOT be a part of the spec, anyone can use any keys/values they like, but a list of commonly used & recognised by client should be kept. OSM has a nice semi-related quote for this: >From https://wiki.openstreetmap.org/wiki/Any_tags_you_like: > Feel free to invent new tags! Though it is not "feel free to ignore existing tagging schemes and start marking pharmacies with unicorn=parking_lot". (tags being key/value pairs)
On Mon, Feb 22, 2021 at 10:34:46AM +0000, Oliver Simmons <oliversimmo at gmail.com> wrote a message of 36 lines which said: > > * What about the value? Completely unstructured and therefore > > unparsable? Your own example for "last-edited" is useless for programs > > since it does not fit any known standard for dates. > > last-edited was just a random example, I wasn't trying to propose keys > or values. My question still holds. Should values be unstructured or should we have structured types (dates, datetimes, numbers, URIs, etc)?
> On Feb 22, 2021, at 11:47, Stephane Bortzmeyer <stephane at sources.org> wrote: > > My question still holds. Should values be unstructured or should we > have structured types (dates, datetimes, numbers, URIs, etc)? Structured, for sure. ?0?
On Mon, 22 Feb 2021 at 10:48, Stephane Bortzmeyer <stephane at sources.org> wrote: > > My question still holds. Should values be unstructured or should we > have structured types (dates, datetimes, numbers, URIs, etc)? > Unstructured data wouldn't be much more useful than people just sticking these in the file as plain text. :P All the usual standards for dates/numbers/URIs should be followed. As I said before, a list of common keys/values should be a thing. Anyone could write any freeform keys/values, but a list of commonly used & supported key/values should be maintained, this should include whatever format the values follow. It should be freeform such that I could come along and decide I want to use a new key and nothing should break, clients will ignore it if they don't recognise it. Metadata is not just for the machines, e.g an `author` key would be mainly for people interested in who wrote something.
On Mon, Feb 22, 2021 at 5:01 AM Louis Brauer <louis at brauer.family> wrote: > Oliver's proposal seems to be quite right because it makes everything optional, very easy to parse and can also be displayed without any special rendering support by the client. This way it's purely conventional and would still work for clients with and without support. I agree this is probably a better plan. > Regarding color schemes etc. Is it part of the plan that Gemtext pages will control the browser color scheme? Gemtext is a text-based markup, there should be no style information. The user should control the theme of their client/browser, not the page that is currently displayed. I was thinking of having a single color that the client could use however it wants, ex. to theme the title bar or color links or whatever. > Lagrange is a great example how rendering of Gemtext can be very beautiful without CSS-like styling whatsoever. Lagrange could take the hue from the theme color and use it, or ignore it or whatever. I suppose this could be a slippery slope though.
On Mon, 22 Feb 2021 at 13:38, easrng <easrng at gmail.com> wrote: > > I was thinking of having a single color that the client could use > however it wants, ex. to theme the title bar or color links or > whatever. > I don't think any stylistic data should be added. Metadata should not modify the document in any way, it should only describe the document or add additional things to it. >From the spec scrolls: > The format is line-oriented, and a satisfactory rendering can be achieved with a single pass of a document, processing each line independently. Having stylistic info ~kinda (it's possible to argue it doesn't) breaks this definition. Enforcing putting the metadata at the end of the file (slightly) helps to avoid this. > I suppose this could be a slippery slope though. Let's try to avoid falling down the cliff.
On 2/21/2021 4:46 PM, Oliver Simmons wrote:
> On Sun, 21 Feb 2021 at 20:21, easrng <easrng at gmail.com> wrote:
>>
>> It would be used like this:
>>
>> ```
>> # My super cool gemsite
>> Welcome!
>>
>> => data:text/gemini-metadata+json;charset=utf-8,{"favicon":"%E2%80%8D"} Page metadata
>> ```
>>
I'm not going to weigh in here on the virtues of this, but wouldn't the
following be more applicable?
# My Super cool gemsite
```data:text/gemini-metadata+json;charset=ut.......
Welcome!
```
--
Bradley D. Thornton
Manager Network Services
http://NorthTech.US
TEL: +1.310.421.8268
On Mon, 22 Feb 2021 11:04:41 +0000, Oliver Simmons wrote: > All the usual standards for dates/numbers/URIs should be followed. On Mon, 22 Feb 2021 11:50:31 +0100, Petite Abeille wrote: > Structured, for sure. https://schema.org/ comes to mind: > Schema.org is a collaborative, community activity with a mission to create, maintain, and promote schemas for structured data on the Internet, on web pages, in email messages, and beyond. Maybe this isn't too deep a rabbit hole ```schema.org keywords: metadata, convention license: wtf ``` as per gemini://gemini.circumlunar.space/docs/gemtext.gmi that states: > Anything which comes after the ``` characters of a line which toggles preformatted line *on* (i.e. the first, third, fifth, etc. toggling lines in a document) may be treated as "alt text" for the preformatted content. In general you should not count on this content being visible to the user but, for example, search engines may index it and screen readers may read it to users to help the user decide whether the preformatted content should be read aloud (which e.g. ASCII art generally should not be, but which source code perhaps should be). There are currently no established conventions on how alt text should be formatted. ```purl.org/dc/terms/ created: 2021-02-22 ``` -- dash dash space would have been quite lovely, too.
On Mon, Feb 22, 2021 at 11:00:29PM +0100, text at sdfeu.org <text at sdfeu.org> wrote a message of 40 lines which said: > https://schema.org/ comes to mind: The good point is that it already exists so we don't reinvent the wheel. The not-so-good one is that schema.org is often complicated. For instance, dates are expressed in the ISO 8601 format which is 1) not publically available 2) very complicated (unlike what most people think). => gemini://gemini.bortzmeyer.org/rfc-mirror/rfc3339.txt RFC 3339 is a more reasonable subset of ISO 8601 > as per gemini://gemini.circumlunar.space/docs/gemtext.gmi that states: [Warning: the authoritative source is <gemini://gemini.circumlunar.space/docs/specification.gmi>] > Anything which comes after the ``` characters of a line which toggles > preformatted line *on* (i.e. the first, third, fifth, etc. toggling lines > in a document) may be treated as "alt text" for the preformatted > content. Using this "alt text" feature is tempting, and it allows the metadata proposal to avoid any change in the specification. But, currently, as far as I know, there is no registry of possible alt texts. (I don't ask for an official registry in the spec. Any widely recognized registry will do.) > ```purl.org/dc/terms/ > created: 2021-02-22 For dates, purl is even worse, allowing many format of dates, besides the complicated ISO 8601. Laxity is bad for simplicity.
On Tue, 23 Feb 2021 09:05:46 +0100 Stephane Bortzmeyer <stephane at sources.org> wrote: > Using this "alt text" feature is tempting, and it allows the metadata > proposal to avoid any change in the specification. But, currently, as > far as I know, there is no registry of possible alt texts. (I don't > ask for an official registry in the spec. Any widely recognized > registry will do.) Alt text is for accessibility, not metadata.
On 2/23/21 10:05 AM, Stephane Bortzmeyer wrote: [snip] > The good point is that it already exists so we don't reinvent > the wheel. [snip] Greetings, Some of this depends on what kind of metadata we are talking about. I am reluctant to discuss extension. I would have to say that the only topic of potential interest to me [1] in that area would be about document metadata: Gemini is about transmission of information and metadata is information. By document metadata I mean information /about/ the document content. As for the questions of network budget, fingerprinting, pressure to include, and complexity[2], those can be addressed. If the document metadata is in the body of the document, then there are no extra network requests. That addresses fingerprinting and mostly addresses network budget. The metadata does not have to be marked up in a difficult manner to be both machine readable and human readable. Borrowing from the link syntax [3], =:[<whitespace>]<TERM><whitespace><METADATA> which could look like this in the body, but would be up to the client as to how it is dealt with. Left unprocessed, it would degrade gracefully and be quite readable. =: dc.title A Random Title =: dc.date 2021-02-23 =: keywords cat; dog; bird Again, by being included anywhere inside the body, there would be no extra network calls. There should be no requirement as to what is in the metadata, which terms are allowed, or what the terms mean. Any extension should say only how terms may be included and leave the rest up to the capsule and the client software. Otherwise the details would lead to discussions which would last years [4] at best while also reinventing the wheel. If a tipping point is ever reached regarding use then there might be some pressure for clients to support it. But if the trajectory follows that of HTML metadata, its use will be inconsistent, niche, and site-specific. Anyway, the type(s) of metadata would be up to the capsule owner to pick and for them follow a schema or vocabulary or not. All that said, there is usually more to gain by KISS than by extension or creeping featurism. /Lars [1] I (a retired digital libraries specialist) got into setting up a Gemini capsule only two weeks ago but used to run a gopher site both back when it was relevant and in more recent years as an Onion service. As for the WWW, I did not get into running any Web sites until 1994, the second of which was briefly so visited by the end of that year that it caused a local network outage. [2] gemini://gemi.dev/gemini-mailing-list/messages/005504.gmi [3] Project Gemini : Speculative specification gemini://gemini.circumlunar.space/docs/specification.gmi [4] See also The Dublin Core Metadata Initiative. What started out as a consensus of a common descriptive core, a simple, no-nonsense list of 15 semantic metadata terms which could fit on a single web page, https://en.wikipedia.org/wiki/Dublin_Core#Dublin_Core_Metadata_Element_Set has morphed since the 1990s into this egregious monstrosity: https://dublincore.org/specifications/dublin-core/ https://www.iso.org/standard/71339.html
On Tue, 23 Feb 2021 at 09:16, Lars Nood?n <lars.nooden at gmx.com> wrote: > Some of this depends on what kind of metadata we are talking about. > > Gemini is about transmission of information and > metadata is information. By document metadata I mean information > /about/ the document content. Only data about the document should be allowed, and it should not modify the document (i.e. no stylistic info). > =:[<whitespace>]<TERM><whitespace><METADATA> > > which could look like this in the body, but would be up to the client as > to how it is dealt with. Left unprocessed, it would degrade gracefully > and be quite readable. This syntax would allow for it to be placed anywhere in the document, which could enable it to be used to extend Gemini in unwanted ways, for example: =: text-colour red I'm blue! =: text-colour blue I'm red >:) (this is a lame example, there are probably worse things it could do) Placing it at the end of the file, which my format would enforce, makes this impossible. If it did change the file (which wouldn't be allowed) it would have to be the entire file, making this harder. Also, using space as the delimiter causes some issues, for example: =: author Oliver Simmons A simple client might try to split on the spaces, which would split the name into two, using a colon or equals is more conventional for key/value things, and avoid this problem (wanting to use : or = in a key or value isn't likely). > Again, by being included anywhere inside the body, there would be no > extra network calls. Just pointing out that none of the three proposed formats do this, extension of the protocol is entirely out of the question. This is NOT like HTTP headers, it is strictly document metadata. > There should be no requirement as to what is in the metadata, which > terms are allowed, or what the terms mean. Any extension should say > only how terms may be included and leave the rest up to the capsule and > the client software. 100% agree
On Tue, 23 Feb 2021 at 15:10, raingloom <raingloom at riseup.net> wrote: > > On Tue, 23 Feb 2021 09:05:46 +0100 > Stephane Bortzmeyer <stephane at sources.org> wrote: > > > Using this "alt text" feature is tempting, and it allows the metadata > > proposal to avoid any change in the specification. But, currently, as > > far as I know, there is no registry of possible alt texts. (I don't > > ask for an official registry in the spec. Any widely recognized > > registry will do.) > > Alt text is for accessibility, not metadata. Yup! Alt text itself is a form of metadata, but that doesn't mean it's ok to include other metadata inside it. Someone with a screen reader wouldn't want to have that read out to them. In Gemini it's intended to be used for things such as code or ASCII art to describe what they are. The spec says this about alt text: > Alt text is recommended for ASCII art or similar non-textual content which, for example, cannot be meaningfully understood when rendered through a screen reader or usefully indexed by a search engine. Alt text may also be used for computer source code to identify the programming language which advanced clients may use for syntax highlighting. Preformatted text is for text that shouldn't be formatted by the client. Meaning it should be shown to the user as-is, using it to add metadata would be wrong, see section 5.4.4 (Preformatted text lines): => https://gemini.circumlunar.space/docs/specification.gmi
On Tue, Feb 23, 2021 at 03:43:22PM +0000, Oliver Simmons <oliversimmo at gmail.com> wrote a message of 31 lines which said: > Someone with a screen reader wouldn't want to have that read out to > them. Why? Things like "publication-date" or "author" are certainly metadata that most readers would like to know.
On Tue, 23 Feb 2021 at 15:58, Stephane Bortzmeyer <stephane at sources.org> wrote: > > On Tue, Feb 23, 2021 at 03:43:22PM +0000, Oliver Simmons <oliversimmo at gmail.com> wrote: > > Someone with a screen reader wouldn't want to have that read out to > > them. > > Why? Things like "publication-date" or "author" are certainly > metadata that most readers would like to know. That's not what I meant... Preformatted text wouldn't be read out by screenreaders, the alt text would. On Mon, 22 Feb 2021 at 20:16, Bradley D. Thornton <Bradley at northtech.us> wrote: > ```data:text/gemini-metadata+json;charset=ut....... > Welcome! > ``` The "data:text/gemini-metadata+json;charset=ut......." is the part that would be read out. "Welcome!" would be ignored (unless it detects that it's ok to read out, or the user says they want it read out). OFC this all depends on the implementation of screenreader.
On 22.02.21 21:16, Bradley D. Thornton wrote: > > > On 2/21/2021 4:46 PM, Oliver Simmons wrote: >> On Sun, 21 Feb 2021 at 20:21, easrng <easrng at gmail.com> wrote: >>> [snip] > I'm not going to weigh in here on the virtues of this, but wouldn't the > following be more applicable? > > # My Super cool gemsite > > ```data:text/gemini-metadata+json;charset=ut....... > Welcome! > ``` > Ok I think have to throw in my two ct here ? # Please don't do fancy data link black magic in gemtext. The reason we (at lest I) like gemtext is that it's easy to read and write, and that for both humans and machines. Putting metadata behind two or three layers of encoding and/or hiding it in elements that were not intended to store page metadata won't make it easier to parse it (for both)! I personally like Oliver's approach, that makes the metadata both machine and human readable and forces it to the end of the document, so that it stays out of the way on clients that don't have support for hiding it. ## Meta about metadata Of course we have to standardize some keys and value types to make the metadata actually useful for machines, but in a way that is human readable/writable and easy to parse. No "anything that <command> can parse" is not a good standard at all, if that approach had been used for gemtext it would have turned into a mess pretty quickly and nobody would care. Greetings - Baschdel ^^^ version: 1 date-written: 21-02-23 11:09 +0100 author: Baschdel => mailto:baschdel at disroot.org author contact E-Mail => mailto:gemini at lists.orbitalfox.eu?subject=? reply contact style: E-Mail message => gemini://gemi.dev/gemini-mailing-list/messages/005420.gmi answerto => gemini://gemi.dev/gemini-mailing-list/messages/005522.gmi mirror
I put some example metadata below my last E-Mail but after catching up with the rest of the discussion since writing it, and thinking a bit about it, I've come to the conclusion that I should add a littlebit of explanation. First and foremost: I consider this st its current stage a (thought) experiment and MAYBE a future convention for gemtext. Something I really shouldn't have to write, but to clarify: With great power comes great responsibility! Adding metadata adds great power and whoever is implementing a metadata based feature should ask themselves if what they are doing is the right thing to encourage (this applies to all things you are implementing). > > ^^^ > version: 1 > date-written: 21-02-23 11:09 +0100 I added that one first and of course I messed it up. It should be: date written: 2021-02-23 11:09 +0100 I choose this format because it's easy to parse for humans and computer alike for dates. The key consists of two keywords: date and written a client that cares about metadata but wants to keep it simple can simply search for the first thing starting with date. (Maybe just having date is enough) > author: Baschdel > => mailto:baschdel at disroot.org author contact E-Mail I'm using link lines for uris here because then they will still work if the client ignores the metadata, the contact keyword tells the client that this link is contact information. the E-Mail is just a label for humans (I don't know if adding the label without any special delimiter is a good thing or not, it will definitely make it less easy to extend this) > => mailto:gemini at lists.orbitalfox.eu?subject=? reply contact Same as above without a label for humans, a client could show a reply button at the bottom of the page > style: E-Mail message Can of Worms! nasty ones! Thinking about it, it would be a good thing to add styling hints (for example that this is a fee page or search results page) but this would encourage writing gemtext, that is overloading linetypes left and right because some people don't realize, that styling and meaning are two different things. > => gemini://gemi.dev/gemini-mailing-list/messages/005420.gmi answerto > => gemini://gemi.dev/gemini-mailing-list/messages/005522.gmi mirror Two tagged links, one linking to the message this one is an answer to another one linking to a mirror of this page (following this system an alternative link to an answer would be tagged with "answerto mirror") To prevent content authors and/or server from going wild I'd suggest, that clients always show the metadata section like it would render the page above. One thing I don't really like with this one is, that we use English keywords here and that for human readable text that is intended to be attached to a file, that could be in any language and is not very accessible to non-English speakers. A possible solution to that could be in unicode and (you guessed it, didn't you?) emoji (yay!), at least those little pictures are standardized and independent of the language(s) you speak. (Just make sure the emoji makes sense for what it is used) Greetings - Baschdel (I should really spin up my own gemlog)
I'm just going to quickly address everything about the metadata ideas /
proposals:
They're not necessary.
I'm going to split it into two groups: metadata affecting presentation,
and metadata about the document.
# Metadata for Presentation
Gemini is (in specification and in spirit) against any specification of
presentation. Stuff like favicons or colors as a part of the document
are problematic because you're going above and beyond the /one/ thing
that Gemini is trying to do: provide content without presentation.
Instead of trying to introduce these, please work within the limits that
Gemini has already presented to you.
# Metadata for the Document
What's the /point/ of standardizing a format for providing metadata
about a document? Seriously, I don't understand. What's the benefit of
letting a client know who the author is? If you, an author, want users
to know that you wrote something, just write "I wrote this". These
kinds of proposals are unnecessary. If you want it to be read properly
by a screen reader, just write in full sentences ('this was written on
the 23rd of February'). Keep it open, prevent it from turning into a
matter of convention, and think about how to solve problems /without/
extending the specification in any way. Even if it's
"backward-compatible", you're creating a rift in Gemini - see "Problems
with Conventions" below.
# "It's Just A Suggestion/Idea"
The problem with 'just' posting ideas and suggestions and proposals like
these is that they waste everyone's time (including yours). Instead of
trying to add new, unnecessary, and unwanted features to Gemini, start
creating content within it! We (and I'm speaking for a lot of people
here) are tired of dealing with new ideas from eager new Geminiauts who
keep trying (consciously or unconsciously) to reinvent the Web. Please
/stop/ thinking about Gemini like it's the Web, or a replacement, or
anything of the sort! Come to Gemini with an open mind to what it's
trying to do. Read the spec, read the FAQ, read the companion
documents, read the mailing list, and /understand/ the spirit of Gemini.
# The Problem with Conventions
Conventions are naturally difficult because you're politely asking
people to do something. This separates the Gemini userbase into people
who have done that thing and people who haven't. If you want to create
a new convention, /please/ think about the effect this can have,
particularly with conventions involving presentation. As others have
pointed out, every new convention threatens to make a split in the user
base, and if anyone (user or site) can for any reason prefer one side
over the other, you've begun the process of separation. Don't do that,
because we're just going to have to shoot your shit down.
# Compatibility
Another issue with conventions is the fact that we have over 200
individual pieces of software which use Gemini in its current state.
This makes Gemini /very/ resistant to change, because we don't have the
manpower to update all of that software. This is why the spec is now in
a near-freeze state - all we want to do now is make clarifications to
the existing spec and to not add new things.
# Conclusion
Please stop.
Thanks.
~aravk | ~nothien
> Le 23 f?vr. 2021 ? 20:09, nothien at uber.space a ?crit :
>
> ?I'm just going to quickly address everything about the metadata ideas /
> proposals:
>
> They're not necessary.
>
> I'm going to split it into two groups: metadata affecting presentation,
> and metadata about the document.
>
> # Metadata for Presentation
>
> Gemini is (in specification and in spirit) against any specification of
> presentation. Stuff like favicons or colors as a part of the document
> are problematic because you're going above and beyond the /one/ thing
> that Gemini is trying to do: provide content without presentation.
> Instead of trying to introduce these, please work within the limits that
> Gemini has already presented to you.
>
> # Metadata for the Document
>
> What's the /point/ of standardizing a format for providing metadata
> about a document? Seriously, I don't understand. What's the benefit of
> letting a client know who the author is? If you, an author, want users
> to know that you wrote something, just write "I wrote this". These
> kinds of proposals are unnecessary. If you want it to be read properly
> by a screen reader, just write in full sentences ('this was written on
> the 23rd of February'). Keep it open, prevent it from turning into a
> matter of convention, and think about how to solve problems /without/
> extending the specification in any way. Even if it's
> "backward-compatible", you're creating a rift in Gemini - see "Problems
> with Conventions" below.
>
> # "It's Just A Suggestion/Idea"
>
> The problem with 'just' posting ideas and suggestions and proposals like
> these is that they waste everyone's time (including yours). Instead of
> trying to add new, unnecessary, and unwanted features to Gemini, start
> creating content within it! We (and I'm speaking for a lot of people
> here) are tired of dealing with new ideas from eager new Geminiauts who
> keep trying (consciously or unconsciously) to reinvent the Web. Please
> /stop/ thinking about Gemini like it's the Web, or a replacement, or
> anything of the sort! Come to Gemini with an open mind to what it's
> trying to do. Read the spec, read the FAQ, read the companion
> documents, read the mailing list, and /understand/ the spirit of Gemini.
>
> # The Problem with Conventions
>
> Conventions are naturally difficult because you're politely asking
> people to do something. This separates the Gemini userbase into people
> who have done that thing and people who haven't. If you want to create
> a new convention, /please/ think about the effect this can have,
> particularly with conventions involving presentation. As others have
> pointed out, every new convention threatens to make a split in the user
> base, and if anyone (user or site) can for any reason prefer one side
> over the other, you've begun the process of separation. Don't do that,
> because we're just going to have to shoot your shit down.
>
> # Compatibility
>
> Another issue with conventions is the fact that we have over 200
> individual pieces of software which use Gemini in its current state.
> This makes Gemini /very/ resistant to change, because we don't have the
> manpower to update all of that software. This is why the spec is now in
> a near-freeze state - all we want to do now is make clarifications to
> the existing spec and to not add new things.
>
> # Conclusion
>
> Please stop.
>
> Thanks.
>
> ~aravk | ~nothien
I wholeheartedly agree, please stop proposing unnecessary complexity that
benefits nobody (just for the sake of normalizing everything) or adds
client display fancyness.
We should always consider underpowered devices, screen readers, people
with a slow internet connection. I know TLS is already a burden for some
of these cases so let?s not add more data to transfer.
?
julienxx
On 2021-02-23 14:23, Julien Blanchard wrote: > I wholeheartedly agree, please stop proposing unnecessary complexity that benefits nobody (just for the sake of normalizing everything) or adds client display fancyness. > We should always consider underpowered devices, screen readers, people with a slow internet connection. I know TLS is already a burden for some of these cases so let?s not add more data to transfer. > > ? > julienxx > 'Nuff said. We need to start focusing on the finer details rather than coming up with new ones. Sure, it might be a good idea in your head, but at one point or another the spec **will** be frozen. Sebastian Alejandro | kayw
On Tue, 23 Feb 2021 at 19:09, <nothien at uber.space> wrote: > > # Metadata for Presentation > Metadata is NOT for presentation. > # Metadata for the Document > > What's the /point/ of standardizing a format for providing metadata > about a document? Seriously, I don't understand. What's the benefit of > letting a client know who the author is? If you, an author, want users > to know that you wrote something, just write "I wrote this". These > kinds of proposals are unnecessary. Myself I've more been thinking of the how and not the why with this, and I apologise for that. Most of the examples given here are pretty pointless for clients, nobody has suggested any uses for metadata other than to replace the favicon thing, author, and the "when" of the document. The only major uses I can think of is for orbits (webrings), and it would help search engines. It's pretty pointless. > Read the spec, read the FAQ, read the companion > documents, read the mailing list, and /understand/ the spirit of Gemini. I would hope everyone here has. > We have over 200 individual pieces of software which use Gemini in its current state. > This makes Gemini /very/ resistant to change, because we don't have the > manpower to update all of that software. This is why the spec is now in > a near-freeze state - all we want to do now is make clarifications to > the existing spec and to not add new things. All existing software would still work. This is only an addition. About the freezing, I got the impression it was only the protocol that was frozen. On Tue, 23 Feb 2021 at 19:23, Julien Blanchard <julien at typed-hole.org> wrote: > > We should always consider underpowered devices, screen readers, people with a slow internet connection. I know TLS is already a burden for some of these cases so let?s not add more data to transfer. I don't see how adding a few lines would cause much of an issue?
Oliver Simmons <oliversimmo at gmail.com> wrote: > Metadata is NOT for presentation. By that, I mean things like the favicon and color proposals, which were also bunched under the 'metadata' umbrella category/name. > Myself I've more been thinking of the how and not the why with this, > and I apologise for that. Most of the examples given here are pretty > pointless for clients, nobody has suggested any uses for metadata > other than to replace the favicon thing, author, and the "when" of the > document. The only major uses I can think of is for orbits > (webrings), and it would help search engines. It's pretty pointless. I agree, it's not useful, but I wanted to cover a few of the cases you mentioned. I disagree with the favicon feature as a whole, so I'm not going to touch that. I don't know how webrings are organized on Gemini, but I'm not sure how the author or date would matter there. From my understanding, these things typically link to the whole gemini capsules, which should already provide author information, and I don't think date info is relevant here. We already have the gmisub companion spec for describing gemlog posts and similar dated content. Search engines typically date content based on when they first indexed it, so that's not an issue either. > > Read the spec, read the FAQ, read the companion documents, read the > > mailing list, and /understand/ the spirit of Gemini. > > I would hope everyone here has. Unfortunately, it doesn't seem to be the case. > All existing software would still work. This is only an addition. > About the freezing, I got the impression it was only the protocol that > was frozen. > > ... > > On Tue, 23 Feb 2021 at 19:23, Julien Blanchard <julien at typed-hole.org> wrote: > > > > We should always consider underpowered devices, screen readers, > > people with a slow internet connection. I know TLS is already a > > burden for some of these cases so let?s not add more data to > > transfer. > > I don't see how adding a few lines would cause much of an issue? The issue is not that it would break pre-existing software, but that it would make it less appealing to use, compared to new software which does implement the new additions. This applies to clients and servers and everything in between. That's the 'rift' I was talking about in my original mail. ~aravk | ~nothien
On Tue, 23 Feb 2021, 21:12 , <nothien at uber.space> wrote: > Oliver Simmons <oliversimmo at gmail.com> wrote: > > Metadata is NOT for presentation. > > By that, I mean things like the favicon and color proposals, which were > also bunched under the 'metadata' umbrella category/name. > I understood what you meant, was just expressing my view of it :) IMO the favicon isn't presentation, it's dosent modify the document itself. I don't really know if I like/dislike the favicons, so I'd like to refrain from commenting on this much, I just know that I don't like their current form (of a seperatate request). I don't know how webrings are organized on Gemini, but I'm not sure how the > author or date would matter there. From my understanding, these things > typically link to the whole gemini capsules, which should already provide > author information, and I don't think date info is relevant here. I think there's been some misunderstanding - date and author etc don't have anything to do with webrings as you said. The issue is not that it would break pre-existing software, but that it > would make it less appealing to use, compared to new software which does > implement the new additions. This applies to clients and servers and > everything in between. That's the 'rift' I was talking about in my > original mail. > I understand your concern, and it's something we should aim to avoid, but this kind of mindset prevents innovation. If we stop creating new, or modifying old, because the old would get left behind, we will forever be stagnant. (To clarify, I'm talking in general there and not just about Gemini) # My conclusion on the metadata topic I think the discussion of the how (format and what it would affect) has been good, but we should stop with it untill a good why (reasoning and use case) has been found. (Sorry if this ends up as a HTML mail, I'm on mobile at current and for the life of me can't figure out how to disable HTML mode, boo GMail devs ?) > -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210223/902b 33a7/attachment.htm>
It was thus said that the Great nothien at uber.space once stated:
>
> I'm going to split it into two groups: metadata affecting presentation,
> and metadata about the document.
There is another group: metadata affecting navigation.
Years ago, there was an extention for Firefox (back when I think it was
just known as Mozilla) that would use metadata in the <HEAD> section of a
web page to construct a navigation bar for the site. The metadata included:
next next "page" in the collection
previous previous page in the collection
first first page in the collection
last last "page" in the collection
up up one level of the collection tree
top top level in the collection
home the entry page (might not be the same as top)
about about the collection
archive page listing each page in the collection
search search the collection
glossary list of terms used in the collection
copyright copyright status of page
canonical canonical link to page
Yes, these can all be just links on a page. But the idea was not to
clutter the page with these links, but construct a UI element with the
navigation items. This could include a navigation bar (what I experienced),
but it could also be a menu item, a popup menu, or keyboard shortcuts for
each each one, depending upon the client.
The Gemini portal at <https://portal.mozz.us> only gives us two of these:
up and top.
> # Metadata for the Document
>
> What's the /point/ of standardizing a format for providing metadata
> about a document? Seriously, I don't understand. What's the benefit of
> letting a client know who the author is? If you, an author, want users
> to know that you wrote something, just write "I wrote this". These
> kinds of proposals are unnecessary. If you want it to be read properly
> by a screen reader, just write in full sentences ('this was written on
> the 23rd of February'). Keep it open, prevent it from turning into a
> matter of convention, and think about how to solve problems /without/
> extending the specification in any way. Even if it's
> "backward-compatible", you're creating a rift in Gemini - see "Problems
> with Conventions" below.
Such metadata could include a summary of the page, keywords, copyright
status, location data (location here being the location the page is about,
not the location of the author or reader), time (when the page in question
was written, when it's about, etc.) in addition to the author, in a format
that is easy for a machine to recognize. A good example is a search engine
could use this information instead of having to attempt to identify it from
the text alone.
> # "It's Just A Suggestion/Idea"
>
> The problem with 'just' posting ideas and suggestions and proposals like
> these is that they waste everyone's time (including yours). Instead of
> trying to add new, unnecessary, and unwanted features to Gemini,
Unwanted by you, others might want it. I think there are better arguments
against this than just "don't do it." That does nothing to convince those
that want it to stop working on it. They might just go ahead and do it
anyway.
> start
> creating content within it! We (and I'm speaking for a lot of people
> here) are tired of dealing with new ideas from eager new Geminiauts who
> keep trying (consciously or unconsciously) to reinvent the Web.
Yes. And for the first year about the *only* topic being discussed was
the format for text/gemini. It is *still* being talked about, only not
quite so much.
> # The Problem with Conventions
>
> Conventions are naturally difficult because you're politely asking
> people to do something. This separates the Gemini userbase into people
> who have done that thing and people who haven't. If you want to create
> a new convention, /please/ think about the effect this can have,
> particularly with conventions involving presentation. As others have
> pointed out, every new convention threatens to make a split in the user
> base, and if anyone (user or site) can for any reason prefer one side
> over the other, you've begun the process of separation. Don't do that,
> because we're just going to have to shoot your shit down.
Having been on this list from the beginning, I can say that the majority
(I would say nearly all) of the proposals have not gone anywhere. Why?
Because it's easy to make a proposal, it's apparently impossible to get
anyone to actually *implenent* the damn things, even as a
"proof-of-concept". That people are lazy is an incredible filter.
There were two people who came into the mailing list (at different times),
incredulous that TLS was used. "It's horrible!" they said. "You should use
something better!" they said. A simple task of taking them at face value
and saying, "Okay. Show us! Implement a server and client so we can see
how much easier and better your ideas are," worked wonders. One simply
disappeared. The other actually did the work, and withdrew the idea
(because implementing crypto is not easy).
Now we have a much strong case for "Why TLS?" Just "shooting your shit
down" only serves to piss people off.
> # Conclusion
>
> Please stop.
It won't. In six months we'll have a new crop of people asking.
-spc
> On Feb 23, 2021, at 23:49, Sean Conner <sean at conman.org> wrote: > > Years ago, there was an extention <link rel> ? https://developer.mozilla.org/en-US/docs/Web/HTML/Element/link https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/rel ?0?
It was thus said that the Great Petite Abeille once stated: > > > > On Feb 23, 2021, at 23:49, Sean Conner <sean at conman.org> wrote: > > > > Years ago, there was an extention > > <link rel> ? > > https://developer.mozilla.org/en-US/docs/Web/HTML/Element/link > https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/rel Yes, that's the tag the extension used, but the extension itself created a UI element based off the <link rel> tags in the <head> section. -spc
On Tue, Feb 23, 2021 at 06:37:19PM +0100, Baschdel <baschdel at disroot.org> wrote a message of 65 lines which said: > One thing I don't really like with this one is, that we use English > keywords here and that for human readable text that is intended to > be attached to a file, that could be in any language and is not very > accessible to non-English speakers. > > A possible solution to that could be in unicode and (you guessed it, > didn't you?) emoji (yay!), at least those little pictures are > standardized and independent of the language(s) you speak. In think that believing pictures are culture-independant is an illusion. The same image will be meaningful for someone, meaningless for an other and offensive for a third. The proper solution is to have standard keys, and structured metadata, so the client program will be able to replace them with locally significant labels (like email clients do with Date:, Subject:, From:, etc). (For fun and thinking, someone actually proposed to replace HTTP status codes by emojis. I made a list of the proposals at <https://www.bortzmeyer.org/http-code-emoji.html>. It's in french but you can see the list of codes and the emojis that were actually proposed. Good luck for finding a proper one.)
> On Feb 23, 2021, at 23:57, Sean Conner <sean at conman.org> wrote: > >> >> <link rel> ? >> >> https://developer.mozilla.org/en-US/docs/Web/HTML/Element/link >> https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/rel > > Yes, that's the tag the extension used, link rel translates quite well into text/gemini: <link rel='alternate' type='application/atom+xml' href='posts.xml' title='Blog'> ? => posts.xml rel=alternate;type=application/atom+xml Blog ?0?
> On Feb 24, 2021, at 11:31, Stephane Bortzmeyer <stephane at sources.org> wrote: > > https://www.bortzmeyer.org/http-code-emoji.html Aha! Thanks for sharing! :D ?0?
On Tue, Feb 23, 2021 at 08:08:48PM +0100,
nothien at uber.space <nothien at uber.space> wrote
a message of 72 lines which said:
> They're not necessary.
Nothing is necessary (except eating and breathing) but metadata are
useful.
> What's the /point/ of standardizing a format for providing metadata
> about a document? Seriously, I don't understand.
This argument surprised me. All the people who professionally manage
documents use metadata. I didn't think it was necessary to explain
their uses. So, let's try;
> What's the benefit of letting a client know who the author is? If
> you, an author, want users to know that you wrote something, just
> write "I wrote this".
Using structured metadata allows you to search into documents those
written, by John Guy (or Alice Gal). grep or other tools for
unstructured searches don't help here since they cannot tell the
difference between a page written by Alice Gal and a page discussing
the life of Alice Gal.
Other examples of useful metadata: date of publication so you can
find, for instance, the most recent, or exclude those that are too old
/ too young, licence, so you can find "only documents under a free
licence", etc.
Basically, it is not because YOU don't use them and don't see the
point of them that nobody does.
> just write in full sentences ('this was written on the 23rd of
> February').
This is not parsable, so useless for programs.
> The problem with 'just' posting ideas and suggestions and proposals like
> these is that they waste everyone's time (including yours).
I strongly disagree. What's the point of this mailing list if not to
discuss ideas when some of them (may be most of them) will turn out to
be wrong? We can think of better tools for discussion, of course
(separate mailing lists, issue trackers, whatever), but we need a
place to receive and discuss ideas.
Otherwise, what will happen? Since the Internet is permissionless,
people will do it anyway. And probably in a worse way. If "we" (we
being "the Wise Gemini People" or "Gemini Experts" or something like
that) reject everything (or even if we are PERCEIVED as rejecting
everything), people will do it elsewhere and may be do it badly. We
cannot (and don't want to) prevent people from doing Gemini stuff
outside of the "Gemini Official Channels" but we can at least act in
good faith, and propose them a serious and documented way to have
proposals examined (and may be rejected, but not dismissed without a
serious examination).
> We (and I'm speaking for a lot of people here) are tired of dealing
> with new ideas from eager new Geminiauts
Then, the solution is for these people to stop subscribing to the
[spec] tag (or move to a separate mailing list, my personal opinion is
that we need several lists).
And new Geminauts are a good thing, this is the goal we try to reach.
> Read the spec, read the FAQ, read the companion documents, read the
> mailing list, and /understand/ the spirit of Gemini.
This is really patronizing. Most people who sent proposals on the
mailing list clearly know about Gemini and studied the matter
seriously. Of course, there are some guys sending stupid wild ideas
but they are a very small (and unavoidable) minority.
Your contempt is the kind of attitude which risk to turn away people,
either completely away from Gemini, or towards a de-facto fork.
> On Feb 24, 2021, at 13:09, Stephane Bortzmeyer <stephane at sources.org> wrote: > > there are some guys sending stupid wild ideas Thank you! ?0?
On Tue, Feb 23, 2021 at 05:49:19PM -0500,
Sean Conner <sean at conman.org> wrote
a message of 112 lines which said:
> Years ago, there was an extention for Firefox (back when I think it
> was just known as Mozilla) that would use metadata in the <HEAD>
> section of a web page to construct a navigation bar for the site.
> The metadata included:
Actually, it is a concrete form ("serialization") of links, which are
an abstract concept, and can be in HTTP headers ('Link:'), in HTML
text, in Atom feeds, etc.
The standard for links is RFC 8288
<gemini://gemini.bortzmeyer.org/rfc-mirror/rfc8288.txt>.
> next next "page" in the collection
> previous previous page in the collection
> first first page in the collection
All these are official standardized types of links, in the IANA
registry
<https://www.iana.org/assignments/link-relations/link-relations.xml#link-re
lations-1>. For
instance, "canonical" was registered in RFC 6596
<gemini://gemini.bortzmeyer.org/rfc-mirror/rfc6596.txt> to link to the
canonical URI of this resource.
> On Feb 24, 2021, at 13:24, Stephane Bortzmeyer <stephane at sources.org> wrote: > > https://www.iana.org/assignments/link-relations/link-relations.xml#link-relations-1 Beautiful. These could all be translated ???? to text/gemini's links. ?0?
On 2/24/21 12:31 AM, Oliver Simmons wrote: [snip] > # My conclusion on the metadata topic > > I think the discussion of the how (format and what it would affect) has > been good, but we should stop with it untill a good why (reasoning and use > case) has been found. [snip] One example: when the capsule's owner has included date metadata, then searches there can be expanded or narrowed according to date. The same for title, author, subject, or any other field that has been maintained throughout the capsule. With machine readable metadata in place, the system can then do the work when limiting searches. Another example: browsing through a 'tag cloud', also known as subject categories, is very common. That is one way of browsing through a set of subjects in document metadata and is a case where it is not niche. An example of when metadata is is not allowed or missing would be plain full-text searches. One well-known confound for full-text searching is when a page talks about a topic in great detail without actually including repetition of strings pertaining to that topic. A lot of technical writers within ICT know of this problem and pepper their writing with expected search terms. Writers, especially researchers, in other fields just write to the topic and might not even include the subject terms more than once if even that. Thus full-text searching is quite inaccurate, even with stemming, and does not scale well. The actual metadata content can be made up as needed, as in uncontrolled vocabulary, or it can conform to an agreed upon, restricted set, such as ERIC or LCSH. After capsules reach substantial size, both in number and length of documents, it becomes impractical to rummage for content manually and full-text becomes increasingly inaccurate. It gets even harder to do relevant searches if the content in the pages is all about the same topic or similar, overlapping topics which share vocabulary. There, without the fielded searches which document metadata enables, the material is effectively lost. So some of use-cases for document metadata deal with trying to retrieve material from largish capsules. /Lars
nothien at uber.space writes:
> I'm just going to quickly address everything about the metadata ideas
> / proposals:
>
> They're not necessary.
Hear, hear.
> # Conclusion
>
> Please stop.
Agreed. Or, at the very least, read every last metadata discussion in
the list archive, and understand why those discussions ended in the
proposed convention not being adopted *before* posting yet another
proposed convention.
--
Jason McBrayer | ?Strange is the night where black stars rise,
jmcbray at carcosa.net | and strange moons circle through the skies,
| but stranger still is lost Carcosa.?
| ? Robert W. Chambers,The King in Yellow
> On Feb 24, 2021, at 14:32, Jason McBrayer <jmcbray at carcosa.net> wrote: > > understand why those discussions ended in the proposed convention not being adopted ?To understand recursion, you must first understand recursion? ?0?
On Tue, Feb 23, 2021 at 4:16 AM Lars Nood?n <lars.nooden at gmx.com> wrote:
The metadata does not have to be marked up in a difficult manner to be
> both machine readable and human readable. Borrowing from the link
> syntax [3],
>
> =:[<whitespace>]<TERM><whitespace><METADATA>
>
> which could look like this in the body, but would be up to the client as
> to how it is dealt with.
I agree that this syntax makes sense and is easy to read: as you say, it
degrades to plain text nicely, so there is no pressure to do anything in
particular with it. However, it makes the information available to search
engines in such a way that it is possible to find documents.
VERY IMPORTANT: I do *not* think that this convention needs to be part of
the text/gemini spec, because understanding it is not a requirement for
clients. One client (for human use) can render an =: line as an ordinary
gemtext line; another client can ignore such lines; a smarter client can
render them but translate "language en" into "English language" and "format
text/html" into "HTML".
Search engines and other metadata processors have the same three choices.
A simple approach to making use of metadata is to treat "creator Crowder,
Mary" in the index as if it were "creator:Crowder creator:Mary", thus
allowing people to search for these things Google-style, without confusing
them with subject:Crowder.
Here's some lines in the above format for characterizing one of Project
Gutenberg's books. This is an extensive example: I do not mean that
typical metadata creators will use anything this complex.
=: pgterms.ebook 22222
=: creator Crowther, Mary Owens
=: language en
=: subject Etiquette
=: type Text
=: title How to Write Letters (Formerly The Book of Letters) A Complete
Guide to Correct Business and Personal Correspondence
=: issued 2007-08-02
=: lcc PE
=: rights Public domain in the USA
=: publisher Project Gutenberg
=> https://www.gutenberg.org/files/22222/22222.txt =: format text/plain;
charset=us-ascii =: size 392109 bytes
=> https://www.gutenberg.org/ebooks/22222.kindle.images =: format
application/x-mobipocket-ebook =: size 3304322 bytes
=> https://www.gutenberg.org/files/22222/22222-8.txt =: format text/plain;
charset=iso-8859-1 =: size 392115 bytes
=> https://www.gutenberg.org/ebooks/22222.kindle.noimages =: format
application/x-mobipocket-ebook := size 917781 bytes
=> https://www.gutenberg.org/files/22222/22222-h/22222-h.htm := media-type
text/html; charset=iso-8859-1 =: size 508856 bytes
=> https://www.gutenberg.org/ebooks/22222.rdf := format application/rdf+xml
Note that some metadata lines are actually links to other formats of this
book, so a metadata-aware processor would look at links and see that after
the URL there is an "=:" and process it as metadata. For this reason, I do
not think that metadata lines should be required to be in a fixed place in
the document: I have put the links at the end because they are most likely
less important to people than the rest of the metadata.
In addition, "=:" lines can be joined together if they are related, with a
second "=:" on the same line, since that is unlikely to be part of the
value. This provides the benefit of structured metadata with a depth of 1.
Note to Lars and other metadata people: I have simplified
"dcterms.creator" to "creator" and "dcterms.subject.LCSH" to "subject", so
as not to be too scary-looking. I have also omitted some of the available
formats of this particular book.
John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org
Unless it was by accident that I had offended someone, I never apologized.
--Quentin Crisp
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210224/19c9
3334/attachment.htm>
Stephane Bortzmeyer <stephane at sources.org> wrote: > Using structured metadata allows you to search into documents those > written, by John Guy (or Alice Gal). grep or other tools for > unstructured searches don't help here since they cannot tell the > difference between a page written by Alice Gal and a page discussing > the life of Alice Gal. > > Other examples of useful metadata: date of publication so you can > find, for instance, the most recent, or exclude those that are too old > / too young, licence, so you can find "only documents under a free > licence", etc. I'm sorry, I wasn't considering the case of gemtext as a storage format, only of it as a communication format. 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. These 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). > Otherwise, what will happen? Since the Internet is permissionless, > people will do it anyway. And probably in a worse way. If "we" (we > being "the Wise Gemini People" or "Gemini Experts" or something like > that) reject everything (or even if we are PERCEIVED as rejecting > everything), people will do it elsewhere and may be do it badly. We > cannot (and don't want to) prevent people from doing Gemini stuff > outside of the "Gemini Official Channels" but we can at least act in > good faith, and propose them a serious and documented way to have > proposals examined (and may be rejected, but not dismissed without a > serious examination). I ... didn't think about this.
On Wed, Feb 24, 2021 at 8:36 AM Petite Abeille <petite.abeille at gmail.com> wrote: > ?To understand recursion, you must first understand recursion? > And to understand anything about Algol 68 (the programming language) you must first understand everything about Algol 68. Fortunately, this recursion is broken: you don't have to understand everything *in depth* to understand any one thing in depth. Consequently, the tutorial "Algol 68 with fewer tears" gives you a shallow introduction to the whole language, and having read that you can read any of the following sections on particular topics. John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org Andrew Watt on Microsoft: Never in the field of human computing has so much been paid by so many to so few! (pace Winston Churchill) -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210224/9382 2e7b/attachment.htm>
On Tue, Feb 23, 2021 at 05:49:19PM -0500,
Sean Conner <sean at conman.org> wrote
a message of 112 lines which said:
> Having been on this list from the beginning, I can say that the
> majority (I would say nearly all) of the proposals have not gone
> anywhere. Why? Because it's easy to make a proposal, it's
> apparently impossible to get anyone to actually *implenent* the damn
> things, even as a "proof-of-concept". That people are lazy is an
> incredible filter.
The metadata proposal is very simple and I doubt that implementation
is a real obstacle.
Proof-of-concept: I did it in Agunua.
=> https://framagit.org/bortzmeyer/agunua/-/commit/b1eda7c6b4e7e1d210e97f96
f51b42a3535ae71f The actual commit, to show it is very simple
=> gemini://gemini.bortzmeyer.org/gemini/metadata.gmi The documentation, and examples
```
% ./agunua --display-metadata
gemini://gemini.bortzmeyer.org/gemini/example-metadata-correct.gemini
{'last-modified': time.struct_time(tm_year=2021, tm_mon=2, tm_mday=24,
tm_hour=0, tm_min=0, tm_sec=0, tm_wday=2, tm_yday=55, tm_isdst=-1),
'author': 'St?phane Bortzmeyer',
'license': 'CC-BY-SA',
'keywords': 'metadata gemini gemtext'}
```
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://lists.orbitalfox.eu/archives/gemini/attachments/20210224/583d 386d/attachment.htm>
On Wed, Feb 24, 2021 at 03:08:32PM +0100, nothien at uber.space <nothien at uber.space> wrote a message of 34 lines which said: > I'm sorry, I wasn't considering the case of gemtext as a storage > format, only of it as a communication format. Me too. > 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. Like John Cowan explained, you have a very restricted view of what a Gemini client is. A crawler, for instance, is a /client/. But even with "clients for interactive human use" such as Amfora or Lagrange, metadata could be useful, for instance to help to bookmark resources, or to present them differently. > I ... didn't think about this. This is what happened to the Web with the WHATWG (which, in all fairness, was a complicated issue but one of the main reported problems was that the W3C was not listening).
Hi all, First time posting on this mail list or any mail list for that matter. Let me know if I'm responding on it incorrectly. Just sharing my thoughts on metadata. I personally don't think metadata should be included in the same way that HTML uses metadata with <meta> tags. Metadata is only useful if something about the file format demands it be meta. For audio or video formats I can see this being the case as aside from file name(which would be a very messy and not very universal way to include it) there's not much a person can do. Gemtext doesn't suffer this issue, a person can write the date written, published and the author(s if there's more than one) in a way that fits best with the document. If this data is omitted, then usually the author chose to omit it as that data isn't relevant to the content displayed on the page. On this point, a lot of the metadata included in websites, is very much a victim of the same thing, it should be data included directly with the content if it's relevant... and it seems a lot of the metadatas that are included are completely irrelevant to the content. Convince me otherwise Only benefit seems to be to bots/softwares involving gemtext such as clients, search engines or scrapers- and it would require creating a standard for the metadata that someone would have to maintain, and outreach to get people to adopt the standard in writing gemtexts and in writing their clients- plus it encroaches a little bit on how long a person should spend to write a gemini client of their own. That's a lot of stuff just to have metadata that should be included as data in the document. For the reasons above, I'm relatively indifferent to metadata but think it's a fair lot of time to pursue(at least to the same degree as <meta> tags have gone). Personally, if a person was to create and adopt a standard, I'd use it if it's useful AND human-readable. Cheers mates, - Aaron
Stephane Bortzmeyer writes:
> This is what happened to the Web with the WHATWG (which, in all
> fairness, was a complicated issue but one of the main reported
> problems was that the W3C was not listening).
To be fair, though, the products of the WHATWG have been almost
uniformly a disaster for the open web, and a way for Google to codify
Chrome as the unofficial browser reference implementation.
--
Jason McBrayer | ?Strange is the night where black stars rise,
jmcbray at carcosa.net | and strange moons circle through the skies,
| but stranger still is lost Carcosa.?
| ? Robert W. Chambers,The King in Yellow
> On Feb 24, 2021, at 15:10, John Cowan <cowan at ccil.org> wrote: > > you don't have to understand everything *in depth* to understand any one thing in depth. Hurray! We broke the chain! WE ARE FREE FROM RECURSION! :D "I don't often repeat myself, but when I do, I use recursion." ?0?
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 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. > 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 licensed under...". Metadata need not be structured for human users to understand it. 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 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. -- pjvm
On Wed, 24 Feb 2021 at 14:36, aaronleonard <aaronleonard at risingthumb.xyz> wrote: > > Only benefit seems to be to bots/softwares involving gemtext such as > clients, search engines or scrapers- and it would require creating a > standard for the metadata that someone would have to maintain, and > outreach to get people to adopt the standard in writing gemtexts and in > writing their clients- plus it encroaches a little bit on how long a > person should spend to write a gemini client of their own. That's a lot > of stuff just to have metadata that should be included as data in the > document. > As with most things in Gemini, this would be entirely optional. Either the =: or my format wouldn't take much longer to code into clients, as they are both based on existing features and follow all of Gemtext's simplicity rules on line-by line etc. Outreach luckily isn't much of an issue - most of the people that will need to know are on this mailing list, and if/once it is a thing it will be documented. I don't understand your "maintaining" a standard point, it's a standard, it should not be changed once it's been decided on (except minor adjustments if required). > > For the reasons above, I'm relatively indifferent to metadata but think > it's a fair lot of time to pursue(at least to the same degree as <meta> > tags have gone). Personally, if a person was to create and adopt a > standard, I'd use it if it's useful AND human-readable. > It should DEFINITElY be human-readable, Gemini (the protocol + text format) is supposed to be a "human-style" thing.
On Wed, 24 Feb 2021 at 16:25, 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. > SEO would potentially be worse without metadata, as is obvious whenever you use the web. The first search results are often articles full of "fluff", cooking recipes will for some reason have a backstory, this isn't the metadata, this is the document itself being full of junk. The opposite is true though, people could use metadata to their advantage, but with it being structured it's easier to filter the junk out, and it also makes adding junk a bit harder. I've never done SEO myself - so I may be entirely wrong - but this is just my perspective on it. > > 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. > Someone searching for freely-licenced (etc) documents is going to have a hard time in that case, they would have to go through every document manually to find the license. Having it always at the end would be faster for people manually reading, and would mean search engines/similar could just be asked to filter out licenses they don't want (or do want). > > 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. > Agree - It certainly shouldn't be used *everywhere*, at least not to a large extent. I'm going to say a typical page would have around MAXIMUM ~3/4 lines, but Bill Gates also said 640K would be enough so who knows. > > 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. > :) Also, I've thought of a great use - email archives. Data could be added upon archival by whatever's archiving it (not by the people writing emails - that would be stupid). Searching them would be made easier if you could just tell your searcher to filter to this: ^^^ email from: oliversimmo at gmail.com from-name: Oliver Simmons reply-to: blah blah subject: [SPEC] Backwards-compatible metadata in Gemini (this would probably make more sense as the page h1, but whatever)
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/5fa2 e72e/attachment-0001.htm>
On 24/02/2021 19:18, Oliver Simmons wrote: > Someone searching for freely-licenced (etc) documents is going to > have a hard time in that case, they would have to go through every > document manually to find the license. > > Having it always at the end would be faster for people manually > reading, and would mean search engines/similar could just be asked to > filter out licenses they don't want (or do want). I don't think it would be a realistic expectation that all or even a majority of authors will be including any given structured metadata field in their pages. So when searching the whole Geminispace, restricting a search to results with a certain value for the "license" field will never be very effective. You have to either exclude or include results that have no license field at all. In the first case you don't know what you're missing, while in the second case you get lots of things you don't want. Also, some might put license information in a "license" field, while others might put it in "rights". The license may have multiple different names and abbreviations. These smaller problems could be combatted with more conventions, but then metadata conventions would become ever more complicated. Basically, I think a metadata convention is of rather limited use for the purpose of searching, unless you know that the set of articles in which you're searching is actually using that convention, and in a consistent way. And I think it would be hubris to expect most of the Geminispace to start using such a convention, let alone consistently. -- pjvm
On Wed, 24 Feb 2021 at 19:07, John Cowan <cowan at ccil.org> wrote: > > 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===== [...] > =====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: > [...] > > 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. > It appears you missed an important part of the key/value form: the toggle line. A toggle line would be used (I suggested ^^^, but there may be a better one), and it would be enable-only, there is no toggle off. (extra toggles must be ignored by clients) This enforces putting it at the end of a file, and prevents mixing it with regular content, as being able to mix it would make Gemini awfully easy to extend. After the toggle the only acceptable lines would be either empty, or metadata. Example: # My lovely example Hello, and welcome to example text. => /fooo Bar! ^^^ key: value another-key: another-value Here was my original email where I explained how I thought it would work very roughly: => gemini://gemi.dev/gemini-mailing-list/messages/005420.gmi
On Wed, 24 Feb 2021 at 19:15, PJ vM <pjvm742 at disroot.org> wrote: > > I don't think it would be a realistic expectation that all or even a > majority of authors will be including any given structured metadata > field in their pages. So when searching the whole Geminispace, > restricting a search to results with a certain value for the "license" > field will never be very effective. You have to either exclude or > include results that have no license field at all. In the first case you > don't know what you're missing, while in the second case you get lots of > things you don't want. Very good point, I hadn't considered that. One way (metadata), it's easier to do, but people that don't use it will be hidden or mixed in. The other, everyone is equal, but it's harder to do. Unfortunately I don't think there's much of a solution to this :/ > Also, some might put license information in a "license" field, while > others might put it in "rights". The license may have multiple different > names and abbreviations. These smaller problems could be combated with > more conventions, but then metadata conventions would become ever more > complicated. Whilst it's true anyone could use any key/values, I would hope that we are civilised enough to be able to agree on what keys and values we use. I'm a contributor to OSM, and their saying goes: > Feel free to invent new tags! Though it is not "feel free to ignore existing tagging schemes". Simple. if you start using your own key/value, nothing is going to support it, so you might as well use what everyone else uses. BUT, as is obvious with OSM, if we don't get the keys/values organised
> On Feb 24, 2021, at 20:16, PJ vM <pjvm742 at disroot.org> wrote: > > So when searching the whole Geminispace, > restricting a search to results with a certain value for the "license" > field will never be very effective. Meh. This is a very bogus argument. It's not either 100%, or nothing. It's a shade of grey in between. FWIW, I would suggest to guide people who would like to provide metadata to do it in an idiomatic Gemini way. Whatever this might be. Stubborn tunnel vision and denial is not helping anyone. ?0?
> On Feb 24, 2021, at 20:18, Oliver Simmons <oliversimmo at gmail.com> wrote: > > It appears you missed an important part of the key/value form: the toggle line. To be candid: this is a terrible proposal. Terrible. Why reinvent the wheel? Badly? It's not even very idiomatic to Gemini. This is really not good at all. My opinion, FWIW, it's my personal opinion that text/gemini should simply provide guideline on how to incorporated the last 20+ years of Web metadata. And that's that. Don't reinvent that specific wheel. Just use it, if so inclined. Otherwise, move on. ?0?
Still don?t get why a Gemini user would care about search engines and other tools to publish content but maybe I?m alone in this crowd and personal branding is the only thing that matter anyway. ? julienxx
> On Feb 24, 2021, at 21:04, Julien Blanchard <julien at typed-hole.org> wrote: > > why a Gemini user would care You? Julien Blanchard? I don't care if you care or not. Your choice. I personally do care. For my very own purpose. Cristal clear? ?0?
On 2/24/21 9:16 PM, PJ vM wrote: [snip] > ... unless you know that the set of articles in > which you're searching is actually using that convention, > and in a consistent way. [snip] It is a matter of scope and it is why the use of document metadata is generally found only in-house for local search and indexing functionality: Only you have control over your own documents and the presence and quality of their metadata. What goes into the metadata is a different topic than the specification for encoding it. So it is possible for groups with common sets to collaborate. Or not. In-house, there is no substitute for the ability to browse or search specific fields when retrieving from a pool of in-house documents. A simple specification for how to annotate key-value pairs is all that is needed. Nothing more. A major benefit from standardized markup for key-values is that any server-side software for indexing, browsing, and searching is easier to share. Think htdig but for a Gemini capsule. Through the discussion here I am starting to realize the importance of having a possibility for capsules to choose whether to add metadata to their own documents. Otherwise, there is a very low upper limit on the number of documents they in practice are able to manage and make discoverable. /Lars
On 2/24/21 9:34 PM, Oliver Simmons wrote: [snip] > Whilst it's true anyone could use any key/values, I would hope that we > are civilised enough to be able to agree on what keys and values we > use. [snip] I agree, if that is about settling on the way of writing arbitrary key-value pairs within Gemini documents. That would be something analogous to what would be the meta element in XHTML:' <meta name="..." content="..." /> The spec there provides the element. The people using the spec fill in the data themselves through their own choice. It is then up to them to use or write software on their site which takes advantage of it to offer one or more ways to navigate the accrued metadata. Or not. The actual contents of the key-value pairs, the actual metadata itself, would not be part of the spec, not even the keys. It would not be appropriate to try to impose a custom vocabulary or even any existing schemes like the Library of Congress Subject Headings (LCSH), Medical Subject Headings (MeSH), Universal Decimal Classification (UDC), L??v, or any other vocabulary. /Lars
>> On Feb 24, 2021, at 21:04, Julien Blanchard <julien at typed-hole.org> wrote: >> >> why a Gemini user would care > > You? Julien Blanchard? I don't care if you care or not. Your choice. I personally do care. For my very own purpose. Cristal clear? > > ?0? I meant someone that just wants something out available to read for fellow cool protocol users but you?re right I?m nobody, ignore, just giving out a thought... ? julienxx
> On Feb 24, 2021, at 21:20, Julien Blanchard <julien at typed-hole.org> wrote: > > I meant someone that just wants something Who is that someone? Neither you, nor me, apparently. This list keeps on harping on that mythical "someone" archetype. Who is it? And who decides? And why should anyone care? Rhetorical. ?0?
> Le 24 f?vr. 2021 ? 21:25, Petite Abeille <petite.abeille at gmail.com> a ?crit : > > Who is that someone? Neither you, nor me, apparently. > > This list keeps on harping on that mythical "someone" archetype. > > Who is it? There is already a lot of content so I?d say anyone that uses the protocol to publish something, every capsule you can see on Capcom, Spacewalk... and the others you can only stumble upon, mines, your(s)? > And who decides? And why should anyone care? Dunno, I guess I expected this protocol was for humans to publish stuff first and computed stuff around it was a possibility, not a goal but apparently I?m wrong. (Really sorry Oliver for polluting your proposal)
> On Feb 24, 2021, at 22:13, Julien Blanchard <julien at typed-hole.org> wrote: > > There is already a lot of content so I?d say anyone that uses the protocol to publish something, every capsule you can see on Capcom, Spacewalk... and the others you can only stumble upon, mines, your(s)? And how is this conversation impacting these existing Gemini users whatsoever? No one is forcing anything on anyone. This is all between consenting adults. If you don't want annotations/metadata in your text/gemini, just don't do it ? and go away in peace your merry way. But do not tell /me/ what I want or not. This decision is up to me. Alone. It's not for you to make in my name. Thanks. ?0?
Hah, we need like a "why doesn't Gemini * FAQ" and a "why doesn't gemtext include * FAQ" >Date: Wed, 24 Feb 2021 08:32:30 -0500 >From: Jason McBrayer <jmcbray at carcosa.net> >To: gemini at lists.orbitalfox.eu >Subject: Re: [SPEC] Backwards-compatible metadata in Gemini >Message-ID: <87czwpa8wh.fsf at cassilda.carcosa.net> >Content-Type: text/plain; charset=utf-8 > > >nothien at uber.space writes: > >> I'm just going to quickly address everything about the metadata ideas >> / proposals: >> >> They're not necessary. > >Hear, hear. > >> # Conclusion >> >> Please stop. > >Agreed. Or, at the very least, read every last metadata discussion in >the list archive, and understand why those discussions ended in the >proposed convention not being adopted *before* posting yet another >proposed convention. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
> On Feb 24, 2021, at 22:31, peteyboy at sdf.org wrote: > > Hah, we need like a "why doesn't Gemini * FAQ" and a "why doesn't gemtext include * FAQ" Nah. You cannot control the use of text/gemini. This will never go away. It's already a meta-thread on its own. It will not die, just foster its pestilence further. Best to get ahead of it once and for all. ?0?
On 2021-02-24 01:31PM, peteyboy at sdf.org wrote: > Hah, we need like a "why doesn't Gemini * FAQ" and a "why doesn't gemtext include * FAQ" We have gemini://when.willgemini.support courtesy of Ren? Wagner. In this case: gemini://when.willgemini.support/?metadata ~nytpu -- Alex // nytpu alex at nytpu.com GPG Key: https://www.nytpu.com/files/pubkey.asc Key fingerprint: 43A5 890C EE85 EA1F 8C88 9492 ECCD C07B 337B 8F5B https://useplaintext.email/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210224/34a6 a1ff/attachment.sig>
> On Feb 24, 2021, at 23:17, Alex // nytpu <alex at nytpu.com> wrote: > > courtesy of Ren? Wagner The hairdresser? ? No disrespect to hairdressers, but why would his opinion have any special authority on the matter? ? https://thestudio.ch ?0?
On 2021-02-24 11:53PM, Petite Abeille wrote:
> The hairdresser?
No, I'm obviously talking about the soccer^Wfootball player, he
maintains a strong stance on fledgling internet protocols:
https://en.wikipedia.org/wiki/Ren%C3%A9_Wagner
In actuality I'm talking about the Ren? Wagner that participates on this
mailing list quite regularly, no need to be snide. Here's the original
message (in this case it was in response to previous threads on escaping
and italics, some other unnecessary proposals that pop up every so often):
gemini://gemi.dev/gemini-mailing-list/messages/003251.gmi
> ...why would his opinion have any special authority on the matter?
Why would their opinion against this change[a] have less authority than
the people who are advocating for this change?
[a]: not that they've expressed any, the site provides a generic
response to "metadata"
~nytpu
--
Alex // nytpu
alex at nytpu.com
GPG Key: https://www.nytpu.com/files/pubkey.asc
Key fingerprint: 43A5 890C EE85 EA1F 8C88 9492 ECCD C07B 337B 8F5B
https://useplaintext.email/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210224/73c5
92fb/attachment.sig>
> On Feb 25, 2021, at 00:18, Alex // nytpu <alex at nytpu.com> wrote: > > gemini://gemi.dev/gemini-mailing-list/messages/003251.gmi Nothing to see there. Same juvenile snark. > Why would their opinion against this change[a] have less authority than > the people who are advocating for this change? It's an equal playing field. All are welcome. Hairdressers included. ?0?
On Wed, 24 Feb 2021, 21:14 Julien Blanchard, <julien at typed-hole.org> wrote: > Dunno, I guess I expected this protocol was for humans to publish stuff first and computed stuff around it was a possibility, not a goal but apparently I?m wrong. You're correct, Gemtext is designed to be a human-centric format, but also very easy for computers to parse. Whilst it's uses might not all be, the metadata should also follow this. Think of metadata as like the front and back page of a book, it tells you some extra info about it, but isn't the contents itself. In a virtual bookstore (Gemini space) machines can take advantage of what's on the book's covers and info pages to help you navigate or improve how you interact with the books. > (Really sorry Oliver for polluting your proposal) Please don't worry about this, this is a mailing list and discussion is what we do. This isn't just for *my* proposal, we should be collaborating to create something that fits everyone (or deciding we don't need it or something else is better). Most of what I'm trying to say is either correcting people, and discussing the *formats* for the metadata. There are really multiple discussions going on here: 1. The format and spec for metadata. 2. What would be allowed/counts as metadata? 3. What would we use it for? / Is it really something we should have? 1&2 are linked together tightly. 2&3 are also linked. 1&3 are seperate. Which creates quite the ruckus ? I've done that thing where I blabber about unnecessary stuff again so I'll stop here. (Again sorry about HTML mail, the GMail mobile app is balls, gonna see if I can find something else) -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210224/43c7 5b91/attachment-0001.htm>
> On Feb 25, 2021, at 00:48, Oliver Simmons <oliversimmo at gmail.com> wrote: > > 1. The format and spec for metadata. Perhaps it would be educative to take a look at the structure of your very own email, as per Message-ID: <CAFkF85aLmBEg5NM_a4+dnwDOWqsaktjOBoba3wT1CXuGasm=QA at mail.gmail.com>. It looks a bit like this: Content-Type: multipart/alternative; boundary="000000000000ac6dd305bc1dadab" --000000000000ac6dd305bc1dadab Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable --000000000000ac6dd305bc1dadab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable --000000000000ac6dd305bc1dadab-- Plain text. Rather self-explanatory. This is called MIME, as in Multipurpose Internet Mail Extensions: https://en.wikipedia.org/wiki/MIME It's one of the fundamental building block of the internet, as we know it today. Even HTTP uses it. Why would text/gemini need to reinvent it? Why not use it just the way it is? ?0?
Oliver Simmons <oliversimmo at gmail.com> writes:
> On Wed, 24 Feb 2021 at 19:15, PJ vM <pjvm742 at disroot.org> wrote:
>
> Whilst it's true anyone could use any key/values, I would hope that we
> are civilised enough to be able to agree on what keys and values we
> use.
>
> I'm a contributor to OSM, and their saying goes:
>> Feel free to invent new tags! Though it is not "feel free to ignore
existing tagging schemes".
> Simple. if you start using your own key/value, nothing is going to
> support it, so you might as well use what everyone else uses.
> BUT, as is obvious with OSM, if we don't get the keys/values organised
> **from the start**, we will end up with different ways of doing that
> same thing and, and I think anyone would agree, that is awful to work
> with. If we get keys/values organised at the start though this isn't
> really an issue.
I think this is a bogus point. I never contributed to OSM, but from
what you're saying I suppose they use something like XML/SGML/... Those
things are *meant* for extensions (the 'X' in XML stands for that),
whilst everything around Gemini is focused on non-extensibility and
simplicity, even at cost of missing features.
Let's think about that again, for a moment.
There are various people here, myself included, that would like to add
"only a small change" to the spec. Everyone has their 20% of things
that would like to add to Gemini or text/gemini[0] because with that it
would be, oh, so much better.
But instead of thinking about what we may add, let's think about what we
have:
- we have TLS because it's fundamental to guarantee confidentiality
between servers and clients
- we have status codes, because a page that says "an error occurred"
or "certificate required" cannot be interpreted correctly otherwise
- we have a media-type in the response, so users know what kind of
document they're getting
- we have links, so we can connect different pages, even across
different capsules
- we have titles, paragraphs, quotes and lists to express and organize
our writings
- we have pre-formatted blocks to allow certain types of
explanations/presentations that otherwise would have been impossible
(how do we teach how to write text/gemini in text/gemini?)
>From here you can notice how humanly-centric Gemini is. We don't have
features for bots (more than what it's absolutely needed at least) and
even more importantly we only have basic and necessary stuff. There's
no fluff in Gemini.
If you think about it, we only have features that we can't objectively
live without (no links? no paragraphs? no media-types? ...) while we're
lacking various things that would be "nice to have".
We don't have headers, because with them comes extensibility and
complexities, and we're getting just fine without them. We don't have
inline formatting because it's difficult to handle client-side and we're
doing really fine without, etc.
Now, replying to the two proposals specifically, I'm against both of
them for various reason:
- we're doing fine without them, so we can continue do so
- they're bring extensibility which is against the "spirit" of Gemini
(at least until now) and thus dangerous.
Specifically they have their own faults in my opinion:
- the one adding the line-type =: (or whatever): you have to parse the
whole document to extract the metadata and it allows for possibly
unreadable text/gemini files[1]
=: foo: bar
# a document
=: title: a document
=: author: Omar Polo
lorem ipsum dolor sit amet...
=: x-best-viewed-with: tinmop
Quia ullam quae repellat. Dicta occaecati beatae qui...
=: script: gemini://evil.corp/analytics.gms
=: document-class: article
=: x-song-im-listening-title: "Norwegian Wood"
=: x-song-im-listening-by: "The Beatles"
=: licence: CC-BY-SA
another pragraph? dunno
--
text: CC-BY-SA, code: MIT (a lot of capsules have lines like this)
=: prefetch-page: /some/other/page
=: x-some-even-more-funny-meta-because-why-not yay!
...
=: preferred-color: black-text-on-white-background
An user on a non-sophisticate client cannot (easily) understand
that. It's just full of bloat. (with non-sophisticate I mean
something more elaborate than "printf $url\r\n | nc ... | less".)
- (your?) proposal of the ^^^ toggle line, while eastetically nice
(I'll give you that!) has the additional drawbacks of breaking the
concatenation. As things stands, I know I can
cat file1.gmi file2.gmi ... > result.gmi
and obtain a valid text/gemini file. With your proposal, I have to
write a parser that analyzes every file. There are a lot of people
who uses simple scripts/makefiles to generate their capsules with
standard UNIX tools, this would (possibly) break them. And even
worst, the cat(1) example I gave before will break only *sometimes*,
depending on the content of the files. (let's not talk about how to
merge metadata from multiple files...)
Also, the examples you gave in support of your proposals seems bogus
too. Serving a mailing list archive over Gemini? Cool, but why convert
the mails to text/gemini? Wrapping them in ``` (with headers visible)
or serving them "raw" is not enough?
What I think is missing in all these discussions is a valid reason to
outweight the cons.
However, I feel that denying and turning down feature requests for
addition is not a good thing. I think we should reflect on what's the
actual problem and solve it, because this smells like a XY problem[2] to
me.
If we want to give people ways to manage their local data, maybe because
they want to search across documents or do some kind of publications
over Gemini, then centralising metadata in one place is an option.
That's what I'm currently doing with my blog: all entries are pure
text/gemini files and there's a posts.edn[3] file with all the metas
(title, tags, date, song I was listening to, relevant XKCD, ...), and
I'm happy with the outcome. It's easy to generate pages for either the
Web or Gemini, and I can easily adjust the "layout" when I want to.
If we want to build a better GUS I don't think that adding metadata to
text/gemini will solve anything, it will actually make things worst.
The point is, you can't trust 3rd-parties metadata. Sure, I can stick a
description of "About the interpretation of the Will of power in
Nietzsche" with tags "philosophy, nietzsche, will-to-power" and a
category of "essay", but you cannot trust me to talk about those
arguments in the page, maybe it only contains link to pics of cute
kittens :)
Why I think metadata will make things like GUS worst? While full-text
search is not without its drawbacks, as Bortzmeyer reminded us, people
will abuse the metadata to "go up" in the search results, and the
outcome of that is crystal-clear on the Web, other than making the life
of who makes a SE more difficult, as now they also have to try to
understand if the metadata is actually relevant or not.
(sorry for the long mail)
[0]: mine? I would love to have a syntax for definition lists and
3-levels of un-ordered lists.
[1]: .gms is GeminiScript of course. A minimal, non-estensibile and
simple scripting language for your preferred client, hoping it
doesn't lack support for it /s
[2]: When people asks for Y because they think that will solve the
problem X, instead of asking directly for X.
https://en.wikipedia.org/wiki/XY_problem
[3]: edn is like json, but for clojure, kinda.
> On Feb 25, 2021, at 10:16, Omar Polo <op at omarpolo.com> wrote: > > There's no fluff in Gemini. Actually... you should take a look at Mercury... a streamlined version of Gemini... courtesy of Solderpunk himself: https://portal.mozz.us/gemini/gemini.circumlunar.space/users/solderpunk/gem log/the-mercury-protocol.gmi The 'approachable & frugal & composable' thread may be of interest as well: gemini://gemi.dev/gemini-mailing-list/messages/001237.gmi ?0?
On Thu, 25 Feb 2021 at 09:17, Omar Polo <op at omarpolo.com> wrote: > > I think this is a bogus point. I never contributed to OSM, but from > what you're saying I suppose they use something like XML/SGML/... Those > things are *meant* for extensions (the 'X' in XML stands for that), > whilst everything around Gemini is focused on non-extensibility and > simplicity, even at cost of missing features. > I'm not talking about XML/etc, that's an entirely separate topic. I'm talking about the key=value system. > But instead of thinking about what we may add, let's think about what we > have: > - we have TLS because it's fundamental to guarantee confidentiality > between servers and clients > - we have status codes, because a page that says "an error occurred" > or "certificate required" cannot be interpreted correctly otherwise > - we have a media-type in the response, so users know what kind of > document they're getting These are all about the protocol, not Gemtext. > - we have links, so we can connect different pages, even across > different capsules > - we have titles, paragraphs, quotes and lists to express and organize > our writings > - we have pre-formatted blocks to allow certain types of > explanations/presentations that otherwise would have been impossible > (how do we teach how to write text/gemini in text/gemini?) > > From here you can notice how humanly-centric Gemini is. We don't have > features for bots (more than what it's absolutely needed at least) and > even more importantly we only have basic and necessary stuff. There's > no fluff in Gemini. > If you think about it, we only have features that we can't objectively > live without (no links? no paragraphs? no media-types? ...) while we're > lacking various things that would be "nice to have". Specification section 5.5 - Advanced line types: > The following advanced line types MAY be recognised by advanced clients. > Simple clients may treat them all as text lines as per 5.4.1 without any loss of essential function. I agree though, unnecessary features shouldn't be added. > We don't have headers, because with them comes extensibility and > complexities, and we're getting just fine without them. We don't have > inline formatting because it's difficult to handle client-side and we're > doing really fine without, etc. Extensibility *is* an issue with metadata, but this applies to Gemtext as a whole due to its nature of being text-based, who's to stop someone from creating a new line type that their client understands? Standardising metadata now would make people less likely to add it in their own weird formats in the future, and laying down solid rules of what is and isn't allowed as metadata in Gemini documents helps in avoiding (it doesn't prevent entirely) people from adding styling or other weird things in the future. On the opposite side, adding metadata would make it easier for people to add new things like styling, if they ignore what it's intended for. Neither side of the argument really wins here in my eyes. > - (your?) proposal of the ^^^ toggle line, while eastetically nice > (I'll give you that!) has the additional drawbacks of breaking the > concatenation. As things stands, I know I can > > cat file1.gmi file2.gmi ... > result.gmi > > and obtain a valid text/gemini file. With your proposal, I have to > write a parser that analyzes every file. There are a lot of people > who uses simple scripts/makefiles to generate their capsules with > standard UNIX tools, this would (possibly) break them. And even > worst, the cat(1) example I gave before will break only *sometimes*, > depending on the content of the files. (let's not talk about how to > merge metadata from multiple files...) I hadn't thought about that, a very valid point. But I think allowing metadata to be mixed in with text, as the other format allows, is a bigger drawback than enforcing putting it at the end of files and breaking concatenation. Having both the opening and closing toggle lines would fix this, but it would allow moving and splitting up metadata thought files again. > Also, the examples you gave in support of your proposals seems bogus > too. Serving a mailing list archive over Gemini? Cool, but why convert > the mails to text/gemini? Wrapping them in ``` (with headers visible) > or serving them "raw" is not enough? Yup, they're pretty pointless, there aren't many specialised 'good' use cases. > Why I think metadata will make things like GUS worst? While full-text > search is not without its drawbacks, as Bortzmeyer reminded us, people > will abuse the metadata to "go up" in the search results, and the > outcome of that is crystal-clear on the Web, other than making the life > of who makes a SE more difficult, as now they also have to try to > understand if the metadata is actually relevant or not. Reverse is also true. Look at some recipes on the modern web, or a news article. Recipes will have a 'backstory', for some reason Margret's cookies will have a few paragraphs explaining how they improved her life and how this (bog standard) recipe has descended through her family. News articles are changed to be repetitive and often the highest-ranking ones in search results don't actually go into much detail. I'm not saying that metadata doesn't also have this issue, I'm saying it applies to everything, not just metadata. Now, to get off-topic: > [0]: mine? I would love to have a syntax for definition lists and > 3-levels of unordered lists. If you mean ordered lists with your first point they would be ~fairly hard for clients to parse compared to other line types, they don't start with a static first three characters. (See spec section 5.3 - "Line-orientation") 1. Hi 2. Foo 3. Bar Works fine anyways with plain text, it just doesn't have as nice line-wrapping as quotes and unordered lists. Multiple levels of unordered lists actually wouldn't be very hard:
On Thu, 25 Feb 2021 at 10:23, Oliver Simmons <oliversimmo at gmail.com> wrote: > > On Thu, 25 Feb 2021 at 09:17, Omar Polo <op at omarpolo.com> wrote: > > - we have links, so we can connect different pages, even across > > different capsules > > - we have titles, paragraphs, quotes and lists to express and organize > > our writings > > - we have pre-formatted blocks to allow certain types of > > explanations/presentations that otherwise would have been impossible > > (how do we teach how to write text/gemini in text/gemini?) > > > > From here you can notice how humanly-centric Gemini is. We don't have > > features for bots (more than what it's absolutely needed at least) and > > even more importantly we only have basic and necessary stuff. There's > > no fluff in Gemini. > > > Sorry, I somehow left I blank, I was meaning to say: Perfectly valid point, Gemini is human-centric and should stay that way. However, metadata isn't just for machines, info such as the license, author and date it was written are all things a human may want to know. - Oliver Simmons (GoodClover)
> On Feb 25, 2021, at 11:29, Oliver Simmons <oliversimmo at gmail.com> wrote: > > Perfectly valid point, Gemini is human-centric and should stay that way. > However, metadata isn't just for machines, info such as the license, > author and date it was written are all things a human may want to > know. Use The Rel, Luke. LICENSE => https://creativecommons.org/publicdomain/zero/1.0/ rel=license Licensed under the CC0 1.0 Universal (CC0 1.0) Public Domain Dedication AUTHOR => gemini://gemini.circumlunar.space/users/solderpunk/solderpunk.vcf rel=author Authored by The One & Only Solderpunk DATE => tag:gemini.circumlunar.space,2020-05-26:/dns/gemini.circumlunar.space/tc p/1965/gemini/users/solderpunk/gemlog/the-mercury-protocol.gmi Created on May 26th 2020 ?0?
Oliver Simmons <oliversimmo at gmail.com> writes:
> On Thu, 25 Feb 2021 at 09:17, Omar Polo <op at omarpolo.com> wrote:
>>
>> I think this is a bogus point. I never contributed to OSM, but from
>> what you're saying I suppose they use something like XML/SGML/... Those
>> things are *meant* for extensions (the 'X' in XML stands for that),
>> whilst everything around Gemini is focused on non-extensibility and
>> simplicity, even at cost of missing features.
>>
>
> I'm not talking about XML/etc, that's an entirely separate topic.
> I'm talking about the key=value system.
>
>
>> But instead of thinking about what we may add, let's think about what we
>> have:
>> - we have TLS because it's fundamental to guarantee confidentiality
>> between servers and clients
>> - we have status codes, because a page that says "an error occurred"
>> or "certificate required" cannot be interpreted correctly otherwise
>> - we have a media-type in the response, so users know what kind of
>> document they're getting
>
> These are all about the protocol, not Gemtext.
While it's true that the protocol and gemtext are two different things
(I can serve HTML over gemini and text/gemini over HTTP), they are close
to each other, and it conveys the point that Gemini is made of
practically only needed stuff, nothing more.
(I read about the Mercury protocol, which I didn't knew, and it's really
interesting, but only if you don't consider TLS essential, which I do.)
>> - we have links, so we can connect different pages, even across
>> different capsules
>> - we have titles, paragraphs, quotes and lists to express and organize
>> our writings
>> - we have pre-formatted blocks to allow certain types of
>> explanations/presentations that otherwise would have been impossible
>> (how do we teach how to write text/gemini in text/gemini?)
>>
>> From here you can notice how humanly-centric Gemini is. We don't have
>> features for bots (more than what it's absolutely needed at least) and
>> even more importantly we only have basic and necessary stuff. There's
>> no fluff in Gemini.
>
>
>
>> If you think about it, we only have features that we can't objectively
>> live without (no links? no paragraphs? no media-types? ...) while we're
>> lacking various things that would be "nice to have".
>
> Specification section 5.5 - Advanced line types:
>> The following advanced line types MAY be recognised by advanced clients.
>> Simple clients may treat them all as text lines as per 5.4.1 without
any loss of essential function.
>
> I agree though, unnecessary features shouldn't be added.
>
>
>> We don't have headers, because with them comes extensibility and
>> complexities, and we're getting just fine without them. We don't have
>> inline formatting because it's difficult to handle client-side and we're
>> doing really fine without, etc.
>
> Extensibility *is* an issue with metadata, but this applies to Gemtext
> as a whole due to its nature of being text-based, who's to stop
> someone from creating a new line type that their client understands?
> Standardising metadata now would make people less likely to add it in
> their own weird formats in the future, and laying down solid rules of
> what is and isn't allowed as metadata in Gemini documents helps in
> avoiding (it doesn't prevent entirely) people from adding styling or
> other weird things in the future.
It's attrition that will prevent things like this in the future, not
standardisation. For example, I can create a Gemini client that
supports a script-type line, like
-~ alert("hello world");
but then I would have to convince this list, people who write content
and people who write clients and tools to recognise the -~ line type and
cope with that. I don't think it will gain traction, so...
> On the opposite side, adding metadata would make it easier for people
> to add new things like styling, if they ignore what it's intended for.
> Neither side of the argument really wins here in my eyes.
...not having metadata is slightly better then because people would have
to come up with a syntax, implement it in their clients and convince
others to do the same while looking weird in the eyes of others. Having
a standardised syntax for it allows from day-one someone to say
`background-image: kittens.png' and be fine with that, without looking
weird to other people browsing his/hers capsule.
It's similar to why we don't have headers in the protocol: because
someone, somewhere at some time will abuse them. Having faith in the
community is a good thing, but ensuring that certain things aren't
possible is better.
One thing that I haven't though about when writing the mail, but only
later when discussing the matter with thfr@, is that we're trying to
hide stuff from users eyes. Sure, if used correctly those two proposed
syntaxes (=: and ^^^) can be easy to read, but lets be honest: clients
won't show them as-is, in particular the more advanced ones.
As things stands now, there are only two things that Gemini clients
usually hide: the URL of a link-line and the alt-text of a pre-formatted
block. There's a understandable UX reason for that, but do we really
need to add something else that we know will be hidden to end users?
(Yeah, clients also hide the `#' and `=>' usually too, but that's not
count as "hiding stuff" IMHO, and they usually provide ways to see the
URL or alt text, or even the raw text/gemini)
Another thing that I forgot to explicitly say in my previous message is
that we can use some sort of common notation, a convention, rather than
adding new things to the specification. See for instance the
"Subscribing to Gemini pages" companion specification: a lightweight,
convention-based way to provide atom-like feeds. I found it pretty
elegant, and has proven a) easy to implement b) easy for content writers
to use c) easy for end-users to consume and d) avoid adding extra line
types/file types/etc to the specification.
>[snip]
>
> Now, to get off-topic:
>
>> [0]: mine? I would love to have a syntax for definition lists and
>> 3-levels of unordered lists.
>
> If you mean ordered lists with your first point they would be ~fairly
> hard for clients to parse compared to other line types, they don't
> start with a static first three characters. (See spec section 5.3 -
> "Line-orientation")
> 1. Hi
> 2. Foo
> 3. Bar
> Works fine anyways with plain text, it just doesn't have as nice
> line-wrapping as quotes and unordered lists.
No, I mean definition lists. They're like dictionary entries, where you
provide a term and then its definition. In LaTeX is
\begin{definition}
\item[foo] definition of foo
\end{definition}
in mandoc
.Bl -tag
.It foo
definition of foo
.El
in HTML <dl>/<dd>/<dt>. I find them super-useful when explaining
things, even if they aren't as widespread as other types of lists. I'm
emulating them with
> Omar Polo <op at omarpolo.com> hat am 25.02.2021 10:16 geschrieben: > An user on a non-sophisticate client cannot (easily) understand > that. It's just full of bloat. Metadata is intentionally meta, means it is data about data. If we make it part of the visible page it would loose it's meta-character. It's just data then, as I think. Google does not take the tag metadata into account anymore, because it had been abused so much to get a higher ranking, by for example adding much and any keyword to it so that it would appear in more contexts. So if Google dropped this, why should we make use of it? It would develop into the same problem again. On the other hand there is some meta data what makes really sense, like the date of last change of a file or such. No search engine could ever give good results, if it can't differentiate a 10 years old page with outdated content from a new one. We should think about those kind of things and imagine a wider spread of Gemini, as it is now. Martin
> On Feb 25, 2021, at 14:09, Martin <devel at datenbrei.de> wrote: > > If we make it part of the visible page it would loose it's meta-character. It's just data then, as I think. WAT? :) This is how your email looks like in my MUA: Martin <devel at datenbrei.de> Re: [SPEC] Backwards-compatible metadata in Gemini To: Gemini application layer protocol <gemini at lists.orbitalfox.eu> Date: Thu, 25 Feb 2021 14:09:50 The WHO, the WHAT, the WHERE, and the WHEN of your email. ? This is before any of the content itself. Making these information visible is what makes it work. ? https://en.wikipedia.org/wiki/Five_Ws ?0? -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210225/4d47 2998/attachment.htm>
Julien Blanchard writes:
> Still don?t get why a Gemini user would care about search engines and
> other tools to publish content but maybe I?m alone in this crowd and
> personal branding is the only thing that matter anyway.
We live in a society. ?
--
Jason McBrayer | ?Strange is the night where black stars rise,
jmcbray at carcosa.net | and strange moons circle through the skies,
| but stranger still is lost Carcosa.?
| ? Robert W. Chambers,The King in Yellow
> Petite Abeille <petite.abeille at gmail.com> hat am 25.02.2021 14:59 geschrieben: > > > > > On Feb 25, 2021, at 14:09, Martin <devel at datenbrei.de mailto:devel at datenbrei.de > wrote: > > > > If we make it part of the visible page it would loose it's meta-character. It's just data then, as I think. > > > > > > WAT? :) > > This is how your email looks like in my MUA: > > Martin <devel at datenbrei.de mailto:devel at datenbrei.de > > Re: [SPEC] Backwards-compatible metadata in Gemini > To: Gemini application layer protocol <gemini at lists.orbitalfox.eu mailto:gemini at lists.orbitalfox.eu > > Date: Thu, 25 Feb 2021 14:09:50 > > The WHO, the WHAT, the WHERE, and the WHEN of your email. ? > > This is before any of the content itself. > > Making these information visible is what makes it work. > I did not say, that you can leave it out. I even did not say, that meta data should not be visible. What I mean is, that this email arrives and everybody can see when this email was sent, because the meta data ist clearly seperated and technically usable by machins so that the mail agent can handle it and deliver this email, for example. I'd like to stress the "separation" from the content of the page. With "Cheers, Martin" you could not answer this email and with "written on some lonely afternoon in south of Germany" you would not know, when this was sent. My point is: meta data seems to be important, but we need to clarify what we want with it, the use cases. This all I say knowing, that the protocol should be frozen somewhen. If we just say, let's get as minimal, as it goes, many things may not be possible in the future. What I like best are concepts, like for example the programming language lua provides, that are flexible and elegant. Where can do much with a small set of features. Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210225/79e6 d9d9/attachment.htm>
> On Feb 25, 2021, at 16:15, Martin <devel at datenbrei.de> wrote: > > What I like best are concepts, like for example the programming language lua provides, that are flexible and elegant. Where can do much with a small set of features. > Actually, in Lua's terms, this is the perennial distinction between 'mechanisms' and 'policies' ? that Roberto likes to make. As far as I can tell, text/gemini has enough 'mechanisms' (namely the link construct) to effectively implement all the metadata 'policies' one would ever want. No need to change anything in Gemini at all. Only to develop a set of practices to make effective use of what it has to offer today. ?0?
On Thu, Feb 25, 2021 at 4:17 AM Omar Polo <op at omarpolo.com> wrote: - we have TLS because it's fundamental to guarantee confidentiality > between servers and clients > I personally don't give a damn about this (after all, who's going to pass confidential information over Gemini? See below.), but I accept that other people do. - we have status codes, because a page that says "an error occurred" > or "certificate required" cannot be interpreted correctly otherwise > They aren't actually part of the required protocol engine, except for 1x vs. 2x. The META for the others is just human-readable content, and could be replaced by a 2x document, and some other mechanism could be found for the marginal case of 1x. (Clients might exploit 6x to automatically retry with a (different) cert, but it's unclear that this is the Right Thing: the protocol document is, as usual, ambiguous, as it says "should be retried" but not who should retry it.) > - we have pre-formatted blocks to allow certain types of > explanations/presentations that otherwise would have been impossible > (how do we teach how to write text/gemini in text/gemini?) > It's still hard to explain ``` within ```: you can talk about it but you can't show an example. Anyway, I don't care about any of these points, just that "necessary" is in the eye of the beholder. - the one adding the line-type =: (or whatever): you have to parse the > whole document to extract the metadata True, but that's true for any approach except metadata-at-the-top. Note that ^^^ within ``` does not mark metadata, so you have to parse at least that much. and it allows for possibly unreadable text/gemini files[1] > ????? ???'? ??? ??????? ???????? ???? ?? ???? ?????? ?????. _O_ver _there_/ _O_ver _there_ /_Send_ the _word, _Send_ the _word_ / _to_ pre _pare_. [PRETEND THE NEXT PARAGRAPH IS IN ITALICS] [READ THE WORDS IN ANY ORDER DESIRED] ad pulcritudinem tria requiruntur, integritas, consonantia, claritas. There's no problem creating Gemini text that's hard to read. T????????????????h???????????????i????????????s???????? ????????????????i???????????????s????????????? ?????????????g?????????????????????l????????????????????????i????????????t? ?????????c???????????????h??????????????????????????y?????????????????? ???????????????t??????????????????????e????????????????????????x??????????? ??t????????????????????????? ??????????????????a???????????t?????????????????? ???????????????????????l?????????????????????e??????????????v?????????????? ????????????e????????l???????????? ???????1???????????????? ?????c??????????????r?????????????????????a????????????z???????????????i??? ?????????????????n???????????????????e??????????s?????s??????????????.?????????????????? you probably will have trouble here Workers at the Tower of Babel: "Bitte geben Sie mir einen kleineren Schraubenschl?ssel.' 'Non ho idea di quello che stai chiedendo.? ???????? ????? ??? ? ?????.? ?Kei te korero koe i tito noa, ko ahau ngenge o te whare pourewa.' There. A perfectly valid text/gemini or indeed text/plain document, and yet quite unintelligible, and it would be trivial to make it far worse. The question is, what is the _motive_ for writing and serving such rubbish? Web pages lie to search engines because money. Web pages contain hidden text because money. Web pages plant tracking pixels because money. The love of money is the root of all Web evil. But where's the money in Gemini? I mean, you could put textual ads in your pages and a link to a website, but why not just use the website? An user on a non-sophisticate client cannot (easily) understand > that. It's just full of bloat. > Again, you'd have to be a fool to write something like your example or mine except for hack value. Reasonable people would either put metadata at the bottom of the document or the most important entries at the top and less important ones at the bottom; it's the possibility of doing that, along with allowing links-with-metadata, that make me want it to be able to go anywhere. Gemini is like (anarchist) Anarres: everything is open to everyone's . The Web has become like (capitalist) Urras: there is lots of glitz on top, but the important stuff is hidden in the cellars, where people are bleeding to death. Repeating myself: metadata conventions should go in a metadata spec, *not* in the text/gemini spec, since neither clients nor servers are required to take any notice of them. What I think is missing in all these discussions is a valid reason to > outweight the cons. > Lars explained that much better than I could. Also, look up cataloging-in-publication, which basically puts metadata on the copyright page of every published book. That way it stays with the book. However, I feel that denying and turning down feature requests for > addition is not a good thing. I think we should reflect on what's the > actual problem and solve it, because this smells like a XY problem[2] to > me. > "If you want PL/I, you know where to find it." --Dennis Ritchie (PL/I was notoriously a bloated language by the standards of its time: by today's standards, not so much.) If we want to give people ways to manage their local data, maybe because > they want to search across documents or do some kind of publications > over Gemini, then centralising metadata in one place is an option. > Out-of-band markup is fine, except that it tends to get lost as content is passed around, reduced reused recycled. Sure, I can stick a > description of "About the interpretation of the Will of power in > Nietzsche" with tags "philosophy, nietzsche, will-to-power" and a > category of "essay", but you cannot trust me to talk about those > arguments in the page, maybe it only contains link to pics of cute > kittens :) > Do that enough and people will simply ignore you. It's a funny-once joke. > Why I think metadata will make things like GUS worst? While full-text > search is not without its drawbacks, as Bortzmeyer reminded us, people > will abuse the metadata to "go up" in the search results, > Why would a geminaut want to "go up"? We are already in orbit. On Thu, Feb 25, 2021 at 6:41 AM Omar Polo <op at omarpolo.com> wrote: but then I would have to convince this list, people who write content > and people who write clients and tools to recognise the -~ line type and > cope with that. I don't think it will gain traction, so... > I agree: social pressure is probably enough here. But scripts make clients
On Thu, Feb 25, 2021 at 2:05 PM John Cowan <cowan at ccil.org> wrote: > This is glitchy text at level 1 craziness. > Okay, Gmail is not displaying the glitchiness, but I checked and it's there in the email. > OT: I'm actually designing something like GeminiScript, but not for Gemini > clients. > I forgot to say that I would very much like to hear from anyone who's interested in developing this idea with me. Email me at cowan at ccil.org. -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210225/7b9c 0337/attachment.htm>
On Thu, Feb 25, 2021 at 5:24 AM Oliver Simmons <oliversimmo at gmail.com>
wrote:
Extensibility *is* an issue with metadata, but this applies to Gemtext
> as a whole due to its nature of being text-based, who's to stop
> someone from creating a new line type that their client understands?
>
Ahhhh, you said in one sentence what took me a whole long email.
By the way, thanks for pointing out the ^^^ in your format; I had forgotten
that in the pile of messages.
> I hadn't thought about that, a very valid point.
> But I think allowing metadata to be mixed in with text, as the other
> format allows, is a bigger drawback than enforcing putting it at the
> end of files and breaking concatenation.
>
Since we are both pro-metadata, can you explain to me your reasons why you
think allowing mixture is bad? My arguments are: (a) some metadata belongs
at the top for the human's sake, (b) allowing links to carry metadata about
the referent is a Good Thing. Note also (in case it got lost) that ^^^ is
not valid within ``` blocks, so you still have to do minimal parsing to
find the metadata.
> Look at some recipes on the modern web, or a news article.
> Recipes will have a 'backstory', for some reason Margret's cookies
> will have a few paragraphs explaining how they improved her life and
> how this (bog standard) recipe has descended through her family.
>
It's fluff, but without fluff there would be no Gemini. :-)
John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org
But that, he realized, was a foolish thought; as no one knew better than
he that the Wall had no other side.
--Arthur C. Clarke, "The Wall of Darkness"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210225/0323
e90b/attachment.htm>
John Cowan <cowan at ccil.org> writes: > On Thu, Feb 25, 2021 at 4:17 AM Omar Polo <op at omarpolo.com> wrote: > > - we have TLS because it's fundamental to guarantee confidentiality >> between servers and clients >> > > I personally don't give a damn about this (after all, who's going to pass > confidential information over Gemini? See below.), but I accept that other > people do. "confidentiality" maybe was the wrong word. The idea is that I don't want to let everyone in the same network see (and possibly hijack) the pages I visit. (OK, there are tons of possible issues with this, given TOFU and how specific clients implements it etc, I don't want to get off topic though.) > - we have status codes, because a page that says "an error occurred" >> or "certificate required" cannot be interpreted correctly otherwise >> > > They aren't actually part of the required protocol engine, except for 1x > vs. 2x. The META for the others is just human-readable content, and could > be replaced by a 2x document, and some other mechanism could be found for > the marginal case of 1x. (Clients might exploit 6x to automatically retry > with a (different) cert, but it's unclear that this is the Right Thing: the > protocol document is, as usual, ambiguous, as it says "should be retried" > but not who should retry it.) I'm not sure I understand what you mean. If my server fails to execute a CGI script, it should return a 20 reply with "Error while executing the script" instead of 42? The meta is human-readable, but the codes 3x, 4x, 5x and 6x carries a meaning, it's an extra information, heck, you can consider that a metadata in some large interpretation of the word. (Maybe 3x can be dropped, and some codes inside 4x and 5x as well if we really want to be barebones, but again, I don't want to get off-topic.) >> - we have pre-formatted blocks to allow certain types of >> explanations/presentations that otherwise would have been impossible >> (how do we teach how to write text/gemini in text/gemini?) >> > > It's still hard to explain ``` within ```: you can talk about it but you > can't show an example. Touch? > Anyway, I don't care about any of these points, just that "necessary" is in > the eye of the beholder. > > - the one adding the line-type =: (or whatever): you have to parse the >> > whole document to extract the metadata > > > True, but that's true for any approach except metadata-at-the-top. Note > that ^^^ within ``` does not mark metadata, so you have to parse at least > that much. > > and it allows for possibly unreadable text/gemini files[1] >> > [...] > you probably will have trouble here FYI, Emacs handled that wall of text surprisingly well :) (just for curiosity, what languages are? I couldn't recognize them) > Workers at the Tower of Babel: > "Bitte geben Sie mir einen kleineren Schraubenschl?ssel.' > 'Non ho idea di quello che stai chiedendo.? Adesso ne ho una, o almeno mezza, sperando che la traduzione sia fedele :) (sorry I couldn't resist. I don't see pretty often examples featuring Italian) > ???????? ????? ??? ? ?????.? > ?Kei te korero koe i tito noa, ko ahau ngenge o te whare pourewa.' > > There. A perfectly valid text/gemini or indeed text/plain document, and > yet quite unintelligible, and it would be trivial to make it far worse. > The question is, what is the _motive_ for writing and serving such rubbish? > Web pages lie to search engines because money. Web pages contain hidden > text because money. Web pages plant tracking pixels because money. The > love of money is the root of all Web evil. But where's the money in > Gemini? I mean, you could put textual ads in your pages and a link to a > website, but why not just use the website? The motive to serving rubbish can simply be some sloppery when generating automatic content. If I know `=:'-style metadata can be put anywhere, I can write scripts that *for convenience* don't try to put everything at the top/bottom. But I agree, this is probably a moot point. The real issue I see lies in just adding an explicit syntax for key-pairs value. I'm explaining it better below > An user on a non-sophisticate client cannot (easily) understand >> that. It's just full of bloat. >> > > Again, you'd have to be a fool to write something like your example or mine > except for hack value. Reasonable people would either put metadata at the > bottom of the document or the most important entries at the top and less > important ones at the bottom; it's the possibility of doing that, along > with allowing links-with-metadata, that make me want it to be able to go > anywhere. Gemini is like (anarchist) Anarres: everything is open to > everyone's . The Web has become like (capitalist) Urras: there is lots of > glitz on top, but the important stuff is hidden in the cellars, where > people are bleeding to death. > > Repeating myself: metadata conventions should go in a metadata spec, *not* > in the text/gemini spec, since neither clients nor servers are required to > take any notice of them. > [snip] > >> One thing that I haven't though about when writing the mail, but only >> later when discussing the matter with thfr@, is that we're trying to >> hide stuff from users eyes. Sure, if used correctly those two proposed >> syntaxes (=: and ^^^) can be easy to read, but lets be honest: clients >> won't show them as-is, in particular the more advanced ones. >> > > I'm sorry, but I am unwilling to take this for granted. Why hide them? > (I'm already annoyed that Gmail hides signatures, and mine aren't always > the same, so I don't use the standard "-- " line to announce them any more.) > > As things stands now, there are only two things that Gemini clients >> usually hide: the URL of a link-line and the alt-text of a pre-formatted >> block. > > > I actually think hiding the URL is bad UX. People should be able to know > *before* going to a page where it's coming from. Showing the domain is not > enough, because multi-hosting. (This is an option in Lagrange now.) > >> There's a understandable UX reason for that, but do we really >> need to add something else that we know will be hidden to end users? >> > > "Know" is a very strong verb, especially for something that hasn't happened > yet. Metadata in HTML head elements was *required* to be hidden from day 1. >[] >> Another thing that I forgot to explicitly say in my previous message is >> that we can use some sort of common notation, a convention, rather than >> adding new things to the specification. See for instance the >> "Subscribing to Gemini pages" companion specification: a lightweight, >> convention-based way to provide atom-like feeds. I found it pretty >> elegant, and has proven a) easy to implement b) easy for content writers >> to use c) easy for end-users to consume and d) avoid adding extra line >> types/file types/etc to the specification. >> > > That's what I want too. =: does not have to be a text/gemini line type, > just a convention explained elsewhere. I feel like we're not talking about the same thing. This thread has grown pretty large, so I apologies if I missed some parts of it. My understanding of the proposals is that they want to add some sort of extra notation (either as line-type or block, it doesn't matter) to express (potentially) arbitrary key-value pairs. Given this, we know that non-dummy clients will hide them in the document, probably to show those information in a "better" way. I mean, it wouldn't be bad if a client would be able to display a sidebar the authors of the document and creation/update dates. But then we have given users ways to extend the format way beyond its purpose, so it gets way easier to add styling, formatting, and other stuff. But from what you write, it seems that you're aim at some sort of convention for metadata, and this is something I can actually agree on. To make it clear, since in another mail you mentioned two "factions", I'm not against the idea of metadata in the first place, I simply don't like the existing proposals for the already mentioned issues. Even if I'm not 100% happy with what follows, if I were to add metadata, I'd advocate for something simpler, without a prefix that smell like "unofficial line-type", and probably already in use like: Author: Omar Polo Published: 2020-02-24 Edited: 2020-02-25 Licence: ISC (even the FAQ document has a Last-Update line near the top, or something like that) With something like this I think we could achieve metadata in a way that: - they're not hidden from the end-user eyes - easy (and natural) to use by who write contents - intuitive for the readers - backward - and forward - compatible with the spec - doesn't require a special treatment by already existing clients Something like this would also avoid various problems regarding the classification of valid keywords and the troubles regarding internationalisation. In an Italian document I would happily write Autore: Omar Polo Pubblicato: 2020-02-24 Aggiornato: 2020-02-25 Licenza: ISC and all my readers would understand the meaning. We could then have specific search-engines per-language, adapt tools to cope with this etc, all without modifying the spec and without providing a syntax that can be abused. Now, to the OT (i'm lazy today and I don't want to write another mail) > OT: I'm actually designing something like GeminiScript, but not for Gemini > clients. I think the idea of no-install instant-download software with > severe limitations on presentation and no access to the local system except > very limited keyboard/screen/mouse is in fact a good one, but unlike > Brendan Eich I have the luxury of more than two weeks to think about it. I > also want to make it as accessible to non-professionals as microcomputer > Basic was. It would run in its own native client, either CLI or TUI or GUI > (there are some issues around the fact that CLIs linearize access). Like > most languages, it could probably be compiled to JavaScript. > I don't like the idea of instant-download software for various ethical and practical concerns, but I have a soft-spot for programming language design and compilers, so, if you don't mind, I'd be curious to read more about it :) P.S.: I find your way of quoting text strange. Why the first line of every cited block isn't prefixed by > when all the others are? Is that some sort of arcane custom that youngster like me don't understand? > > > John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org > Your worships will perhaps be thinking that it is an easy thing > to blow up a dog? [Or] to write a book? > --Don Quixote, Introduction
On Wed, Feb 24, 2021 at 10:11:07PM +0200,
Lars Nood?n <lars.nooden at gmx.com> wrote
a message of 27 lines which said:
> The actual contents of the key-value pairs, the actual metadata itself,
> would not be part of the spec, not even the keys.
May be not in "The Official Spec" but it certainly needs to be
somewhere, because otherwise people would tag the same information
differently ("last-modified", "last-change", "updated"), then
destroying its utility. The OpenStreetMap example (you can invent new
tags but you should use the official ones, when relevant) is certainly
pertinent.
> It would not be appropriate to try to impose a custom vocabulary
Nobody imposes anything, Gemini has no armed forces.
On 26 feb. 2021 11:44, Stephane Bortzmeyer < stephane at sources.org> wrote:
> May be not in "The Official Spec" but it certainly needs to be
> somewhere, because otherwise people would tag the same information
differently ("last-modified", "last-change", "updated"), then
> destroying its utility. The OpenStreetMap example (you can invent new
> tags but you should use the official ones, when relevant) is certainly
> pertinent.
The parser could have aliases for duplicate keys, but I agree is best if
we have as few aliases as possible. I am of the opinion that the keys
should be in the language of the document.
--
Katarina
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210226/4e9f
8646/attachment.htm>
On Thu, Feb 25, 2021 at 10:16:52AM +0100,
Omar Polo <op at omarpolo.com> wrote
a message of 161 lines which said:
> As things stands, I know I can
>
> cat file1.gmi file2.gmi ... > result.gmi
>
> and obtain a valid text/gemini file.
One of the things missing in the current specification is a formal
grammar of gemtext, so there is currently no way to know if lines must
end with a end-of-line or is the end-of-file sufficient.
=> gemini://gemini.bortzmeyer.org/gemini/missing-eol.gmi Example
Amfora and Lagrange seem to accept the last line (the one without an
end-of-line). But your example with cat would break it, concatening
the last line of the first file with the first line of the second file.
> Also, the examples you gave in support of your proposals seems bogus
> too. Serving a mailing list archive over Gemini? Cool, but why convert
> the mails to text/gemini? Wrapping them in ``` (with headers visible)
> or serving them "raw" is not enough?
Because humans (specially non-anglosaxon humans) have trouble with
"From", "Subject" and "Message-ID"?
> If we want to build a better GUS I don't think that adding metadata
> to text/gemini will solve anything, it will actually make things
> worst. The point is, you can't trust 3rd-parties metadata. [...]
> people will abuse the metadata to "go up" in the search results, and
> the outcome of that is crystal-clear on the Web,
I'm not convinced by this "look at the SEO mess" argument. Gemini is
not the Web, there is no money at stake, marketing people and salesmen
frown upon Gemini ("what, no pictures? No tracking?") so I really
doubt that many people would resort to dirty tricks just to be higher
in GUS' results.
> On Feb 26, 2021, at 12:53, Stephane Bortzmeyer <stephane at sources.org> wrote: > > I'm not convinced by this "look at the SEO mess" argument. There is comic relief in it :D ?0?
On Fri, Feb 26, 2021 at 11:44:38AM +0100, Stephane Bortzmeyer wrote:
> On Wed, Feb 24, 2021 at 10:11:07PM +0200,
> Lars Nood?n <lars.nooden at gmx.com> wrote
> a message of 27 lines which said:
>
> > The actual contents of the key-value pairs, the actual metadata itself,
> > would not be part of the spec, not even the keys.
>
> May be not in "The Official Spec" but it certainly needs to be
> somewhere, because otherwise people would tag the same information
> differently ("last-modified", "last-change", "updated"), then
> destroying its utility.
I'd say it is diminishing its utility, and even then mostly for third
parties (like indexers).
I also believe that useful metadata will roughly converge to a format within a
natural language, like we're already seeing with meta-data like "Tags:".
Sure, there are variations,
but it's not unreasonable to say these are the responsibility of the third
party to pick up on.
And if some writer really wants to be indexed by a particular engine, that engine
should put up a list of useful metadata for writers to use. Different engines can
copy each other, or be more distinctive in their meta-data requests.
Now e.g. chinese writers can freely use "??:" for tags, meaning they probably don't
care about being indexed/archived by non-chinese engines, but if an all-languages
engine still want to index the page, they can if they put in the work.[0]
So,
What are the benefits of a consolidated meta-data format for the two most
important parties
within Gemini: the writer and the reader?
Why are the third parties (indexers, archivers, etc) for whom meta-data could be
important not working on this by themselves? They can write and publish rules, and
then try to get the writers onboard. And writers can decide for themselves if the
extra trouble is worth the extra discoverability/better archiving, etc, forcing third
parties to co-operate and to keep it simple.
In short, I don't understand the need for regulation when non-regulated convergence
seems a natural outcome that will fit the various use cases better through
an evolutioanry
process. Granted, waiting for convergence is a lot slower, but does faster adoption
really matter with Gemini?
[0]"??" is a dictionary translation for illustration purposes.
> On Feb 26, 2021, at 13:09, avr at geminet.org wrote: > > Granted, waiting for convergence is a lot slower, but does faster adoption > really matter with Gemini? Very good point. No one actually cares :) I personally do use metadata in gemini for my own purpose, in my own little bubble ? but quite frankly couldn't care less about any of the current crop of wacky proposals :D ?0?
Stephane Bortzmeyer <stephane at sources.org> writes:
> On Thu, Feb 25, 2021 at 10:16:52AM +0100,
> Omar Polo <op at omarpolo.com> wrote
> a message of 161 lines which said:
>
>> As things stands, I know I can
>>
>> cat file1.gmi file2.gmi ... > result.gmi
>>
>> and obtain a valid text/gemini file.
>
> One of the things missing in the current specification is a formal
> grammar of gemtext, so there is currently no way to know if lines must
> end with a end-of-line or is the end-of-file sufficient.
>
> => gemini://gemini.bortzmeyer.org/gemini/missing-eol.gmi Example
>
> Amfora and Lagrange seem to accept the last line (the one without an
> end-of-line). But your example with cat would break it, concatening
> the last line of the first file with the first line of the second file.
It's not completely true. This example was specifically for UNIX-like
systems where files are expected to end with a newline. It's POSIX
fault, as it defines a line as a sequence of character ending with a \n:
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_206
(this isn't an excuse for clients to not handle them correctly though!)
>> Also, the examples you gave in support of your proposals seems bogus
>> too. Serving a mailing list archive over Gemini? Cool, but why convert
>> the mails to text/gemini? Wrapping them in ``` (with headers visible)
>> or serving them "raw" is not enough?
>
> Because humans (specially non-anglosaxon humans) have trouble with
> "From", "Subject" and "Message-ID"?
I can agree, but I find preferable something like
# Hypothetical archive page for a Gemini mailing list in Italian
Da: Omar Polo <op at omarpolo.com>
A: <someone at example.com>
CC: ...
Oggetto: [spec] proposta per i metadatai
```
actual raw body of the e-mail...
```
instead of
-: x-mail-from="Omar Polo <op at omarpolo.com>"
-: x-mail-to=<someone at example.com>
-: x-mail-subject="..."
```
...
```
or even
```
actual body of the email
```
^^^
from: ...
to: ...
...
"Free-form metadata", as in simple text paragraphs made up like that,
are probably already widespread, intuitive for writers and readers, and
probably also "simple enough" for tools to grok, at least partially. It
also solves localisation problems, because it's the author that is free
to pick the way he/she prefers to conveys the meaning for his/her
audience. Different authors may choose different keys for the same
"idea" (i.e. "Updated", "last-updated", "edited" ...), that's true, this
solution is not without its drawbacks.
(ah, all of this without adding dangerous ways to extend the text format)
>> If we want to build a better GUS I don't think that adding metadata
>> to text/gemini will solve anything, it will actually make things
>> worst. The point is, you can't trust 3rd-parties metadata. [...]
>> people will abuse the metadata to "go up" in the search results, and
>> the outcome of that is crystal-clear on the Web,
>
> I'm not convinced by this "look at the SEO mess" argument. Gemini is
> not the Web, there is no money at stake, marketing people and salesmen
> frown upon Gemini ("what, no pictures? No tracking?") so I really
> doubt that many people would resort to dirty tricks just to be higher
> in GUS' results.
I acknowledge that this is not a problem right now, and hopefully will
never be, but we should be aware of the troubles. Adding a syntax for
metadata will (possibly) open the doors for tracking, styling, etc.
On Wed, Feb 24, 2021 at 03:17:07PM -0700, Alex // nytpu <alex at nytpu.com> wrote a message of 44 lines which said: > We have gemini://when.willgemini.support courtesy of Ren? Wagner. > > In this case: > gemini://when.willgemini.support/?metadata "gemini is (almost) perfect the way it is now" I am personally not at ease with people who claim thay they (or their party, or their religion, or their specification) is perfect. I understand that <gemini://when.willgemini.support/> is supposed to be a joke but I think it is a bad one.
On Thu, Feb 25, 2021 at 3:56 PM Omar Polo <op at omarpolo.com> wrote: > "confidentiality" maybe was the wrong word. The idea is that I don't > want to let everyone in the same network see (and possibly hijack) the > pages I visit. Well, TLS doesn't block traffic analysis (who's talking to whom at what time). For that you need Tor (a U.S. government-funded effort, by the way). I'm not sure I understand what you mean. If my server fails to execute > a CGI script, it should return a 20 reply with "Error while executing > the script" instead of 42? That's the idea. There is a language problem, of course, if the server explains it in a language you don't know. Again, this isn't something I want seriously considered. FYI, Emacs handled that wall of text surprisingly well :) > Well, sure. Plain-text console-style rendering can handle most of that fine. > Workers at the Tower of Babel: > > "Bitte geben Sie mir einen kleineren Schraubenschl?ssel.' > German: "Please give me a small screwdriver." > 'Non ho idea di quello che stai chiedendo.? > That was supposed to be "I have no idea what you're asking for." I hope it was. > > ???????? ????? ??? ? ?????.? > Russian: "Let's have a cup of tea and go home." > ?Kei te korero koe i tito noa, ko ahau ngenge o te whare pourewa.' Maori (the native language of New Zealand): "You're talking nonsense/fiction; I'm tired of the tower." > I don't like the idea of instant-download software for various ethical > and practical concerns, but I have a soft-spot for programming language > design and compilers, so, if you don't mind, I'd be curious to read more > about it :) > I have a lot of scribbles on paper right now, so I'll get back to you when they are online and a little more organized. > P.S.: I find your way of quoting text strange. Why the first line of > every cited block isn't prefixed by > when all the others are? Is that > some sort of arcane custom that youngster like me don't understand? > /me chuckles No, just carelessness/laziness on my part. The text I want to comment on often starts in the middle of a line, so I delete everything I *don't* want to quote, and I often forget to put back the initial > (or several of them). John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org Long-short-short, long-short-short / Dactyls in dimeter, Verse form with choriambs / (Masculine rhyme): One sentence (two stanzas) / Hexasyllabically Challenges poets who / Don't have the time. --robison who's at texas dot net -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210226/7edb 56aa/attachment.htm>
---
Previous Thread: [SPEC] Encouraging HTTP Proxies to support Gemini hosts self-blacklisting
Next Thread: [Spec] <META> in the response header is too vague