Ted Goranson - Personal Blog

The first function of this new project will be to serve as a simple blog; I'll start with entries like this one on the project, and occasionally add some personal stuff. But the main function of the site is to host some highly structured documents that both describe some ambitious research and demonstrate some elements of it. As those documents grow, I will use the blog to let you know what is going on, both in the work and the documents.

That way, you can track progress by simply monitoring the RSS feed of the blog area. I suspect that the three research areas (Film, User Interface, Narrative History) will be of interest to three different communities, so I have segregated the blog’s outline accordingly. You can see that outline by selecting the by outline popup in the upper right.

The outline of the blog may change over time. At this writing (3/21/12), the plan is:

• A personal section with, well, personal posts plus notes like this one on the site and tools.
• A section on Virtual Enterprises. This blog section does not have a corresponding large document on the site as do the ones listed next. Therefore, I will be populating that blog section with a few observations on the work I do to (usually) earn a living.
• The section on FilmsFolded. The structured document in that section of the site is the one I will start first. There is an active community to help and gosh it is fun. As that FilmsFolded section is built, the FilmsFolded blog will report on what is going on.
• A similar section on user interface studies we call Kutachi. A similar relationship exists; that area of the site will host a differently ambitious structured document and the kutachi blog area (probably mirrored on the symmetry site) will report on that project.

Another area on the site is called GeoKabbalitter. This will be much larger, more deeply and experimentally structured. FilmsFolded and Kutachi are planned to be collaborative projects, but Geokabbalitter is not, and it may well appear on the site whole when it is done. Therefore, I plan no blog area to report progress.

Navigating By Structure

The deep structure will be created on my personal machine, using some new theoretical notions. I plan several ways to present this structure here:

• That popup in the upper right is designed to show a couple lists created by structural affinities among notes. The blog will be the first to experiment with this. The idea will be more impressive under the hood than likely obvious in use at first. Current ‘by similar’ techniques use lexical means, basically matching words and word proximities. Our structure traces semantics and will allow a demo of matching real meaning, even narrative intent.
• We also plan a graphical diagram that shows the ontological nets we’d be using. This would likely be appended to the note when the ‘by similar’ option is chosen.
• Within FilmsFolded we plan to implement an experimental interface that uses a completely different and novel layout.
• The Tool Area is designed to dynamically illustrate the narrative structure encoded in GeoKabbalitter.

I’m using Attribute and Preference defaults updated for Tinderbox v9.6.0 as a platform. It does some things well and some things extraordinarily well with a tightly integrated set of capabilities. It does two things that I believe are unique: it is an experimental platform for ‘spatial hypertext’ and it supports typed links.

Spatial hypertext is apparent in two Tinderbox views: the so-called ‘map’ view which has unique spatially structured zooming, proximity association and simple graphic tools. The outline view is a nested graphical structure of notes, more well developed structurally than any other. In both of these spatial views, links can be ‘physically’ created by dragging and dropping, even across windows and views! Our approach will use these links extensively, so an observation on links follows.

Tinderbox has its legacy in the hypertext world, a once rich community of researchers who were exploring how computing could free us from the limits of linear narrative. Unfortunately, the web came along and pulled the energy out of that vision because links conceived more broadly than ‘go’ were essential for hypertext. Tinderbox is less constrained by the constraints of this web thinking than other environments, at least before you export to html.

Web links are along a spectrum of two types: navigation and annotation/expansion. When you see and click a link in a browser (or browser-like application) you have a pretty good understanding of what is going to happen. You will be taken somewhere. Perhaps the click is purely to get you where you want to go. Or perhaps it is to take you to a page where you can find out more, or to follow a designed thread. There is often some surprise at what is at the other end of a link, but there is absolutely no surprise in what happened when you clicked it.

One view of hypertext had links as multiple pathways through a collection of specially designed narrative fragments. The reader created the path through the fragments. Perhaps pathway options changed based on history. The link in this paradigm was a user-defined ‘and-then’ link. We add a few different approaches.

