James Tauber's Blog 2004/05/15
Using the Leo Outliner as a PIM
Because what little time I've had to work on "recreational programming" has been spent on Leonardo and the tree-based instant messenger, I haven't made any progress on some of my tree-based personal information manager ideas.
So I thought it would be interesting to just start using an outliner to keep track of my calendar, projects, weekly work targets, etc. So far it's working pretty well.
I'm using Leo (not to be confused with Leonardo) which is a Python/Tk-based outliner that also supports literate programming. I first heard about Leo a few years ago from Joe Orr whom I met via the now-defunct Alliance for Advanced Real Estate Transaction Technology (AARTT).
One feature Leo has which is extremely important (although by no means unique amongst outliners) is the ability to place a node under multiple parents. I'll write a separate entry soon about why I think hierachies based on only the containment relationship are an unnecessary limitation (and how hierarchies should be done).
I've got some top-level nodes for goals, interests, responsibilities and projects. I also have a top-level node for my calendar.
Using multiple parents, I can link a project under one or more goals, interests and responsibilities. An event such as a meeting can go under a specific day node in the calendar as well as under the relevant project, responsibility, etc.
I even have a node for each week's "status" - I can link tasks, meetings, etc under the status node for the week and generate a weekly status report by using Leo's export-flattened-outline-to-file feature.
Leo has a text editor pane that allows text to be associated with any node in the outline (this is where you'd write your literate programs when using Leo for that purpose). This pane is great for taking notes on tasks, meetings, etc.
There are a couple of features that would really take Leo to the next level for these sorts of things. I'm not sure if it would make sense to extend Leo or to write a Leo-like outliner sans the literate programming features.
What I'd really like is the ability to have custom views of a node, not just the text pane. The text pane could be replaced by a tabbed control and the text editor would be just one of the tabs. Other tabs could contain things like the result of applying an XSLT stylesheet to the node and its descendants. This would be great for things like my Calendar node, which doesn't really lend itself to a tree view. It would also be very useful for aggregated views where I want to see the text for a node and all its descendants in a single view.
An XSLT stylesheet generating read-only HTML would be a huge step forward. You could go even further by having custom controls on these tabs that allow manipulation of the data. Finally, you could introduce a way of expressing properties (via something like Notation-3 in the text view) and make the hierarchy derived.
by James Tauber : Created on May 15, 2004 : Last modified Feb. 8, 2005 : Categories information_management : (permalink)
Leonardo 0.3.0 Released
A new version of Leonardo, the code behind this site, is available.
Changes:
- draft facility — content can be created under drafts then moved to blog or general site
- wiki tag for including content from one wiki page within another (note that there is no cycle-checking at the moment)
If you are upgrading, you'll just need to replace the lib directory and add the three new settings (the ones beginning DRAFT) to your config file.
by James Tauber : Created on May 15, 2004 : Last modified Feb. 8, 2005 : Categories leonardo : (permalink)
XML Infoset and XML Schemas versus RDF and RDF Schemas
In my other mnot response today, I wrote the response here and just referenced it in the comments section of mnot's entry. In this case, I responded in full in the comments section and then decided afterwards to include it here as well. More evidence that comments and trackbacks are the same thing.
I wrote the following in response to mnot's Informational Properties of Infosets:
It could be my document-centric bias (like many members of the original WG, I came from a publishing and text processing background) but, for the most part, I've viewed XML as surface syntax (and by extension, XML schemas as as grammars for surface syntax and the Infoset as modelling surface syntactic information).
RDF/RDFS has always seemed to me to be a much better data modelling language. The problem I've always had with the syntax of RDF is that it is neither a fixed serialization of the data model nor a generic mapping to-and-from arbitrary XML. It is rather a middle-ground where some common XML patterns are supported but not the generic case.
I've always argued that RDF should support a mapping to any XML surface syntax. Back when I was writing PyTREX (never updated to support RELAX NG, unfortunately) I was hoping to annotate the TREX grammar (which I saw as being about surface syntax) with a mapping to RDF (which I saw as the right way to express the underlying data model of the document). This plus something like Sparta would be then be the XML data binding.
The Infoset is priceless for modelling the surface syntax. For everything else there's RDF.
by James Tauber : Created on May 15, 2004 : Last modified Feb. 8, 2005 : (permalink)
Naked Objects in Sparta
When I first discovered Naked Objects, I thought about a Python implementation that used RDF to provide the schema. What I wasn't sure about was how best to mix use of Python objects for the instances with RDF for the schema.
The answer could be mnot's sparta.
Sparta provides a simple Python-object-to-RDF binding. It uses eikeon's rdflib, which is based on the code eikeon and I wrote for Redfoot.
Sparta itself doesn't make use of the schema module in rdflib but a Naked Objects implementation could be built on top of Sparta + the schema module.
The schema module lets you do things like ask what properties are allowed on a given resource and what values those properties can take. (Actually, it doesn't appear to do the latter anymore - I'll have to ask eikeon why that dropped out of our original code). The generator-based version of the schema module is certainly a lot cleaner than the original code eikeon and I wrote three years ago. One of us should write up a side-by-side comparison of before and after.
So another little project to add to the list: a Naked-Objects-like generic UI on top of sparta, using the schema module in rdflib to control property domains and ranges. The result would be pretty close to a rich-client version of the original generic viewer in Redfoot.
by James Tauber : Created on May 15, 2004 : Last modified Feb. 8, 2005 : (permalink)