Stephen Fortune
Center for Cultural Studies

Minor Project

I’m looking into how databases affect what we consider knowledge. The process that interests me is called ‘knowledge discovery in databases’. This process works by setting pattern matching algorithms to work on a large enough database or dataset.

A lot of the earlier literature spoke of utilising the human propensity to quickly discern patterns visually in order to further augment the knowledge discovery process. A great deal of data visualisation concerns itself only with visual stimuli, and further a lot of database based art projects rely on a visual front end. Thus I wish to explore different ways to explore the database. A more detailed consideration of why I deem this important follows the proposal outlined below;

Historically speaking our pattern matching ability was integral to our evolution. Our visual system is highly developed at noticing pattern and absence, and thus aided immensely in our navigation of our environment.

Today we are surrounded by another environment to navigate, that of data. In order to make sense of the spectrum that is populated by the data we both create and unintentionally exude we utilize a new tool: the relational database. The arrival of new realm in which patterns may (and in some enterprises must) be discerned does not necessitate the perpetuation of ocularcentric artistic interpretations and yet that has proven to be the case. My project will explore other sensory means of experiencing the patterns which determine the knowledge mined from databases.

My project will be driven by multiple speculative, and exhaustive, investigations. In doing so I hope to ascertain whether the data spectrum as navigated by relational databases can be apprehended in new (yet bodily familiar) manners, and if it cannot I hope to illuminate just how foreign and alien this new means of ordering our lives and conduct is to our lived experience to date.

The deeper considerations of my project come from viewing databases from a sort of extended cognition perspective. This is a double consideration borne of databases increasing ubiquity and also a trend I discerned in some keynotes delivered by data mining experts and which was also present in Conrad Wolframs address to Transmediale 10. This trend centres around the increasing importance of asking the right question. This I found to be a little at odds with my conception of relational databases. The Relational Database was conceived, in order that future users of large data banks “be protected from having to know how the data is organised in the machine” (Edgar F Codds own words). I am therefore interested in exploring this conflict between needing to learn how to ask better questions, and the layer (or process) of questioning (or querying) is being ever more elided from the user experience

Practical Outline of Project

My minor project intends to explore databases, and the tools used to traverse them, SQL and KDD algorithms. This will be done in a multi sensory manner that does not privilege vision at the expense of the other senses; moreover it seeks to explore what pattern discerning skills we possess that are elided or passed over in our ocularcentric culture.

I hope to achieve this by an interactive interface. The dataset that the user is to operate upon will be mapped to some form of sound. As I envision it now it will be as raw a mapping as possible in order to abstract away from the actual data as little as possible.

Upon approaching the interface the user will hear a cacophonous noise emitting from a set of speakers. This noise will be the some total of all the columns of all the tables in the database ‘playing’ at once.

The user will be presented with interfaces, approximately two per table in the database. The first interface will be a literal representation of the table, something akin to a music pre amp (or similar), with one headphone slot per column of the table it represents.

Table Interface

This simple interface should be able to fulfil basic SQL commands directed at a single table, for example to

SELECT column1, column 2, FROM table1

one would plug headphone jacks into the first and second slot in the above interface.

This would have an effect on the sound being played through the speakers. Instead of the whole dataset being played, now only the selected columns will play.

The aim of the project is to explore how many SQL operations can be translated into actions mediated by audio interfaces. The hope is to be able to link tables in the manner so important to relational databases purposes.

I also envision a second interface per table, one that will enable commands like WHERE, AND/OR and JOINS to be used (example below).


Operator Interface:

Though I have only realised this now, this project is in unconsciously indebted to John Searles Chinese Room thought experiment. In my installation the user will interact with the database by poking around with the interfaces, plugging jacks in and out, connecting interfaces to one another and twiddling knobs and pressing buttons, all with the aim of eliciting changes in the sound output. The hope is that the user will happen across a change in the noise that he or she likes, i.e. that they think there is something rhythmic or pattern to the noise. However what they discern as interesting may in fact correspond to a very mundane SQL query, which reveals little new about the dataset.

Thus in a way the user is positioned as a knowledge discovery algorithm within the database. They know not what the data in each column is, they can only seek out something interesting via their ears. In a similar way, knowledge discovery algorithms operate upon a database by proceeding via parameters of interestingness (instead of explicitly knowing what it is they seek, hence how knowledge discovery algorithms [KDD] generate new – or hidden – knowledge).

For the purposes of my minor project investigation I have decided to focus on building interfaces to relate two tables to one another. The aim is to build something small that is scaleable (just like SQL databases in real life).

I have decided that I will make my own custom built database full of data specified by me, that way I can focus on the functionality of the interfaces. At present I see the database perhaps only containing numerical data in the rows rather than strings or characters as numerical only data allows for more use of the interfaces allowed in the operator interface(above).

There are some issues with the exact execution of how the interface will operate, but at the moment I have the following flow chart in mind for the computation.


Computational flow chart

I envision Perl DBI will be an absolute necessity, and I am also aware that the above chart will sadly mean that the user will not be absolutely free to affect any change merely be plugging in jacks as they see fit. The user interface will have to be constructed in such a way that all possible actions map to some form of SQL query or another. There will also be an issue of when the sound changes, as random manual interaction with the interface will likely not proceed in the ordered fashion that SQL syntax is expected (from computers POV).

I see the focus of the minor project being dedicated to getting the interface to work as a scaleable SQL surrogate, and as such the actual data being manipulated and its resultant output are of secondary importance. However it would be my hope that I could find a way to map the sound in such a way as to appeal to the pattern noticing sensitivities in the human ear. My conversations with some friends in the ‘music, mind and brain’ MSc lead me to believe there may be scope for collaboration there. Moreover I hope to make this project work with many tables and I do hope to let this interface operate upon a meaningful real world set of data.