Our documents are likely to have at least these types of links:

• Navigation Links: These are the ordinary web sort, though we discriminate among those that are to external sites, those that are internal to this site but that cross sections and those that are internal to sections (like the blog).
• Parenthetical Links: These follow the idea of stretchtext. They are marked between words and whenclicked the textfield expands to show the parenthetical text, reference or marginalia.
• Ontological Links: These are used within Tinderbox to enrich structure by linking to formally structured definitions. These enable quite a few novel advantages, some of which should appear soon.

We are currently putting these together, and the site you will ultimately see will have these displayed. We wish to also have:

• Situational Links, where one can ‘zoom out’ to understand context. (The unhoisted outline and map views are two ways of displaying context.)
• Reactive Links. While all the links can be dynamic and propagate change, some links are designed with this in mind. ‘Trigger links’ are user interface items that instigate change; ‘state links’ are largely for system use and track certain state changes, establishing complex (including quantum) causal relations; ‘topological propagation links’ which are similar but deal with structural qualities less intuitively related to cause.

These notions do not have a heritage in hypertext. Yet.

I am way early in setting up this Tinderbox document. It is an ambitious project; while Tinderbox offers the ability to ‘add structure' to notes well into the game, my intent requires that I make as many macroarchitectural decisions as I can, early in the game.

I have a late model, pretty juiced up 17" MacBook Pro. This is the main machine which travels with me, and travels well. It exists to create two documents. One is a traditional document which I won't describe. These go on the company site, Sirius-Beta.com.

The other is this document you are reading now, which is authored in Tinderbox. I'll write about its structure and goals in another note. This note is a record of how that document is fed.

Writing in Tinderbox is pleasant, and essential when adding structure. But when the item is longish, I edit in BBedit, using some associated utilities. A QuickCursor operation, paste or drag puts the foundation text in Tinderbox. Some Quickeys macros help. (Custom gestures are planned.)

But what if I do not have my MacBook in front of me? I have a Pismo and an iPhone.

The iPhone is connected three ways.

• The rather marvelous Simplenote technique. Writing in the Simplenote app (or their website) places a note in Tinderbox's Simplenote container.
• The Dropbox technique. Writing in one of the Dropbox editing applications places or changes a text file in all my Dropbox images and these can be dragged to Tinderbox. Dropbox may be doing some undesirable things though (in terms of privacy).
• The Email technique. Writing in an editing app and mailing to a dedicated mailbox places that note in a mailbox that Tinderbox monitors. This has the advantage of triggering actions from instructions in he beginning of the note. It also allows for a wider selection of editing apps.

The Pismo is an 12 year old Powerbook that just keeps chugging. I keep it in the car, charging from the cigarette lighter. I like it because it is rugged and can be pulled out opportunistically. I describe it more below. It connects:

• By Dropbox, using a BBedit project file. This has the advantage of allowing work on large complex documents in process.
• By Dropbox. using a ‘scratchpad' Tinderbox file. This has the advantage of letting me work in Tinderbox, convey user attributes and outline structure and work on complex documents.
• By Email of course. This has the advantage of allowing me to boot the Pismo in Linux and get better power management.

I am experimenting with an ultralow power consumption solution on a different Pismo:

• A 400Mhz G3 with a Compact Flash Hard Drive, 801.11b wifi and 1G RAM.
• Running a barebones MintPPC.
• Running only some version of Mozilla with QuickFox Notes, a Simplenote and Dropbox editor.

On this site, and in this single Tinderbox document, we will have four types of documents:

• The blog with blog sections
• Lightly structured documents, being somewhat ordinary style linear documents but with enhanced structure.
• Heavily structured documents, being unique to our approach
• A modeling tool for heavy structure and related dynamics.

Starting with the blog (and its web presentation) is something of a challenge because it has to be designed to deliver the ordinary functions of a blog; however, we also want it to fit into the larger picture with the fuller capabilities. We want to leverage the unique strengths of the tools we are using, together with specific qualities of our theoretical approach that we want to demonstrate.

