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:
- start at the top-level view, and find the top-level subject
- project the semantic relations (to the current subject) onto
spatial relations
- for each related subject, make an appropriate view and go to 1.
- 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:
- make the current subject the one requested
- project the semantic relations to the current subject onto Web page
relations
- for each related subject, make an appropriate view and go to 1.
- 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.
