Since around 1997, I've been interested in using the Internet to further my genealogical research. It started with browsing index sites like Cyndi's List, and the USGenWeb Project, and subscribing to surname mailing lists at RootsWeb.

With time I learned how to make web pages, and put together my own little genealogy website (link courtesy of the Wayback machine)featuring my own ancestors. I found tools that would take a GEDCOM file and turn it into a set of linked html pages that a website visitor could use to trace the lines in the GEDCOM. I learned about CGI, and was delighted to find a set of cgis that would let me just upload a single GEDCOM, and they would dynamically generate web pages based on the contents of the GEDCOM. Such tools have become very good as dynamic web technologies have flourished. One prime example of this is phpGedView.

But as my research skills have become better, I have found these utilities to be somewhat inadequate, and for that matter, GEDCOM itself. And so recently, as my web development skills have grown, I have moved down the path of designing my own utility which stores the genealogical data in a Postgresql database. Other such projects are underway as well.

In pondering the various design questions I'm facing in my own project, I've thought about various ways in which I can make my genealogy website much more interactive. An email address of the site maintainer is about as interactive as most genealogy websites (mine included at this point) get. Mailing lists such as those at RootsWeb take things a step further in terms of community and interactivity, but there's still something missing there.

As of the last few months I've been seeing more and more the power of blogging, news feeds, and wiki-style sites. I've been reading Dan Gilmore's We The Media in which he discusses at length the rise of grassroots journalism via the tools of blogging, rss, wikis, and SMS. As I read this and other sites about these emerging technologies, my mind is at work evaluating various combinations of technologies for anything that produces a "Wow, that would be cool if..." type of idea.

And so as web-based genealogy has been on my mind a lot lately, I have been crossing that concept with the ideas of RSS news feeds and wikis, and I think I have come up with some "Wow, that would be cool if" sort of ideas. And that,ultimately, is the main point of this post, to toss into the Meme Pool a few ideas, that I hope will catch some attention, and hopefully, with a little time, some implementation.

First is the idea of combining RSS and web-based genealogy. Think if, say, RootsWeb added an RSS feed to each of its WorldConnect databases. I could then be alerted via my newsreader of whenever any databases of interest were updated. Take that idea one step further, and think of the potential value if I could be alerted via customizable RSS feeds of when info on any individual of interest was updated in any of those databases of interest. Are you listening, MyFamily.com? Speaking of MyFamily, and more specifically, ancestry.com, one thing I kind of like about Ancestry.com is these occasional emails I get from them telling me that they have some new database or document collection in which they have information on the names I am interested in. Now suppose they allowed me to customize an RSS feed that provided the same information. I think I'd like that.

For my own project I plan to eventually allow customizable RSS feeds for any given individual in my database. Thus when I post a new image, or a new source document, or anything about great-grandpa Ephraim Hanks, anybody who has subscribed to the corresponding feed will find out about that addition in their news-reader. This is where I think (at least the near-term) future of online genealogy ought to be headed. Sadly, googling for 'genealogy rss' yields practically nothing in this arena. I think this is perhaps a symptom of many people's dependence on GEDCOM-based tools. GEDCOM served its purpose well, back in the days of 3 1/2-inch floppy disks, but times have changed. Web-based genealogy tools to date are mostly clumsy as far as allowing dynamic updates to online data. Usually, it's a matter of updating your local GEDCOM with PAF, or Family Tree Maker or whatever other piece of software you use, and then uploading a new GEDCOM and re-indexing. Web-based genealogy software needs to be much more dynamic than that, and much more interactive.

How interactive? Lets consider the idea of combining web-based genealogy with Wikis. The success of a mega-wiki like the WikiPedia shows the power of online communities. And ultimately isn't genealogy all about communities and families of individuals?

One feature I'd like to be able to add to my web-based genealogy database system is a wiki area associated with each individual in the database. This way any visitor to my site who has further information about the individual in question can simply add it right there. Add the ability to upload related images and documents and have them immediately (or at least after editorial review) available as part of the page about that individual, and you have something remarkable. Of course since RSS feeds for each individual, or for the entire database itself would be available, myself, and anybody else who is interested can be quickly notified of any changes that have been made. The old way of people sending me material via email, and then having to wait until I have time to add it to the site becomes a thing of the past.