But in getting the blog up, we want to do it quickly and incrementally introduce more radical capabilities over time. So what to focus on initially?

Tinderbox is a rather special tool in the combination of things it offers. But there are two things that make it extraordinary. One of them will be completely ignored in the blogs: the way it handles ‘spatial hypertext.’ This is novel and exciting; Tinderbox could be considered a platform for researchers in this area, and our tool will be squarely in it.

The other unique capability is that Tinderbox handles typed links. Ordinary web links can be only from text blocks (and graphic objects) to pages (or premarked locations in pages). Those links are a stupid ‘go here for something.’

Tinderbox links can be to and from notes and text blocks. And they can have any number of user-determined types. These types by themselves are really not much more than ordinary links with names. But the application allows us to see the links and use the values in the built-in note manipulation (and export) language. You'll hear more about this in other areas.

I'm mentioning it here because it is what makes our blog architecture unique. Other blog tools and their file management counterparts use ‘tags,’ designators that describe blog posts. There's really very little you can do with conventional tags. Additionally, there is only so much you can do with comparing the actual words in the note to words in other notes and references. On the other hand, lots of capability can come from typed links if they are implemented in a way where transformative functions are associated with them.

This is what we will be doing sitewide; it will be risky because we will be working with both our limits within the theory and the limits of the tool. The initial blog implementation will be fairly simple: we will present our tags the way other blogs do. We will also write within an outline structure with aliases. Both will be displayed as navigation in the ordinary way.

Internally, a tag will be implemented as a link of type o_taglink to a ‘note’ object with the tag value. In the future, that note will contain functional code that is associated with the link and which may transform notes and code. All code will be in notes and accessed and triggered by typed links; then we should be able to go to town with exciting stuff.

In the short term, we'll use the links as elements of directed graphs to give us a better similarity measure among notes than you can get by comparing word frequency and placement the way Google does. We'll do that too: in fact Tinderbox already does!

My method will assign these ‘tags’ by dragging. Each tag is a ‘note’ so that a link need not be a word, but can be a whole dictionary entry, and it can be linked to other tags by ontological relationships. Also, I will trace second and higher order links; a first order link sharing is the same as ordinary tag sharing. Two notes with the same tags are presumed to be related.

But I can go deeper and see which of those notes have deeper links, and because the link structure is a directed graph (as well as the outline, attribute and prototype structures), all sorts of linguistic tools for understanding semantic distance can be applied. We aren't simply talking about lexical patterns (word match) any more.

More on links appeared earlier.

This note, and those that follow will only be of interest to those interested in details of how this thing works.

The Outline Structure

When I write a note, I am conscious of how it fits into the outline. There are many links behind the scenes that you do not see in the web output, but the outline structure is fully revealed here. I have, however, distributed it so as to make it friendlier.

The top level is the whole site, of course. A next level are the four areas, this blog area plus the three structured documents denoted by the glyphs on the left.

Each of those has subsections. You can see these by selecting ‘By Outline’ from the popup in the upper right. We are in the blog area, which (at this writing) has sections on Personal, Virtual Enterprise and so on. We are in the personal section, where I have also chosen to make remarks like this about the site. In the structured documents, you can think of these as main chapters, or parts.

Each section is populated by notes, which you can also see in the outline navigation to the right. A note has its internal outline structure as well. In the authoring environment, a note has two outline levels. The top level is the text that appears at the beginning of a web page. On this page, that begins with: “The first function...” and ends with “... illustrate the narrative structure encoded in GeoKabbalitter.”

Then we have subnotes, which you see on this page as collapsed bold titles. That is to say that these. Each note and subnote can have a further level of non-collapsed sections, also with bold titles. So the words you are reading now are in Ted Goranson> Blog Area> Personal Blog> Blog Architecture> Site Structure> Outline Structure.

Each note and subnote contains text that can further have outline structure in the terms of bullet lists:

• A first level.
  • A second level.
  • I do not go further than two levels deep.

