The Gordian Data

There’s a famous story about the eastward blitzkrieg of Alexander the Great through Asia Minor. On a narrow isthmus at the town of Gordia, on the only road to the east, there was a wagon left by the legendary Gordius, which had stood there time out of mind. The crossbar of the yoke was tied with cornel bark rather than rope, as they usually were, to the bar attached to the cart. Untypically, this knot was of mind-numbing complexity and size. Legend had it that Asia Minor would never fall to any conqueror who could not unravel this knot. As was the tradition, Alexander was led to this puzzle, which had stumped all who went before him, none of whom were successful in taking Asia Minor.

Impetuous Al took one look at the massive snarl, shrugged, and cleaved it with a blow of his sword. It seems that with oxbows as with life, the direct, unorthodox approach is often the best.

We need to cut through a lot of mystery that surrounds data management, especially as it lives on the web. Actually, the RSS standard is pointing the way to the future of most data on the web, and RSS may be the means to cut through the Gordian Data problem.

The standard for large data-driven web sites is to connect the web (html) server to a separate data server, which supplies the data to be displayed in the user’s browser and which stores the data provided by the user. Special code in the web page triggers a Common Gateway Interface (CGI) which talks to the data server and gets and puts the required information. Every time the user hits such a web page, there are two events: fetch the web page and fetch the data to be displayed on the web page. When the web form is submitted, there are another two events, tell the page you’re done and move the data to the data server.

Data for the Rest of Us

Interestingly, a web page is a database. It contains information which, when requested by an authorized user, is served to the user. It’s not elegant and it’s useless for large data sets, but it still has all the characteristics of a data base.

Until the world wide web, there never had been a public data record like a web page. The web’s breakthrough was to totally expose some set of useful data to anyone, without restriction. who had the web address. This was, I submit, a bigger deal than even we web junkies acknowledge.

My mantra is that proprietary data is the root of tyranny. If information has no use, it’s not considered data. But if it has been elevated to data status, it’s needed by somebody and protected by someone else. Whether it’s a driver’s license record, Visa account or the Most Wanted List, when you need to have the data you are subject to the demands of the party controlling the data. It is what gives governments power over their subjects and police the power to make your life a mess. It’s why it’s bad form for a government to detain its citizens without putting them on a public data list so others can see what’s going on among their peers.

The Data Problem

When you build a data base, you need a trained data guy who will use specialized software to design the data forms and connect them to the data base, which is usually a table with a header row of the data types and another row for each record (person or property or airline flight). Sounds good, but the problem is that the tools are quite specialized and each data base is custom-built for its owner. That means it’s hard for another designer to step in and modify the data base, since it’s a little like a computer program.

This means the data base owner is dependent on the designer, which he doesn’t want to be, and the designer is an indentured servant to the owner, which he doesn’t want either.

So we’ve got an ungainly data source that’s available to everyone and buildable by almost everyone’s niece – the web page. And we’ve got a cumbersome, expensive specialized tool understandable by only a few and fully understood only by the designer. Where’s the middle ground?

The data problem is really two problems: interface and data integrity. Data for the Rest of Us needs a lot of  people who know how to design a useful interface with low cost tools. That would be web design. Since all data is finding its way onto the web, we’re making the web page our default interface standard.

That leaves the back end data problem. There are thousands of people who will design you a web page, but hardly any of them can even spell “data”. Most owners of data bases want to get information from their customers, not just digitize their brochure. The best that small outfits can usually get from their designer is the ubiquitous web-to-email tool which dumps the info they want into their inbox. If you want something useful, you’ll spend more than a small outfit can, or use one of the one-size-fits-all solutions, which locks you in to a single vendor.

Find Your RSS with Both Hands

The RSS solution is elegant. It codes your info as categorized text using XML tags like <title>Jaws</title>, <director>Spielburg</director>, etc. And it puts it right on the web where anyone can see it. Since it’s just text, it can be written by many tools, and because it’s systematically tagged, machines can read the data and slice and dice it, just like a “real” data base.

The problem is that “the Rest of Us” and our web designers still need an expert to customize the RSS feed for our purpose. RSS is real progress that stops just a little short for anyone but bloggers and news syndicators.

The Gordian breakthrough is to store data right on the user’s web site using XML as the data store. Suddenly any web designer is able to design the data input form, if they have a tool to parse their preferences into PHP code.

XWriter.php

This fall, you’ll be able to download an open source script that lets a web designer add data tools to their web sites. The only skill they’ll need are these:

1. Know where the data display folder is on your web site
2. Know where the data input folder is on your web site
3. List your data types, which XWriter converts to a parseable string
4. Drag the XWriter-created data display strings or input strings to your WYSIWYG editor
5. Click on a graphic representation of the 6 form types and 2-4 options for each input
6. Click Process

That’s it. XWriter adds the needed PHP code to your web page, puts the page where directed and opens it for testing. XWriter was developed for creating and modifying Xpertweb forms but its uses are so broad it’s been enhanced for use on any PHP-equipped site.

The XWriter tool is being developed by Hurai Rody, who has done a great job working on a strange concept. We’re indebted to him.

8:24:31 PM