eighty-twenty

The aim of Fuschia was to write a clean, Python-based, blosxom-like blogging tool. As soon as I’d started though, I got grand plans and lost my way. Now I’ve turned back to it as a testing ground for some zowie ideas.

I branched Fuschia to try making a web site by projecting an RDF model along semantic relations. This is very zowie-ish, so I’m going to write about my experiments here.

The view

Here I ran into the dilemma of having either a single model, and constructing views using a projection and a subject (a subject-centric view); or having a graph of views and the models distributed among them (a state-centric view).

A zooming user interface may have a locus of attention (either explicitly as in an insertion point, or guessed from the input device state, like mouse position) but it may not always have an explicit subject aside from the world. Hence it’s difficult to have a subject view; however, you can on the other hand, let the state of the view decide this for you — rendering the view becomes:

1. start at the top-level view, and find the top-level subject
2. project the semantic relations (to the current subject) onto spatial relations
3. for each related subject, make an appropriate view and go to 1.
4. composite the responses according to the spatial relations

Naturally, the state of a view along with the spatial relations in the projection will mean that some related subjects are outside the clipping area, too small, &c., so these won’t be rendered.

A Web site always has an explicit subject, given by the URL. Our algorithm is very similar to the state-centric case:

1. make the current subject the one requested
2. project the semantic relations to the current subject onto Web page relations
3. for each related subject, make an appropriate view and go to 1.
4. compose the response HTML according to the Web page relations

It looks like a Web site (in this experiment) approximates the smoothly interactive interface with discrete, subject-sized steps. The state of the view is implicit in the explicit subject, rather than subjects being interpolated between by the view state.

The model

What do we want from the model? In the MVC sense, a model fulfils two roles: being a value cell, and being observable (letting the view know when the value changes). Since I don’t initially have a controller changing the model, I can not worry so much about being observable, and just hold a value. Primarily, I need to know semantic relations between subjects (resources) and objects (values). These are naturally expressed (because it suits my purpose) as a RDF triples database. My model for a particular subject is the set of relation-arcs leading outwards; for this we really only need a reference to the triples database, the subject itself, and a way to query the database.

I started by representing some facts about (say) a part of the filesystem. We have to know what form these facts are going to be for us to reason using them later, so I use a standard set of facts about containment and names of things. From this basic set of explicit relations and an inference procedure, I can infer other relations such as ancestry, transitive containment, and so on. We can also use these to project our filesystem facts into semantic relations (‘classified-as’), and our semantic relations into view-specific relations (‘linked-to’).

Style and templates

Assumed in the above algorithms is a procedure for determining the appropriate view for a subject. Here I have a number of options, including:

Have a statically configurable map of subject type to view. This is essentially a view factory, and conceptually straight-forward so far as it goes. It leaves the matter of templates alone — concievably some views would use some kind of templates, which leads to coupling between the template language and the view projection.

Use context and selector-matching to determine the view (or style) to use, in the manner of CSS or GSS stylesheets. This is really a refinement of the above; however, since we have context, we can stick to styles and simply have some styles that rule out rendering a subject. We don’t have to resort to control structures or even have templates.

Direct the view rendering through templates entirely, using selectors and control structures, in the manner of XSLT. Although this is a nice pun on XSLT, and could even be workable using XSLT, it is more or less what I’m trying to avoid. I want to extract the relations implied in such templates and keep them explicitly in one place — the projection.