Korsakow is software. It lets you make and publish multilinear video (and sound) works online. That is pretty much all you use it for and all it does.
Some questions: why do we use it? What mightbe learnt from using it? What can we make or do with it?
How to Think Korsakow
The Korsakow System is software that lets you make hypertexts. Unlike traditional hypertext the content nodes here are now video or audio, but all the principles, rules of making and reading are pretty much the same as for hypertext (or I guess more accurately hypermedia).
The simplest way I think of understanding the Korsakow System is that it is a system for making what I think of as hypertext movies. It lets you make links between nodes like you do in HTML, except the links are not written out as HREFs but use keywords. Each clip in your project These keywords can also be attached to time.
This means that you should think of a keyword as being the same as a link, so a video clip while you are making a movie can have links out to other video clips in your k-film. This means any clip can have as many links to other clips as you like (there is even a random option where it will insert any clip for you, think of this as a random link to all the other nodes/clips in your project). Similarly there are links in to each clip from other clips, and you define these as well.
Figure One: Standard Links Using HTTP and HTML (HREF attribute).
For example, as Figure One illustrates, the sorts of links commonly understood to constitute hypertext are those written in HTML, and so are anchored on a source page (for instance in text or an image) and when selected have a single destination which is to a legitimate URL. Hypertext however, has always had much more sophisticated notions of linking than this, including the assumption that you could link from the entire object (in the case of Figure One, this would be the entire page), and that any link may have a single anchor, or source, but multiple destinations.
In such a system (see Figure Two) a link may come from an entire node, or from any part within that node (and a node may contain text, image, video, and so on) and may have multiple destinations. In many traditional hypertext systems this is realised through a link with some sort of dialog or directory window opening when a multiheaded links is selected to let the reader choose which of the destinations they would like to arrive at. Alternatively, such systems may also institute rules so that the system, rather than the user, determines the destination from those available (Storyspace is an example of such a system). Such rules usually rely on state information (that is the system records what you have been doing, and so knows what nodes you have in your history, which word you just selected to follow a link, and the like) and so make links available on the basis of reading history (what you have, or have not visited) and text strings (what bit of text you have selected.
However, technicalities aside, what is of importance here is the difference this sort of hypertext has to plain vanilla HTML with HREFs. In the latter links are singluar with a nominated and visible source (the link anchor) and a single destination (a URL). This means links can be thought of (and mapped) as complex, recursive tree structures, but the connections are all fixed and visible, whether they are followed or not – this web page has n links with n1 destinations. In Figure Two though we don’t have such tree like structures (I should stress that ‘tree’ really is a misleading analogy, since a web link can link to any other URL and there is no necessary hierarchy required, which the tree analogy suggests, but I do want to provide a strong sense of the way in which these sorts of links are ‘flat’ compared to more complex hypertext structures, are easily discoverable (ie you can just see them) and so describe and create a fixed topography whether they are followed by a reader or not. This is, after all, how a spider like Google can index webpages as it follows links, it is premised on them being explicitly declared, described and able to be followed). I like to think of them as clouds, or as fuzzy links.
Figure Two: Multiheaded Links in a Hypertext.
Clouds and Fuzzy Links
These are quite informal terms, but that’s OK. They are fuzzy because in Figure Two the link that has four possible destinations does not need to be made up of four different links (as would be the case in HTML) but can be a single link which has a condition or rule attached to it where that rule is satisfied (in this example) by four destinations. This lack of specificity, where a link does not absolutely go from here to there, is what makes it fuzzy. It might go to N1, but it might also go to any of N2, N3, and N4. As a consequence of this the structure is not fixed as in HTML but is cloudy, there is a soft constellation of potential destinations, and they are potential not because it is a web page with ten links and the reader may decide on any of the ten (or none) but because the destination is actuated by the system in response to the user as a feedback system.
Now, let’s return this to Korsakow. Korsakow uses the model described in Figure Two. The link is not a link in the technical hypertext sense (though it is, after all a hypertext system such as Storyspace is, like Korsakow, a database application with a particular sort of presentation layer for authoring and reading) but a keyword which enables a search. This search will, in the simplest scenario, match all other nodes that contain this keyword and so make them available for selection – in the first instance by the system and in the second by the user. In a k-film the set of possible destinations to a key word is constrained by a) the number of nodes containing that key word, b) the number of lives each node has (which limits the number of times it can be played, which in turn limits how often it can appear as a result of a search), and c) how many thumbnails have been allocated to present the outcome of the search.
For example, in Figure Two we have four nodes that have links, so as a k-film that would be four nodes that contain the same key word that we are searching for (keeping in mind that this could include the same node that is the source of the search). However, in defining the parameters for the first node in this series it is possible to limit how many results to return for this search, so while there may be four that meet the condition only two (for example) may be displayed. Similarly the designer of the k-film is able to determine how many thumbnail panes to present in the project, and this can also affect how many nodes within this ‘cloud’ may actually appear to the user. For instance, a k-film may only have three thumbnail panes, so if there are four nodes that match the search criteria, one will not be displayed. Finally, it should be obvious that as more material is added to a k-film project the set of nodes that matches a search may change as more nodes with the same key word are included.
So, we have links that are fuzzy because they are rule defined, and what meets the conditions of these rules varies due to a variety of author defined constraints. A problem remains though, as an artefact of our visualisation, which suggests a linear passage through the material (from left to right, and implicitly from beginning to an end). This is, in fact, not the case.
Figure Three: A Sketch of the Structure of A Completed K-Film
Figure Three provides a concpetual link structure for a simple k-film. The coloured lines are different key word links between each of the nodes. The point of this third figure is to begin to suggest the complexity that can be built through only a few nodes (SNUs, lexias) and keywords, and that the structures (the sequences) are recursive, circular, and ‘ill formed’ in that they are not explicit like in HTML but lie there, as a virtual set of possibilities.