In reply to “Change is expensive” by Frode Hegland. This is mostly sequential commentary in the order of paragraphs in the source. Would work better in a system that supports annotations, side-by-side, visibly connected. Where change is expensive, wouldn’t make it sense to work on making it cheaper? The example of Engelbart shows that change can be made sufficiently cheap so it becomes affordable to have lots of it. Who cares about actually changing standards (?) if you can have and make lots of them? Better to have standards than everybody doing their own thing in an incompatible, conflicting way! Isn’t the knowledge worker somebody with highly specialized needs, tools,…
-
-
HTX Integration
The “htx” parts in digital_publishing_workflow_tools with the earlier predecessor automated_digital_publishing comprise the early stages of a system that implements an abstract capability architecture standard (think POSIX) around the notion of small, independent tools/components supporting each other to perform higher-level operations. The goal is to build an Open Hypertext System for document aspects to follow later once the foundation is in place. Integration can happen by adding a capability implementation or the whole system to an existing application or to call it as an external function/service. Another way would be to register an existing application or capability as the implementation for the system to invoke it, which requires the conformance of…
-
Personal Hypertext Report #9
Finally, I’ve managed to get the “change_tracking_text_editor_1” capability working reliable enough for beta testing and prepared a downloadable package: hypertext-systems.org/downloads.php. Java 1.6 or higher is required. A description of the tool/capability can be found in this video. From here, plenty of very interesting options to extend it present themselves, but I find important to point out that in my opinion, tracking the development of a text is fundamental for a hypertext system and serious writing on a computer. Without it, versioning and revision can only be done retrospectively with heuristical diffs as after-the-fact analysis, which can be wrong and lacks information like the order of changes or changes that later…
-
RFC: Summary Data Formats
A summary/abstract capability can be implemented like this: <summary>This is a summary.</summary> In compliance with a HTML 5.1 proposal, it’s also allowed to be wrapped in a <details> tag, <details> <summary>This is a summary.</summary> </details> although this form isn’t recommended and a transitional provision for the time no semantical identifier has been assigned yet. Clients are free to ignore the <details> wrapping. Clients are also free to ignore any other tags within <summary>, the expectation is that the text nodes regardless of other tag encapsulation will be rendered. It might be important to point out that this RFC doesn’t imply that semantic meaning is derived from the HTML 5.1 proposal…
-
What Sucks about Blogging
Blogging as a practice is just fine, what sucks is that the way we do it isn’t hypertexty enough. Blogging as a practice in itself doesn’t suck at all. Writing diary or articles or entries in a journal is just fine. It’s the way how we do it today that needs improvement. I have an incomplete list of desired hypertext capabilities, but when looking at only blogging activities in isolation, it’s also clear that a different hypertext capability profile/subset is needed than for other modes of working on/with text. What sucks about blogging on the web is the absence of that particular capability profile. This is an incomplete list as…
-
Personal Hypertext Report #6
Stephan Kreutzer doesn’t want to work on a WordPress enhancement: the current posts on the default installation broke XML processing by a non-browser client because of a named DTD entity and bugs in WordPress’ wpautop() function – both unnecessary problems caused by the general web context, too expensive to fix and difficult to work with. There’s great consensus that the first project, the jrnl, should be a WordPress enhancement project. I’m happy with that as a good practical compromise for bootstrapping ourselves: it’s readily available and many people know how to set it up and/or use it, it’s libre-freely licensed (not ideal though, GPLv2 makes no sense for software that…
-
Re: jrnl launch meeting announcement (for Friday 24th of August 2018)
This is a reply to “jrnl launch meeting announcement (for Friday 24th of August 2018)”. It’s a little surprising that the Journal/jrnl in an already very, very specific form is supposed to be the main topic, despite it’s still unclear to which extent the potential participants write about their research and work or plan to, or if that should be the main interest or first strategic goal for now. For a long time, I keep repeating that even WordPress comes with many problems, I wonder who’s supposed to work on these. The proposal continues to suggest that the jrnl should exist as just another blog or website, following the traditional…
-
Re: Friday
Today, Frode Hegland officially confirmed the first meeting of the Future of Text Institute on the 2018-08-24. With that I received a mail from him, to which I was asked to reply, so I try to do it here. The meeting will introduce the “jrnl” software project, an attempt to make a more Engelbartian blog system, likely the first major topic for the FTI. As it became possible to study Douglas Engelbart’s ARC Journal in more detail, it looks like NLS and Journal are quite distinct and relatively independent from each other, which allows for both to be investigated and recreated as a capability separately. If we would want to…
-
Stephan Kreutzer
I maintain an updated profile on my about page that includes a collection of links which lead to my other online presences and projects. For the context of this effort, I also describe most of my earlier and current work in this article. My contributions to this initiative usually won’t reside on this site as I’m able to build and run my own hypertext systems that hopefully will compose material from different sources into a virtual space or combined rendering, something like that. My results can be found on publishing-systems.org for automated conversion workflows and single-source, multi-channel publishing (working with legacy, bookish-style material), complemented by hypertext-systems.org for the more hypertexty…
-
RFC: Glossary Data Formats
First stage For now, we can use the following format to specify glossary entries for the Journal: <dl> <dt>Media Fragment</dt> <dt>Media Fragments</dt> <dd>Paragraphs, datasets, images, topic maps, glossaries… that go into forming one or more document(s).</dd> <dd>This glossary entry is a media fragment, and each of its parts could be as well.</dd> </dl> As the Journal is currently stored in WordPress, we might use its data model to some extend, but will abandon that more and more by abusing it as generic online data storage, where any arbitrary data is stored in the content-body of a blog post. This will render all plugins, themes and administrative tools on the server…
