Friday, December 22, 2006

Journey with a camera

Two things have happened recently: I just returned from a trip from Portland and Seattle, and I've discovered flickr. Naturally, I took many many photos on the trip. Only a few of them have actually been uploaded.

It really is amazing how photography has changed. I'm a casual photographer. With film, I would have taken the photographs, and that would have been it. They would have been as my camera had taken them, as the film lab had returned them. The colors would be bad, the photos crooked, and I would never even have realized I've taken a bad photograph.

Enter the digital age. On flickr I can see many, many examples of composition. I can see how mistakes can be turned into something wonderful. I have an instant museum at my fingertips. (OK, so the photographs aren't all that good, but even the worst photographers seem to take good shots every once in awhile.) After I take a photograph with my digital camera, I don't have to fiddle with any chemicals to correct it. I have a piece of software, which cost $70 and never a penny more, that makes most common corrections I would care to make. No chemicals required. Sure, I could do better with Photoshop, which costs ten times as much, but it isn't necessary to what I want to do: turn a slightly bad photograph into a decent one. And even Photoshop is a fixed cost. Unless you choose to get upgrades.

I don't think I've appreciated until now just how powerful a social network can be, even one with which you aren't really communicating. Now I'm wondering if I should look into switching over from Picasa to flickr.

Wednesday, December 20, 2006

The formalness of semantic representations

The more I think about it, the more obvious it becomes that wikis have been successful precisely because they appear to be simple to write. Eventually when the wiki becomes large enough, the guidelines become sufficiently tedious that anything you write won't be acceptable on the first pass. The appearance of simplicity remains though, because the mechanics of the process are straightforward. That's what I see in wikipedia.

Now, if we apply this principle to semantic wikis, it is essential that they retain the appearance of simplicity, even if they become complex beasts. It is far easier for complexity to appear when authoring semantics, because of the number and nature of links that appear between concepts. It will take a correspondingly longer time for hand-authored semantic content to become coherent, consistent and complete. However, making it simple to author semantic content, even incoherent semantic content, is essential if the wiki is going to retain its contributors.

Tuesday, December 19, 2006

Semantic wikis and reason

Here we are back at the eternal question about semantic wikis: what good are semantic wikis? So far, the only real use of semantic wikis is in semantic media wiki, where semantics are being used for simple search and retrieval. Organization, not inference. And I want to do inference.

Let's start with a somewhat simple description of inference. You apply resolution or some other theorem proving technique to a knowledge base, and thus determine whether the fact is true given the knowledge in the KB. The KB must be consistent for this to work in the simplest case. Then there is the question of whether we can accomplish this tractably. The right knowledge in the KB must be brought to bear while answering the question. So, given a high quality knowledge base, we can produce precise answers to questions using a generally mechanical mathematical procedure.

I don't think reality is so kind to us. Building a knowledge base is a difficult endeavor. Wikis are a convenient way of collaboratively authoring texts, even high quality texts as some of the content on wikipedia may demonstrate. However, authoring knowledge using wiki principles seems to be much harder. I cannot see how we might produce a high quality knowledge base, as would be required for applying reasoning and inference procedures.

There are basically two kinds of KB quality issues I worry about: inconsistency and incompleteness. Inconsistency is when you can prove a contradiction in your KB. Incompleteness is when you cannot make the unique names assumption, that is, when there can exist multiple names in a KB for the same underlying concepts. In the case of a wiki, this would mean having multiple URIs, multiple documents, for the same concept.

I'm still reading up on this. I need to do a mini-project to see just how much of a problem inconsistency and incompleteness prove to be. Inconsistency has been tackled in the past, it is a problem that's always been present in AI systems. Incompleteness has always been present too, but the semantic web I think makes it much more prevalent. I obviously can't get any clarity on this issue without running some experiments.

Monday, December 11, 2006

Computer playing game as screensaver

This is great, having the computer play Angband for a screensaver! And it runs on Windows! Guess what I'm just about to download... I'm excited, and I've never even played or appreciated Angband-like games in my life.

Sunday, December 10, 2006

Using hunchentoot, clsql

I'm starting on a project to build an app server that manages persistence and generation on top of an existing HTTP server. There are of course many other things one would like in an app server, such as session management, but I'll let that be for now. I just want to get the data flow working at present.

For the web server I've chosen Hunchentoot, though I have yet to use it any substantial way. I might change my mind yet. clsql + postgres are going to give me my back-end. Using clsql should give me substantial database independence, though. The intermediate data structures I plan to define as CLOS objects that can be translated to the database, XML, from requests, etc. This role will be partially filled by my own HAXL, which is still in its infancy.

No telling if this is going to work. Either way, I'm certain to learn a lot.

Friday, December 8, 2006

HAXL defined

I have just finished defining a project HAXL to manipulate XML documents. I've written a couple of items already about manipulating XML, and the use of XPath. HAXL gathers that code. Over time I'll also implement data interchange between XML and CLOS. I don't yet know the form that will take, though I do have some ideas.

Tuesday, December 5, 2006

Reddit switches to python

Yes, I know, old news, Reddit switched to python an year ago, and there's even a whole c.l.l. thread on the topic. But I haven't read much about it, and find that I'm writing stuff that essentially adds no value: implementing a poor wiki when I could have an open source one that has been battle tested. There is functionality I need that the current crop of wikis don't provide so well, so there is genuinely a need for adding functionality. But that doesn't mean I should be writing a wiki in lisp. Even if it means I get to have fun hacking up new ways of manipulating XML.

Certainly, there are many tools currently missing from the common lisp world for building applications. I want to write some of them. But to fail to develop an idea because I have spent time writing tools is irresponsible. There's only one reasonable way I can see going forward: to do both.

While trying to write my application, I approached a colleague who appreciates the power of Lisp but at the same time has a healthy skepticism for how much a single programmer might produce alone. There are things that Lisp does well, and there are things at which it is presently rather poor. We have to catch up in spheres where Lisp is relatively poor: the web application frameworks need to be richer and more powerful. And there are some things we can do that truly play on the strengths of lisp. His suggestion was to write a javascript engine in lisp for the server side. There are lots of projects that try to implement lisp in language X. How about the reverse? There is a lot of stuff being written in Javascript because of the convenience of doing so, even on the server side. Because of its dynamic nature, Lisp could make a killer javascript engine.

Monday, December 4, 2006

Finding my way around clsql

I recently decided for my project that I need to learn to use a relational database through lisp. I haven't used relational databases much. And certainly not through lisp. So I picked up PostgreSQL for windows, installed it on my laptop, and used asdf-install to fetch clsql. With only a blog post as a guide, I started down this adventure.

clsql provides are two different protocols for PostgreSQL: a socket protocol, and an FFI based protocol through the C library. I first tried the FFI based protocol. I could not get clsql_uffi.dll to load, try as I might, on ACL 8. It once magically seemed to work, but then I was thwarted in my attempts to link to pq.dll.

There is nothing in the documentation that describes the difference between the socket and FFI protocols, other than saying that one requires the dll, and the socket one does not. So I'm using the socket protocol, albeit with reservations. My previous experience with socket protocols is that they work fine in general, but tend to leave out goodies like caching. I don't know if there is a hidden gotcha with PostgreSQL, but then I'm not working on anything remotely close to a production system.

All I can say for now is, so far so good. All I want to have is a persistent data store. I might even have been able to roll my own. But I felt I needed to get my hands dirty with a database.