Re: Org and Hyperbole

[indieterminacy <indieterminacy@libre.brussels>]

Hello Robert,

On 08-10-2022 22:26, Robert Weiner wrote:
> Hi Jonathan:
> 
> I and I think others would love to understand what you are trying to
> achieve.  I get that you want to use the Koutline format with external
> systems like GemText and the TXR parser generator/Lisp language but I
> would rather understand the purpose of what you are trying to build
> (problem(s) to solve) and what you can't do with the Koutliner as it
> now stands that you would like to do.  Try to explain it without
> referencing any particular technologies, as I can't follow many of the
> things you write because of a lack of context.
> 

How does one describe crimson and clover?

My medium term plans are to adapt my utilitarian setup, so that it 
becomes encapsulated.
Im planning to provide augmentation of Icebreaker's stack into areas of:
* text-to-speech
* speech-to-text
* braile

Though initially focusing on software design, I could (eventually) see 
advantages of product design to
complement the interfacing and interpreting aspects of my work.

Not technologically speaking, the problem Im wrestling is broadly 
similar to George Bernard Shaw (with regards to
notation; shorthand; and semiotics) when he proposed the Shavian 
Alphabet to supplant the
Latin alphabet.

Philologists should track down the later half of his preface in the 
book,
The Miraculous Birth of Language:
https://archive.org/details/in.ernet.dli.2015.462145/page/n9/mode/2up

Coincidentally, both his and my approaches to our different problems 
settled on a notation with 40 characters.


Focusing on my TXR interpreter, I have been creating my own flavour of 
canonical s-exp, Qiuynonical:
https://git.sr.ht/~indieterminacy/1q20hqh_oqo_parsing_qiuynonical

Here is an example of the parsing-expression-grammars interleaving 
different uris and there comments:
```
+ (("2:=>" "1: ") ("w-i" (("6:gemini" "3:://" "10:icebreaker" "1:." 
"5:space") ("5:/?q=/" ("3:111:1:." "1:+" "6:gemini" "3:://" 
"10:icebreaker" "1:." "5:space")))
+                  "i-w" ("3:REM:5:bunch:2:of:5:words" ("3:ueu" ("1:_" 
"14:testing-search"))))
+  "bing-x-b-ii-a")
+ (("2:=>" "1: ") ("w-i" (("6:gopher" "3:://" "10:icebreaker" "1:." 
"5:space") ("3:/?=" ("3:1aa:1:." "1:&" "6:gemini" "3:://" 
"10:icebreaker" "1:." "5:space")))
+                  "i-w" ("3:REM:5:bunch:2:of:5:words" ("3:ueu" ("1:_" 
"14:testing-search"))))
+  "bing-x-b-ii-a")
+ (("2:=>" "1: ") ("w-i" (("6:finger" "3:://" "10:icebreaker" "1:." 
"5:space") ("2:/?" ("3:1a2:1:." "1:&" "6:gemini" "3:://" "10:icebreaker" 
"1:." "5:space")))
+                  "i-w" ("3:REM:5:bunch:2:of:5:words" ("3:ueu" ("1:_" 
"14:testing-search"))))
+  "bing-x-b-ii-a")
+ (("2:=>" "1: ") ("w-i" (("5:https:5:bunch:2:of:5:words" "3:://" 
"10:icebreaker" "1:." "5:space") ("4:/?q=" ("2:1a:1:." "1:%" "6:gemini" 
"3:://" "10:icebreaker" "1:." "5:space")))
+                  "i-w" ("3:REM" ("3:ueu" ("1:_" 
"14:testing-search"))))
+  "bing-x-b-ii-a")
```

