change_instructions_navigator

The Future of Text Institute already lists a <a href="https://thefutureoftext.org/projects.html">series of projects</a> that happen to be of interest. I’ll try to align my activities towards these where it makes sense. I agree that the first step should focus on retrieval and reading, because we can fake authoring for quite some time and the WordPress editor is already available as a writing interface, but reading is reading, so there’s no way around consuming what we produce, otherwise it would simply remain unknown. If the Institute wouldn’t encourage decentralized blogging right from the start, a centralized Journal would make it much easier to bootstrap in the traditional way with authoring tools as the first step and a central place to learn about published material, but this isn’t a big issue, it can be done either way. The Journal project proposal heavily relies on WordPress and RSS, which are both nice in some ways, but come with a bag of problems of their own. RSS exists to optimize the retrieval of the newest resources, which might not be very helpful for navigating interconnected text. WordPress is a pretty decent server package, but it’s primarily geared for browser consumption, which isn’t very helpful and can cause serious conflicts. I also want to point out that we already failed one earlier time to implement a HyperGlossary with WordPress (or did we succeed individually, just not collectively?), maybe due to social reasons and not technical ones. Have a look at Frode Hegland’s implementation (<a href="http://www.liquid.info/glossary.html">proposal</a>, <a href="http://wordpress.liquid.info/ohs-2/">example</a>, <a href="http://wordpress.liquid.info/hyperglossary-posting-via-liquid-v1/">interaction</a>), Gyuri Lajos’ <a href="https://jrnl.global/2018/11/20/semantic-web-compatibility/">proposal</a>, Christopher Gutteridge’s <a href="https://github.com/cgutteridge/glossyx">implementation</a> and mine (<a href="http://doug-50.info/journal/2018/04/07/rfc-glossary-data-formats/">proposal</a>, <a href="http://doug-50.info/journal/2018/02/11/viewspec/">example</a>, <a href="https://www.bitchute.com/video/Nu2Cv9fc8cvT/">interaction</a>). Now, in the context of the FTI, it’s obvious that we do not necessarily need to come up with a single approach on how to implement a glossary capability, but it is clearly demonstrated that everybody only implements their own thing the way it fits best into the already existing project, with no interoperability/collaboration going on. There are more problems with the project proposals: using some commercial offers can be OK depending on the circumstances, owning the system and providing it as a commercial offer are distinct, who knows if propaganda and fake news are useful categories to think about, ViewSpecs not only need to be text operations but could also be specifications for graphical display/rendering, PDF should not even be mentioned for anything other than printing regardless of whatever attempts Adobe comes up with to make it “interactive” or “rich”, it’s not true that citing and high-resolution linking in e-publications isn’t possible because of commercial barriers (these are proprietary, restrictive barriers that can be present even at gratis or theoretically libre-licensed publications), the claim that there is a need to start an open addressing scheme for proprietary publications (they deliberately don’t want to be cited or linked, so just leave them alone and respect their wish to stay irrelevant!), the limited use of “open sourcing” an application that is trapped on a proprietary host ecosystem (algorithms, artwork, other parts might be useful to the libre-free software world, but then again, “open sourcing” something for the wrong reasons might lead to disappointment). Still, there’s no need to arrive at full agreement within the FTI on every point listed here, and it needs to be reiterated that many of those proposals are in their first draft, so we’ll probably discuss them in much more detail and certainly invite further comments as well. The “Links in Images” capability is very easy to do as I tried to indicate in my brief <a href="https://skreutzer.de/2018/07/11/hypercard/">HyperCard investigation</a>, even in native programming I can’t imagine it being too hard. At the same time, it’s probably by far not the most important feature for bootstrapping systems that primarily deal with text. The Journal project may or may not be influenced by the recent analysis of the ARC Journal files from SRI, or only by the earlier published material or account by Doug himself, in any case: it’s an open question to what extend the FTI should try to replicate the ARC Journal in modern technology, and where it should take liberty to expand, limit or adjust the example of this earlier system. I abandoned the idea as it became clear in the Doug@50 group that I would be alone in replicating the Journal capability, and while it is still very useful for a single individual to have it, there are significant differences in how to go about it if it is for personal use or to be used by a group. The latter would greatly benefit from bootstrapping, which you can’t do just on your own. So I went back to basic capabilities, but a Journal for the FTI would equally make sense as the first step. I already built a few components that could help with this task: a primitive StAX implementation for programming languages that don’t come with one (<a href="https://gitlab.com/publishing-systems/CppStAX">C++</a>, <a href="https://gitlab.com/publishing-systems/JsStAX">JavaScript</a>) for properly reading RSS, an EDL-based <a href="https://www.bitchute.com/video/UZmca59a20Ez/">generic retrieval mechanism</a>, a <a href="https://www.bitchute.com/video/agkvwxYtL6YD/">WordPress retriever</a> and a <a href="https://www.bitchute.com/video/CTwgzo6Wax1y/">WordPress uploader</a>, all of which would require more work or re-work for this project, but what major obstacle would prevent us from just building a first prototype and then bootstrap from there? A few capabilities/components are still missing, for example local storage management, federation of sources and a dispatcher based on semantics to invoke a basic ViewSpec mechanism. Other approaches might even be more viable of course, this is just an early offer/suggestion. For the FTI Journal, I plan to publish my “journal entries” in some form (be it a WordPress instance as it is now or raw resources) under my <a href="https://skreutzer.de">skreutzer.de</a> domain to make it clear that those are personal opinions, not official statements by the FTI (if there can be such), and <a href="http://www.hypertext-systems.org">hypertext-systems.org</a> might provide federation services beyond my own material, but also not necessarily identical to the official structuring of the FTI corpus, over which I don’t have any control nor need any in a decent federation. This text is licensed under the <a href="https://www.gnu.org/licenses/agpl-3.0.html">GNU Affero General Public License 3 + any later version</a> and/or under the <a href="https://creativecommons.org/licenses/by-sa/4.0/legalcode">Creative Commons Attribution-ShareAlike 4.0 International</a>.