I can only begin to imagine the power of such online genealogical communities. I can see groups of interested people, indeed, families, in every sense of the word, congregating around online trees of shared ancestral data, collaborating, and ultimately creating something more than any one of them could have done with the existing tools of today. Googling for 'genealogy wiki' provides a few promising results, but there's a lot more that needs to be done, yet.

So as I'm building the rpm, it gets to the 'make test' stage of the module build, and spits this out:

Some of the tests require access to an existing RAC card.
I promise not to power_off() your server.
Do you want me to run the live tests ?  [n]

I can see Google playing that role, but I believe there is a vast bridge of complexity that needs to be crossed before we get to the rosy (and potentially disturbing) picture painted by the article. From what I read, heirarchical databases were sacked decades ago in favor of the relational model, principally because heirarchical databases were based on graph theory, which proved too complex a beast to manage. XML and its ilk (including RDF) are also based on the elements of graph theory.

Um, ok... I'm not sure what's Clinton's autobio has to do with future database systems...but if you say so. Ah well, I'll click "No" on the "Was this a useful post" question offered for the entry.

find . -mtime +N -exec rm {} ;

Or something like that. The problem with that is that if, for some reason you fail to make a backup for some number of days, you eventually lose all your backups. So I found Dir::Purge on CPAN which does things a little smarter. It lets you specify how many files you want to keep around, and it's smart enough to keep the N newest (or oldest) files around. Nice. Makes my job easier, and it's code I don't have to maintain. Even better.

So my co-worker also offers a similar 1-liner solution by using a combination of ls -latr, and head or tail. Yeah, that'd probably work too :-).

Monitoring the creation of the new temporary segments/extents was something I thought of initially, but I'd like to see how accurate v$session_longops is.

I keep pretty good track of my purchases using GnuCash, and the model I use there is that each expenditure 'category' (as you'd call it in Quicken) gets its own account. When I spend money, on say, dining out, I make an entry indicating that money was transfered from my checking account to the dining out expense account. When I want to make reports, I can tell in which areas I have been spending money. But what if I were to shift that model slightly, such that instead of tracking spending by category, to track spending by merchant. So instead of indicating a transfer from checking to dining out, I were to indicate a transfer from checking to the Carlos Backstreet Grill account. Yes, yes, I know I already can sort of do that, by looking at the memo field of the transaction.

So what if we take this one step further, and I went really crazy, and for each receipt I receive, I make a gargantuan split, and divvy up the funds involved into an account for each product? For dining out, we'd still have to just keep the restaurant account, but at Walmart, I could track the 2-liter of Sprite account, etc. Hmmm, for one-time purchases (a particular Lego set for my boy, say) that could get pretty ugly. There'd be a lot of those, with only one transaction. More useful for those products that we buy time and again, like diapers :-). Or maybe not so useful.

So in a dream world, I get a receipt, scan the handy barcode provided on it with my trusty barcode reader hooked up to my computer. Software on my computer links up to the merchant's Web Service, and provides GnuCash with a nice itemized transaction to manage all of this for me. Major privacy issues there? You bet.

In a sense, I guess what I could be looking at here are different 'views' (to borrow a term from the relational model), that could be applied to the set of transactions in my ledgers. In one view I want to see in which expense 'categories' I have been spending my money', in another, I want to see to which merchants I have been giving my business, and in yet a third view, I want to see the set of products for which I am spending money.

Just some thoughts.

Users coming to sqlplus from something like MySQL's CLI may complain about SQL*Plus's apparent clunkiness. From what I have found, though, SQL*Plus is very powerful if you know how to use it. But I will agree, the lack of a command history, and command-editing (aka readline support), is painful. uniread addresses this beautifully. It gives me exactly what I'm used to with SQL*Plus, but augments that with readline support. I'm in heaven. Sure, there's no tab-completion, but that's secondary, in my opinion.