Notice how "REM" is actually the first instance of non official token, 
starting a new parenthesis but still permitting repetitive patterns for 
things like "ueu" as an annotation to still be caught later on (with or 
without descriptors (which could be an underline, a tab or two or more 
whitespaces).

Niceley, the way ive been approaching breakpoints between line-types and 
content-types is that you could(!) have iterating blocks of gemtext and 
koutliner within the same line - with the datalisp representing it as an 
array.

As a consequence, one may then use logic rules for sophisticated 
inferences.
Such as querying a subtext of a gemtext document and appending a 
conclusion or requirement in a referenced koutliner block.

Think YahooPipes for playgrounding.


In terms of accessibility, rather than all content being read out, uris 
could be counted and headers or notion read out with a distinctive tone.
Or similarly, concerning annotations or dates.



It is of course worth stating that gemtext has advantages for written 
prose, especially its ease of transmission with its TLS backed protocol, 
Gemini.
I appreciate its simplicity and minimalism, including on a technical and 
tooling level.

Here is a (recently released) video from last years Software Freedom Day 
concerning Gemini and complexity:
https://www.youtube.com/watch?v=zyTC4QWGCQg

FFIW, the messaging service featured in the talk used sqlite.

I feel that Gemtext is as worthy of usage as Outline for instance and 
the cost for interoperating with Orgmode not insurmountable.

It is worth stating that I treat all coding comments as the 
aforementioned formats and syntaxes.
With the intention of inverting code documents into a 
literate-programming form.

Given that out of the box TXR can operate inside a Gemtext document and 
output something different gemtext content makes me feel that
  there are a lot of possibilities yet to explore.


This quote from the Gemini community highlights why Icebreaker feels it 
is making the correct design decisions (given the importance of Gemtext 
to its technology stack):
```
I am a blind person who is interested in all kinds of different ways of 
working with text and writing.
I’ve written in Markdown, Org-mode, tried LaTex but found it just about 
as verbose to write as HTML,
and thought about Restructured Text but the advanced stuff in it looked 
a lot like HTML too.
Anyways, I got into Gemini because of the simplicity.

I loved the idea of basically a Markup language being the pure writing 
method of an entire site.
No static site generator needed, just directories of linked plain text 
files.
No CSS, no JavaScript, no Liquid or or shortcakes or anything.
...
Screen readers are not smart.
They speak whatever the operating system or application exposes to the 
accessibility API’s.
Sure, the spoken, or brailled, output can be arranged or massaged 
slightly,
but whatever is there is what will be spoken, from left to right, top to 
bottom.

Some screen readers, like NVDA and JAWS, and Orca to some extent,
do try to massage the data of websites to make them easier to use or to 
fix accessibility issues that
the web developer won’t or can’t, but there’s a line they try not to 
cross between scripting things to
work better and making up a whole new interface for something when the 
UI developers don’t consider accessibility.
Even if the block is labeled, it’s still text, and the screen reader 
will do what it does, read all of it.
...
Now, this isn’t to say that Gemini is bad for accessibility. I love 
being able to get right to the content of
a page *quickly* because there are no sidebars, no top navigation links, 
no ads, no frames, no nonsense.
It’s like having the whole web in reader view, with only useful or 
important links at the bottom or
somewhere out of the way. I *love* that about Gemini,
and it’s why I read it on not only my laptop with Emacs, but on my 
iPhone too.
So thank you all for this great way to read and write on the Internet!
```
https://lists.orbitalfox.eu/archives/gemini/2021/005631.html [Clients] 
Gemini and accessibility regarding preformatted code blocks
(an archived citation from a retired mailinglist)

> 
> On Fri, Jun 24, 2022 at 8:51 AM Robert Weiner <rsw@gnu.org> wrote:
> 
>> Hi Jonathan:
>> 
>> Yes, the backlink issue is one of the reasons we have not focused on
>> moving kcells with permanent hyperlink anchors from one file to
>> another.  We generally feel that the context of kcells within an
>> outline is important and thus should stay as a unit.  You obviously
>> can and do link to any kcell from outside the outline by combining
>> the file path with the cell's permanent id and thus could have a
>> grep-like search across any number of Koutlines.
>> 
>> But I agree a cross-file permanent ID structure could be useful and
>> that there are times where you want to move or copy outline
>> structure between files (we already support exporting the text of
>> koutlines to other buffers or to HTML), so this is a future use case
>> to consider.
>> 
>> -- rsw

Ive decided to chunk blocks of text as a mechanism to cross-manage my 
knowledge assets

Im electing to use an awk parser to do an earlier pass and divide 
(gemtext and koutliner)
  documents into chunks (according to headers or blocks).

  
https://git.sr.ht/~indieterminacy/1q20hqh_kq-owo_interpreting_gemtext-glint

 From the chunks hashes shall be made, including of:
*    canonical s-exps
*    datalisps (formed from Qiuynonical)
*    third party formats (orgmode; latex; scribillo

These chunks and interpretations shall form individual files, to be 
cross referenced using the token database, ldif.
I understand that ldif plays nicely with emacs.

The current plans are for ldif for funneling issues and troubleshooting.

It should be Gemtext friendly but an inversion of the considered 
syntaxes (expessed here in a TXR form):

```
> # @nw-ue_mq-te_sequence_any-header@;; 
> iw-rw_heh-owo_found-during_parsing-involving-awk-too-glint
=> 
./mq-tet_raw/@xw-tet_mq-xw_w-te_hash-value-in-canonical-form@(os-2)@/\*#/@;; 
tet_mq-te_aggregate_body-with-header
=> ./mq-tet_raw/@xw-tet_mq-xw_w-te_hash-value-in-canonical-form@(os-2)@ 
\*/@;; tet_mq-te_constituent_body-without-header
=> 
./mq-te_canonical-s-exp/@xw-tet_mq-xw_w-te_hash-value-in-canonical-form@(os-2)@/\*#/@;; 
tet_mq-te_aggregate_body-with-header
=> 
./mq-te_canonical-s-exp/@xw-tet_mq-xw_w-te_hash-value-in-canonical-form@(os-2)@ 
\*/@;; tet_mq-te_constituent_body-without-header
@(maybe)
@(cases)
=> 
./mq-mqm_qiuynonical/@xw-tet_mq-xw_w-te_hash-value-in-canonical-form@(os-2)@/\*#/@;; 
tet_mq-te_aggregate_body-with-header
=> 
./mq-mqm_qiuynonical/@xw-tet_mq-xw_w-te_hash-value-in-canonical-form@(os-2)@ 
\*/@;; tet_mq-te_constituent_body-without-header
@(or)
=> 
./mq-tet_raw/@xw-tet_mq-xw_w-te_hash-value-in-canonical-form@(os-2)@/\*##/@;; 
tet_mq-te_aggregate_body-with-header
=> ./mq-tet_raw/@xw-tet_mq-xw_w-te_hash-value-in-canonical-form@(os-2)@ 
\*/@;; tet_mq-te_constituent_body-without-header
=> 
./mq-te_canonical-s-exp/@xw-tet_mq-xw_w-te_hash-value-in-canonical-form@(os-2)@/\*##/@;; 
tet_mq-te_aggregate_body-with-header
=> 
./mq-te_canonical-s-exp/@xw-tet_mq-xw_w-te_hash-value-in-canonical-form@(os-2)@ 
\*/@;; tet_mq-te_constituent_body-without-header
=> 
./mq-mqm_qiuynonical/@xw-tet_mq-xw_w-te_hash-value-in-canonical-form@(os-2)@/\*##/@;; 
tet_mq-te_aggregate_body-with-header
=> 
./mq-mqm_qiuynonical/@xw-tet_mq-xw_w-te_hash-value-in-canonical-form@(os-2)@ 
\*/@;; tet_mq-te_constituent_body-without-header
@(maybe)
...
@(end)
@(or)
...
@(end)
@(end)
```

This tree approach allows search utilities to get an overriding 
impression of a document and how it interleaves with other documents and 
project environments.

I feel it should give an idea as to how an knowledge ecosystem is 
changing over time, especially if contexts are provided in git messages 
for this hashing technique.

Hopefully it can encourage users to have greater granularity.
I feel that it will be useful covering my extremely wide and flat folder 
structure within my system.
Ultimately, I want to track concepts as they move within documents and 
across filetypes.

If you want to see an example of how gemtext and git integrate nicely 
with respect to task-management I encourage you to visit this Guile 
project:
https://github.com/genenetwork/gn-gemtext-threads




Qiuy is a knowledge and interface orientated solution for Semantic 
Business Process Management (SBPM) type concerns:

*    It uses notation that has the same physical patterns that are used 
by any user requiring
     the use of modifying keys to command things quickly
*    Qiuy is not constrained by being contained within one tool, one 
language or one format
     (let alone languishing in logfiles).
*    Its notation serves as a universal prefix, which is front and 
present, terse and proud - permitting people to autonomously
     augment according to need, toolsets and context.
*    As such, it is not a destination point in itself - rather a means 
to an end to reach a goal in the quickest and most succinct way.
*    A direct consequence of this is that recall and interaction can be 
managed according to tactical criteria
     (such as repeatability; signalling; extensibility; or scope)

As such, Qiuy is beneficial for domains such as identifying other 
semantic modelling constructs within or across collections
(for say drilling down or across collections such as RDF constructs), or 
providing entrypoints for integrating information assets
from alternative linguistic languages (such as Lojban); syntaxes; or 
formats.

Predicated on putting explanations and expectations into chunks,
Qiuy is a mechanism for description; interpretation; interfacing; and 
change -
recursively, whether in imperative; declarative; or functional forms.


Below are examples concerning Qiuy's graph orientated approach to 
taxonomies and ontologies.

So for instance for search criteria:

a policy on tasks:
iw-rqr

a task concerning internal-policy:
rqr-iw

an observed task concerning third-party-policy on the topic of 
running-events:
rer-ie_rqr-iwi

completing a policy-position around parsing-results
rwr-iw_hwh

These annotation sets of 40 (36 (single or repeated letter) archtypes 
and four for direction and/or normative and positive demarcations)
Two annotations combined creates a permutative range of below 17k 
combinations.
Im often writing with 4 annotations in combination with differing types 
of delimeters and descriptions
(with the weighting of the stack to aid handpicking subsets).

There are few clashes with these notations with conventional texts and 
coding.
The discipline has more of an improvisary and fuzzy quality to it, as if 
the initial pathway to something isnt immediately
  found there are enough workflows and heuristics to find something (if 
not reevaluate).

As such, from the perspective of metaphysics it is operating as 
something more akin to body-language.
Or from a scientific management, something like Pitman shorthand.

Im sure you can appreciate how Hyperbole's context aware actions can be 
potent for identifying and acting upon these annotations.


In relation to databases, the value of having an interpreter for 
representing Qiuy annotations will be significant.
This is because that database will be able to grep whitespace delimeters 
in used within queries for annotations or annotations.
Otherwise, only full capture when using '-' or '_' delimeters.

I find my Qiuy annotations, they are similar length but terser than 
shorthands or triads.
I increasingly use triads as a technique to delineate between 
descriptors using these annotations.

Heres this primer on the types of annotations and how they operate 
within a filesystem:
https://10years.guix.gnu.org/video/l-union-qiuy-fait-la-force/

In essence, Im trying to represent a universal prefix to serve as a mid 
semantic point notation - within and across systems.

You might appreciate how encapsulating is advantageous from a cognitive 
as well as an accessibility viewpoint.

These tooling environments combined in an emacs environment permit me to 
really move across a filesystem rapidly and switch contexts casually.

The proliferation of my annotations across content and coding give me a 
sophistication that grows capacities unimpeded.

If you visit these logs you may get a better idea regarding how I use 
these annotations are used for managing a project:
https://git.sr.ht/~indieterminacy/1q20hqh_oqo_parsing_qiuynonical/log

Fwiw, I started writing a book on Qiuy, though it covers the topic from 
a more artistic perspective and is now a couple of years old:
https://matrix.to/#/!moDjfUaAGUFxVySkEd:matrix.org/$SOThirF1w3DwXQxIg56Anu5vjztoT1R99ClWzqxKuJY?via=matrix.org&via=kernelpanic.cafe


HTH!

When Im not yak-shaving I can be found here considering such topic areas
https://matrix.to/#/#xq_icebreaker:matrix.org


>> 
>> On Fri, Jun 24, 2022 at 6:55 AM indieterminacy
>> <indieterminacy@libre.brussels> wrote:
>> 
>>> Hi Robert,
>>> 
>>> On 24-06-2022 07:34, Robert Weiner wrote:
>>>> Hi Samuel:
>>>> 
>>>>> On Jun 24, 2022, at 12:32 AM, Samuel Wales
>>> <samologist@gmail.com>
>>>>> wrote:
>>>>> 
>>>>> for starters, does hyperbole have any concept of links that
>>> are:
>>>>> 
>>>>> - unbreakable [like org-id]
>>>> 
>>>> This one is not so simple to answer.  Hyperbole only uses
>>>> perma-hyperlink anchors in its Koutliner format.  But it would
>>> be
>>>> straightforward to add a UUID-type id for use elsewhere.
>>>>> 
>>>>> - bidirectional [link a goes to link b; link b goes to link a],
>>> or,
>>>>> reversible via command to say "what links here?" [by any
>>> mechanism.
>>>>> if desired, please see "id markers" concept on this list for
>>>>> unbreakable bidirectional links and more stuff]
>>>> 
>>>> Hyperbole does not have bi-directional links, only a history
>>> function
>>>> to move back through followed node paths.  We have started
>>> thinking
>>>> about this need recently.
>>>> 
>>>> — rsw
>>> Improvements to the backend of Koutliner would be useful,
>>> especially as
>>> (if I recall from the documentation) the API aspects are not so
>>> clearly
>>> defined.
>>> 
>>> Bi-directionality would be a priority IMHO, especially to
>>> facilitate the
>>> updating of all links targeting a specific block should it move.
>>> 
>>> At the moment, each link self updates when it identifies a
>>> reference
>>> which needs to be updated but that comes across as an expediency
>>> (which
>>> I mitigate with direty look running through links to validate they
>>> are
>>> functional).
>>> 
>>> It would be great to achieve this with an 'eventual-consistency'
>>> type
>>> way, given that files could come in and out of a system or
>>> network.
>>> 
>>> Similarly, allowing the perma-hyperlink anchors to be transferred
>>> would
>>> really mature the format.
>>> 
>>> Here are some umble functions I use to facilitate moving blocks
>>> into
>>> other files:
>>> 
>> 
> https://git.sr.ht/~indieterminacy/1q20bwb_oq_transferring_emacs/tree/main/item/kqk_kq_blocks_koutliner.el
>>> 
>>> They at least avoid being descructive, as after moving the block
>>> becomes
>>> a pointer to where the moved block ended up in the other dcoument
>>> - but
>>> it feels like a fudge which could turn some documents into
>>> spaghetti.
>>> 
>>> While Im sure that you are planning on solving these problems
>>> within
>>> eLisp, I should point out that I shall have a Koutliner parser,
>>> written
>>> in TXR (soon to be finalised, Ive had some familial and health
>>> impedencies recently).
>>> 
>>> Here is a WIP
>>> https://git.sr.ht/~indieterminacy/1q20hqh_oqo_parsing_glean
>>> 
>>> And a (rough) example
>>> 
>> https://git.sr.ht/~indieterminacy/1q20hqh_oqo_parsing_glean#examples
>>> 
>>> I do need to add some facets (I suspect the linking for other
>>> blocks is
>>> in a seperate script).
>>> I shall also be integrating the parser with GemText (Orgmode would
>>> be
>>> nice one day too).
>>> https://git.sr.ht/~indieterminacy/1q20hqh_kq_parsing_gemtext/
>>> 
>>> I do quite like TXR's datalisp format but I havent gotten around
>>> to
>>> finding a way to slurping it up into eLisp. I feel like it should
>>> be
>>> easy to resolve but its not a query which is easy given SEO
>>> search.
>>> 
>>> The way Ill be approaching this interpreter is that it could
>>> search the
>>> aggregate or a journey from one document. Being able to have an
>>> overview
>>> of multiple documents is something I consider to be helpful, given
>>> the
>>> domain of cross-referencing.
>>> 
>>> and FYI, I will be working on outputting RDF from Koutliner and
>>> GemText
>>> analyses.
>>> 
>>> --
>>> Jonathan McHugh
>>> indieterminacy@libre.brussels

-- 
Jonathan McHugh
indieterminacy@libre.brussels