Books/chapters and directories/files - dichotomies considered harmful

If the physical constraints are not allowed to dictate the boundaries for chapters, then we can end up resorting to file naming conventions to split the content into manageable chunks e.g. chapter1_a, chapter1_b and so on. We might then decide to keep things clean by introducing a subdirectory for each chapter, putting the sub-chapters tidily away in their own little compartments.

All is well with the world. Or is it? This is where things get interesting from an information management perspective. A full unit of work - a book - has now been split into bits that are navigable through a directory structure and bits that are navigable through an application. The result? You can use off-the-shelf tools to navigate your way through the directories. You can see the overall structure of the book by simply looking at the directory structure as a hierarchy. You can see that chapter 1 has a number of sub-chapters. However, that is as far as you can go. To dig any further into the structure of chapter 1, section A, you need to launch the editing application.

What a pity.

Why is it, that we have this hard and fast dichotomy between directory structure and file structure? Why is it that file system exploring utilities need to stop in their tracks when they hit things called 'files'?

As you have probably noticed, this artificial split can be breached in certain circumstances, at least to some extent. Graphics file formats are a good example. Many file system exploring tools know about, say, JPEG files and can display thumbnails of their contents.

That is a start in the right direction but I think it needs to go a lot further if the artificial directory/file distinction is to be eradicated.

Let us go back to the book example. Let us use Microsoft's OLE technology as an analogy. With OLE you can embed one thing in another. So for example, you can embed an Excel spreadsheet into a Word document file. Now, in your head, take that further. Imagine a world in which the file system explorer is the top level application. It manages a single, humungous file on the disk into which you embed documents, spreadsheets, databases etc. Each think you embed into the explorer can itself embed other things to any depth required.

In such a world, directories/files have merged into one abstraction. The book author does not have to introduce artificial segmentation of the book into separate entities. In such a world, filenames become something of an oddity. What do you need filenames for? You would only really need a filename at the point where you decided to exchange information between systems A and B.

Moreover, once the package of data is pasted into System B's file system explorer at some suitable point, the filename would be thrown away.

Sounds interesting wouldn't you say? So why don't we have systems that work like that? There are, as ever, many reasons. One reason which was an issue some years ago, is ceasing to be an issue very quickly now. Obviously, in order to show the structure of a "file" a file system explorer needs to look inside the file format. If the file format is proprietary, then we can do nothing.

Enter XML-based file formats like the OASIS Open Document Format[1]. The day is coming when file system explorers will be able to do for office documents, what they currently do for JPEGs. That is a start in the right direction. Eventually, I hope we will see the directory/file distinction begin to melt away.

Technologies/applications that never quite made it to the mainstream such as OpenDoc[2] and FrameMaker[3] with its powerful Book/Chapter model, may yet have a second coming.