Images are a sort of subnote, and they appear the same way, under collapsed bold headers. Images can appear in notes, subnotes and parentheticals.

Parentheticals

I make heavy use of parentheticals. If the outline structure described above can be thought of as a vertical depth, then most of the links you encounter here can be considered as a sort of diagonal. Links take you to 'notes' that provide more information but not within the controlled structure we've created. Parentheticals can be considered horizontal structure. A parenthetical on a printed page would likely be an endnote or a marginal note. As you no doubt already know, we've devised a way to have these inline likethis.

A related type of short parenthetical is written out — it is the kind of thing I'd appreciate — inline and enclosed in em-dashes.

Though not implemented at the time of this writing, Parentheticals in the structured documents will also contain bibliographic references.

Tinderbox is a wonderful tool, but I find myself writing complete notes in BBEdit and an iPhone editor.

Given the rather complex and unique structure of what I am about here, I had to create my own markup language. None of the existing candidates comeclose.

For goofy reasons, I've been calling it sidemark, because there are so many horizontal indicators.

Ordinary Styling

Like many of the others, I use *wrapping asterisks* where I want the result to be italics, the only styling I use for emphasis.

Bullet lists also use asterisks, two asterisks for a child. I do not give an example of the bullet sidemark here because it unavoidably produces the bullet list automatically. Unfortunately, that is the only sidemark tag that converts without action.

Outline Headers

Sidemark mainly uses vertical lines ‘|’. One line marks text that stays. Two lines demark text that gets relocated (usually to a field that acts as teaser text).

The main note’s title is marked thus:

||The Title with No Period||The teaser text that appears in the right hand side navigation rollover.

An ordinary header (like ‘Outliner Headers’ above) appears this way:

|Outline Headers

Headers for subnotes that appear on the web page as collapsed sections:

|The Section Title||The teaser text that appears under it, which disappears when opened.

Macros

Two of the most advanced effects require Tinderbox macros. We cannot show them directly in this note because they get translated. At the end of this subnote will be a screenshot.

One macro is for inserting an image, the other for inserting a parenthetical note.

In sidemark, the parenthetical location between two words is marked with three lines: like|||this. The parenthetical text after the marked paragraph looks like this:

||Paren

My parenthetical text goes here.

Paren||

The image sidemark is similar to a header:

|The Image Title Here||The teaser text here, also used for the alt text.||The caption here, possibly quite long.||<image-filename>

In the Tinderbox file, these appear with some surrounding code, which is dimmed.

Links

We have ordinary links, the kind you see every day that take you places. The source in Tinderbox will also have other sorts of enriching links, but this is experimental. In any case, I do not specify the non-navigation links in the sidemarked text editor. We do discriminate three types of navigation links: those within a section of the side (for instance among the FilmsFolded essays); those across the site; and those external to the site. These are discrete types by all marked the same way:

Some text with |a marker|<a note or URL>> some more text.

^do("FigStart","An Example of Markup Text","(Image) A screenshot of a BBedit session for a note elsewhere on the site.")^

^do("ImgTag","foldername","image filename","Alt/Title Text", "px Width", "px Height")^

This website/blog is one product of a rather ambitious project. The platform I am using is Tinderbox, supplemented by other tools. The system is designed using an experimental conceptual framework. A key concept in that framework is the notion of function. I’ve had to examine just what I need in the concept of function because the cost of bending my development platforms to the functional framework is high.

The benefit I am looking for is extended from some research we have been doing for some time. The basic idea is simple; our primary object of interest is the situation. A situation the way we conceive it is a structured collection of information, only some of which is explicitly known. We think of this structure as following some laws related to narrative. This is based on the theory that we interact with the world not in terms of facts but in terms of stories (or something like them) and interpret facts in the context of situations.

Situations are therefore stories and memories and references structured as stories. Unfortunately, the logical systems used in simple formal reasoning systems and all computerized systems handle this notion of situation poorly. So instead of the usual set-theoretic framework that most reasoning systems use, we invest in category theory. Situations are modeled by categories. A category is a rather abstract mathematical object that has the advantage of modeling structure and relations.

