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 : Created on May 15, 2004 : Last modified Feb. 8, 2005 : (permalink)
A new version of Leonardo, the code behind this site, is available.
Changes:
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 : Created on May 15, 2004 : Last modified Feb. 8, 2005 : (permalink)
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 : Created on May 15, 2004 : Last modified Feb. 8, 2005 : (permalink)
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 : Created on May 15, 2004 : Last modified Feb. 8, 2005 : (permalink)
There are three ways in Javadoc that you can reference interface doc from implementations.
For a while I've favoured alternative A over alternative B because of the "inherited doc in Eclipse" issue. But there are still disadvantages of this approach.
I recently discovered the {@inheritdoc} tag in Javadoc: alternative C. It's attractive, but it's a tough call because even though the only issue with it is the lack of inherited doc in Eclipse, that's a pretty big issue for me.
Right-click "Open Super Implementation" allows navigation up the tree to see the superclass or interface's doc but it still doesn't help with tool tips for calls to the implementation.
Pros:
Cons:
Pros:
Cons:
Pros:
Cons:
by : Created on May 11, 2004 : Last modified Feb. 8, 2005 : (permalink)
Previously, I've talked a little about using literate programming for writing tutorials.
I just found The Haskell Road to Logic, Maths and Programming (via Lambda the Ultimate) in which they state that "the full source code of all programs is integrated in the book; in fact, each chapter can be viewed as a literate program in Haskell."
I haven't yet established if the book was actually written as a literate program or whether they are just saying it is like one. No indication, either, of how they express the evolution of the code in the source to the book.
But speculation aside and quite apart from the literate programming aspects of the book, it looks like a very nice book on foundational mathematics.
I think there is a certain flavour that programming brings to pure mathematics. The way I think of topics like abstract algebra is heavily influenced by both object-oriented and functional programming (see, for example, my observations about currying tensors.)
by : Created on May 10, 2004 : Last modified Feb. 8, 2005 : (permalink)
My Own Shopping Cart is a plugin for Eclipse that lets you browse and shop at Amazon.com. Not only a great application of Amazon.com's API but also more evidence that by 2005, there will be people that never leave Eclipse to do their work.
by : Created on May 6, 2004 : Last modified Feb. 8, 2005 : (permalink)
A quick bug-fix release for Leonardo.
Changes:
by : Created on May 6, 2004 : Last modified Feb. 8, 2005 : (permalink)
I've released a new version of Leonardo, the wiki/blog publishing system that is used to produce this site.
Changes:
by : Created on May 5, 2004 : Last modified Feb. 8, 2005 : (permalink)
For many years I've been thinking about the application of Semantic Web technology to studying (and presenting the results of the study of) the Bible. However, I never really thought about the application of Bible study (and the tools and techniques developed for it) to the Semantic Web. Then I came across this great blog entry, discussing the latter.
On the former, there is a wonderful site SemanticBible that I hope I can contribute to in some way.
I also really need to get back to my morphological analysis. I haven't thought about it for a while, but I need to come up with URIs for each lemmata and word form. I could even grandfather in Strong's numbers and G/K numbers.
by : Created on May 4, 2004 : Last modified Feb. 8, 2005 : (permalink)
Mark Pilgrim has a nice entry on his "essentials"—the software he can't do without.
I like reading posts like this. They're like a colophon for your digital life.
Someone should come up with an RDF schema for this sort of information.
Doesn't just have to be software - could include what cell phone, what portable music player, etc.
by : Created on May 1, 2004 : Last modified Feb. 8, 2005 : (permalink)