Oh crap, I just invented Prolog

Following a link trail that started with a discussion of CouchDB, I just found this old comment posted by Bill de hÓra:

Perhaps we can go top down - write smart analysers to dynamically denorm data based on usage patterns; indeed database optimisation is an industry sector. But another, dumber, option is bottom up - avoid the initial structural 'typing' step and normalise where necessary....Normalisation can be done later on, based on demand.

I don't even want to design database schemas. To hell with modeling. I just want a system that takes a great, undifferentiated pile of facts, and infers entities based on the statistics, primarily of the content, but also on the access patterns. Actually I don't even care that it infer entities; that's an implementation detail I don't need to know about. It would just optimize for query time, or insert time, or some combination; inferring some table structure will probably help it do that.

Why do I need to tell the computer the relations in my data? All I should have to do is insert facts, as triples. When I ask it a question, I want those facts returned (or maybe other conclusions).

Is a really tweaked Prolog the ultimate DBMS?

Using Atom to manage lists of Atom feeds

As Phil Wilson does, I have come to rely on Planet Intertwingly as a substitute, largely, for maintaining my own list of interesting feeds. But now Phil wants to filter Sam's picks; he wants to select favorites from the PI OPML.

That raises the interesting prospect that we now need Atom feeds for OPML updates. When Sam adds a new feed, I would want to check it out. Since OPML content is, by definition, a list, I guess Sam could mark up the feed with Simple List Extensions. I'm temporarily suspending my suspicion of SLE, because PI's growing and shrinking list of feeds is clearly unlike an ordinary, infinitely growing feed.

Using Atom to manage lists of Atom feeds demonstrates that Atom captures a powerful abstraction.