Categories are our basic object in the conceptual framework. Categories are related and transformed by mathematical operations that map and/or translate structure. In our work, the types of categories and the types of these category-to-category relations vary. The important point is that the way we implement this framework in a machine, regardless of the complexity of the categories and operations is by functions. The requirements of functions that we are looking for, come from this notion of a function as a narratively informed structural transform. For instance, the changing interpretation of a story from one state to another is a matter of functional transforms.

Thus, we have to think of what a function is in terms of these structural transforms first, and then think of what that means in terms of programming concepts. Fortunately, there is a robust formal methodology here. Then we have to worry about how to actually code these functions in the frameworks we are using; this note addresses functions in the Tinderbox framework.

Tinderbox has its own built-in action code and export languages. They have evolved and changed over time and unfortunately employs several different syntaxes. Many of the operations we ask Tinderbox to perform are pretty low level, and it superficially seems to not make much sense to impose the functional style at this level. In functional programming systems, it is common to have the high level operations be functional and the low level ‘internals' more procedural and hardware specific.

One reason we picked Tinderbox is because it uniquely can support typed links which we will associate with functions; these map among notes and ‘situations’ of notes. In other words, the stuff the user sees in Tinderbox is close to the stuff we are operating on and the links are close to representing the operations. Moreover, the narrative-story metaphor is carried in (most of the structure) the text in Tinderbox notes. That means we have to make Link-triggered Tinderbox operations — at least the ones we care about — behave as functions.

What do we care about? Anything that is in the reactive chain starting with a link assignment or a state change in an attribute anywhere in the reactive graph, plus anything that is connected to causal dynamics. But I will not know what those elements are until I start implementing them, and for each of these high order functions associated with a dynamic link, it needs to be auditable functions all the way down until we hit the platform floor.

This blog/site has some pretty aggressive aspirations.

As mentioned in other posts, it is structured in Attribute and Preference defaults updated for Tinderbox v9.6.0 because I need some features found in that environment. But Tinderbox was designed for a somewhat different purpose than mine, and was never intended to have some needed but specialized capability. I intend to supplement Tinderbox with my own application.

This application would theoretically be reusable in a more full up tool, used either in parallel or standalone.

I will be working in Python. It has been a while since I did production-level programming, but I believe I can master what I need as I need. Python has enough functional power for our use, while at the same time being a ‘mainstream’ language. That means I can pass it on, or find help more readily than if I used Haskell, or some domain specific language built on Lisp.

Probably, I will use Python 3 supposing that certain libraries are available.

I expect to strongly favor Leo as the editor. It can allow structured function/term rewriting, using an outliner paradigm. This means that I can have at least three orthogonal outlines: the ordinary Tinderbox structure (over what we can call ‘content’); the ordinary Leo structure (over what others would call ‘code’) and over a reactive typed link arrow structure that will span both outlines. Probably this third structure would be wholly mirrored in both.

I suspect that I will be using some portable environments for some of this work, and toward this end I have refurbished two Pismo machines. One runs Tiger and with the iPhone is a content generation ‘writing machine.’ I’ve blogged about it elsewhere. The other runs MintPPC which is a PPC Debian with LXDE. I’ll do the Leo - Python work there as I can, probably using Bazaar.

Some key similarities:

• Leo has true clones, allowing genuine directed graphs; Tinderbox has an intelligent alias that allows change of some attributes, dropping others.
• Leo notes can be (and typically are) code, while Tinderbox note attributes can be code.

Some differences:

• Leo has a one-window, one-arrangement UI. Tinderbox supports many windows and several views.
• Leo is scripted by (and written in) Python, and thus can be reflexively deep; Tinderbox is scripted by an integrated language that modifies attributes.
• Leo is designed for writing programs using literate techniques so narrative is applied to code; Tinderbox is designed for structured content, and uses code to support the creation and structuring of text.