Imaginary Tools for Imaginary Jobs
I want to kick this off with an impractical screed for the philosophically-minded web developer.
Sometimes when I’m teaching a class to web professionals and trying to clarify the difference between database structures, CMS content types, and metadata taxonomy terms, I start to get a very funny feeling. A form of delirium really. This is because, as much as I know how helpful it is to understand and use these distinctions in one’s professional life, I’m also equally aware that the landscape of different data structures and distinct levels of information we deal with are quite mirage-like, a strange fantasy that exists only by our collective imagination. People who work with computers all day become habituated to thinking of the different types and levels of information as “different types of things.” Given the virtual nature, the relatively unbounded nature of actual data in the computer, and the intense similarity of different levels of structure in computer systems, this is a notion that is questionable at best.
We hang on to these notions of different levels (the existence of file system, database, content type, website structure, metadata, XML content structures, cookies, the structured content of web pages, etc.) because they are the landscape that matters when we are making decisions in the world of computers. However, as much as they may seem like different categories of “things,” for the most part, what is really decisive about how we experience them are, in fact, the qualities of the human interfaces that we use to access them (and, to a lesser extent, their easy accessibility to different kinds of control, and the number of transformations involved in expressing them to the end user). What happens technically behind the scenes to make these things happen, are often, for all intents and purposes, almost interchangeable.
For instance, a visible piece of content on a large website may be considered the expression of text-image-and-links (data), a content type definition designating content fields (metadata), a related template (metadata), topical categorization (we actually even CALL this “metadata” taxonomy), a draft/published state (metadata), a location in the site navigation structure (metadata), and presentation logic within the template (yet more metadata). Are you starting to sense a theme here?
All of these things we give different names to are really “metadata” which is really just “more data,” and were it not for the interfaces and rules that govern how we enter and manipulate and see that data and metadata, we would have no reason for considering them to be fundamentally different. This becomes evident in some advanced scenarios, where people start to use metadata taxonomy categorization to control what template is used in a particular context; or in very bad programming, where you can sometimes smell the ignorance because the programmer is using (obviously!) the wrong (imaginary) tool for the wrong (imaginary) job. For instance, sorting content items into topics by putting them into a hundred different little folders, and computing against their location. You say, “you can do it,” but it just isn’t “the done thing.”
The same ambiguity occurs on the level of how data is kept. For instance, a “file system” is simply a large database of binary objects. A “relational SQL database” is a further level, a giant file which is an entry in that larger database of the file system, that may have its tables (folders) and columns (file properties). When products add addition faux-file system levels (as in virtualized servers, digital asset management systems, limited FTP’d website connections, social media sites, and digital camera browsers) this interpenetration of database and file system becomes yet more vivid. Likewise it is the case when you are storing structured XML system data in a relational database, where a system of columns and rows (the database) is holding a system of named nodes (the XML) in ad hoc files. Both are really very close to the same thing behind the scenes, just data manipulated in different ways, visualized slightly differently, and (largely because of the interfaces that mediate these structures) suited for different kinds of tasks. (For instance, XML can be more easily extended, and lacks the need for redundant entries for blank areas in the data.)
Objections are easy to marshal to this line of argument, because everything about how we pragmatically interact with the various “levels” of data are meant to make them seem highly distinct. And yet, over time, the norms of that interaction change, a sea change so incremental that continuity is never broken, but you end up somewhere else, or sometimes come full circle. Paradoxically, this largely has to do with changes in the logic of related human interfaces. For instance, if a vendor produces a metadata taxonomy interface that is now smart enough to show in each node of the tree the detail of what items of content are attached, who is to say this is not the same thing as a primitive file system? And if the interfaces of databases are re-written so that they can easily show a hierarchical outline view of the data and its relationships, who is to say that (barring this or that processor bottleneck inefficiency) that this isn’t the same sort of thing as an XML file?
At the end of the day, we are energetically wrestling with ghosts, pointing at virtual objects that only exist by stipulation, objects that we think are “behind” our interfaces. In fact, our interfaces and habits of using them are far more determining of what the landscape of the virtual world is like than we want to admit. Perhaps it’s something in us that needs to project more depth than is actually there to this logical, virtual space—even if it means the absurdity of considering our folders, nodes and keywords to be fundamentally different “types of things.” Behind this curtain, there are a limited number of elemental types of structures, and given that we use them over and over again with different names (and a procession of different, yet very similar meanings), those structures must say a great deal about US.
About the Author
Leave A Reply