Description

Middleware Database Adapter is a part of the Culture 2000 project OASIS Archive (Open Archiving System with Internet Sharing) focused on preserving and presenting the European Electronic Arts. The purpose of the OASIS Archive is to make a possibility of an international co-operation and pan-European web-based exchange within the field of electronic media art. Platform generated for such a purpose should to have an open infrastructure available to interconnect the various content-rich repositories and giving the location independent presentation of media-based artefacts (video, audio or image). It should to make the ability to transmit these artefacts to any other data carriers and locations by means of web technology. Important works of the European Electronic Arts should be accessible in that way to the public at large – to the individual users and to researchers or curators planning on historical studies or exhibitions.
To achieve this goal, various databases of all participating institutions (with different structures, driven by different engines) are to be interlinked through a distributed metadata system. This part of the OASIS Archive system architecture which is responsible for interlinking databases is called the DB-Adapter. Design and implementation of the DB-Adapter is enclosed in OASIS Archive Workpackage 04.
The main task of DB-Adapter is management of the data flow (queries and answers). Simple input data (in common, unified language) from the front-end interface (GUI) are transferred through the middleware layer to the DB-Adapter where are combined and converted to form formal SQL statements. Statements are formed in consideration of diversity of the databases (different engines, structures, names of tables and fields, etc.). Queries are sent to the appropriate servers on to retrieve selected data. Retrieved data are then transformed again into common, unified form and finally moved to the GUI interface.
At the present stage of the system architecture design, DB-Adapter interlinking databases of three participating institutions:

1. Center for Art and Media in Karlsruhe (Server: ZKM),
2. Netherlands Media Art Institute in Amsterdam (Server: Montevideo),
3. International Centre for Art and New Technology in Prague (Server: AMANT).

Architecture of the DB-Adapter

The main module of each DB-Adapter is the Query Manager.
Query Manager control the data flow between DB-Adapter and databases. Query Manager receives queries in common, unified language from the middleware and process them to form a formal SQL statement. Final SQL statements are generated in special parser module and executed by DB-connector unit. Query Manager is also responsible for creating the Daily Cache – a temporary repository which holds all the data from the database in Metadata like format.
Queries transmitted to the Query Manager has a Google like format, as for instance http://foo.bar/run_query.php?query=Woody+Vasulka. Methods of the parser module cause, that each query, like "Woody Vasulka" is threated as query for Woody AND Vasulka. The plus ("+") sign is substituted with spaces and query is case insensitive. Searching is performed within all fields unless there is specified a query modifier, as for example ”author:Vasulka”. In such case, WHERE clause with “author”as the field which should to be searched, is attached. The other NOT modifier is implemented as the preceeding minus ("-") sign. It is also planned to implement OR modifier. DB-connector negotiate and open connection with corresponding server with use of appropriate driver.

Caching

Daily Cache

Daily Cache is generated once a day by using a special query of config file of each DBAdapter.
Structure of Daily Cache is the same as the metadata set depicted in Fig. 2.

Inputs

Metadata are the description which is unified for all of interlinked various databases.

Processing

The DB-Adapter's cache module (written using PHP scripting technology) "translates" daily a local partner's DB into a table containing daily cache being compliant with OASIS Archive Metadata Set.

Outputs

The result is stored the daily_cache table. At the end of translation process (caching) the translation script checks if the Content-based indexing extension has been installed (by availability of its directory), and if yes, it executes the indexing script as:

~/index/index.pl dbname

Where dbname is the name of the database where the daily_cache table can be found. Please refer to Content-based_indexing_extension#Inputs for more details.

Searching

Inputs

The input data is transmitted to the DB-Adapter using GET method. It is described in detail in the article: Communication. Most of information about inputting and outputting data is already descibed more in detail in the article: Communication.

Processing

The Generic DB-Adapter searches for the keywords in a local daily cache. Metadata is extracted from the local cache. In the first step only a list of origin_ids (matching given keywords by normal SQL LIKE) is extracted. The list is complemented with weights, being number of occurances of keywords in each row. The temporary SQL table is constructed of rows selected from the local cache. Optionally the generic DB-Adapter it can cooperate with Content-based indexing extension in order to search for content-based keywords stored in IndexingDatabase. Please refer to article Content-based indexing extension for information on lanuching the searching process for content-based keywords. In such a case the result is complemented with results from the IndexingDatabase. Weights from both sources sum producing the weight column in the temporary table.

Outputs

The Generic DB-Adapter returns the name for the temporary SQL table as a HTTP result (in order to inform the Middleware). The previously generated temporary table can be accessed directly by the Middleware. It is described in detail in article: Communication. Please note that the Middleware is obligated to DROP the temporary table just after it is no longer required. Most of information about inputting and outputting data is already descibed more in detail in the article: Communication.

Requirements

Each DB-Adapter require its own UNIX account at the partner's server. The recommended account name is dbapartner, where partner is the name for the given partner. The server providing an account for a Generic DB-Adapter should have installed regular Linux packages, including:

1. PostgreSQL 8.1 - the highly scalable, SQL compliant, open source object-relational database management system
2. Apache - Web server
3. PHP 5.0 - scripting language
4. ADOdb - library for PHP

Location

The files for a DB-Adapter should be placed in ~/public_html/dba

Installation