From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id gEuUItqZQ2OV5AAAbAwnHQ (envelope-from ) for ; Mon, 10 Oct 2022 06:04:42 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id eJ+oIdqZQ2OEcwAAG6o9tA (envelope-from ) for ; Mon, 10 Oct 2022 06:04:42 +0200 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 3773D9C7E for ; Mon, 10 Oct 2022 06:04:41 +0200 (CEST) Received: from localhost ([::1]:57370 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ohk1v-0003jm-KA for larch@yhetil.org; Mon, 10 Oct 2022 00:04:39 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:46884) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ohk0U-0003ij-CC for emacs-orgmode@gnu.org; Mon, 10 Oct 2022 00:03:10 -0400 Received: from libre.brussels ([144.76.234.112]:55734) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ohk0N-00038i-Lx for emacs-orgmode@gnu.org; Mon, 10 Oct 2022 00:03:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=libre.brussels; s=mail; t=1665374570; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=5CYp1KITNsmXdZR82Vq9NB/LA9vzzWBxzb6dmiJ9W6U=; b=dh44LvIUrqheEMmm5Xgeiw+Ct3DQGhtWOBAxwr6lxP/GJBqjI+tGV/GmRLv7p9VCdlToAT wUvlQwkAN5xsRyLkFNjMCUrtw5HYRRCfdJKH3aO0ozfRBDOhVD3BvggOcLvGYFTCceg5LA P/DGhaZw59Xb7+94G0rdihANtA6TqTE= MIME-Version: 1.0 Date: Mon, 10 Oct 2022 06:02:50 +0200 From: indieterminacy To: rswgnu@gmail.com Cc: Samuel Wales , emacs-org list Subject: Re: Org and Hyperbole In-Reply-To: References: <813D3F10-3E3C-497F-9FD8-FE0DA13C2970@gmail.com> <7befc1b0378c484ad18e1d8103889ea7@libre.brussels> Message-ID: X-Sender: indieterminacy@libre.brussels Organization: Icebreaker Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: pass client-ip=144.76.234.112; envelope-from=indieterminacy@libre.brussels; helo=libre.brussels X-Spam_score_int: -16 X-Spam_score: -1.7 X-Spam_bar: - X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Migadu-Flow: FLOW_IN X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1665374681; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=5CYp1KITNsmXdZR82Vq9NB/LA9vzzWBxzb6dmiJ9W6U=; b=tMXgwZUABj2aKDpM25IFur6gx/piRWr8CKov1Ll729MTGeLQNtpf/mdLS9LEBG5AbCYgS1 GFCoYg3KwnHBs1+9q2A9Oe2ogj8xwTFWIktQ0VTuNSmBcJ+8r/MCbEIr1vHJjlms7VQbFp agoQCw8/o7WdzMwLID4hB2SpuNtox8m6oeIgvRzwbmQ0eHMVfQ+qzCkrOI+rLooLSgnqel zHPUfN1KdSyDa8dk42AxjrnHQ1bDWDT/y9Rp7ZCyZWz3xTvp5YDJTa87AhVtl8H2bZiIqV 8b8quTjbUDPfDyXDpZVkJJjUyQ6h+ODeElZb++othpSeEnwqGfA13SJf+q0p6A== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1665374681; a=rsa-sha256; cv=none; b=RVVSlGrDIpBw1Zjh+O1RbKRlw7iJNXcFSixay9Dv46TEk7OXCbmEH7cU4n+s32EkPNnuon AoHYjwiPg8vFL76OCLB6PPH4+yWFNbErAtMVovs/KmBlyPCYkD4CdyvHhflEA61s02PC31 kWi3INF+dYYfXmrosFwufZfL7EE3jNY8dy//0tPqRlcTxzSb09u2MijqPxem+0rweK7Lz4 6a8dwX9tKPBfaEslrQ8/4dFVWQ0xsvVnSzgft64U6sCJqxZmg8CG7XKgBFY4IOlDI+fSHW MZ4uyhPq3otSGmHIl6ARAyh1kwaz4YqD7MYsiltNChnhTlKJbuzoNl9E30AU1Q== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=libre.brussels header.s=mail header.b=dh44LvIU; dmarc=pass (policy=none) header.from=libre.brussels; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: -7.48 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=libre.brussels header.s=mail header.b=dh44LvIU; dmarc=pass (policy=none) header.from=libre.brussels; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: 3773D9C7E X-Spam-Score: -7.48 X-Migadu-Scanner: scn0.migadu.com X-TUID: pzA8StKi+Wwc 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 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 >> wrote: >> >>> Hi Robert, >>> >>> On 24-06-2022 07:34, Robert Weiner wrote: >>>> Hi Samuel: >>>> >>>>> On Jun 24, 2022, at 12:32 AM, Samuel Wales >>> >>>>> 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