Overview of the system architecture
DB-Adapter - Principle of Operation
SQL statements generated by DB-Adapters queries the Daily Cache table.
Building of the Daily Cache table is realised by the Cron demon [18] and consists of three stages:
- gathering metadata,
- grouping metadata according to objects they describe,
- building the final shape of the Daily Cache table.
Metadata describe electronic art objects – artworks, provided by participating institutions. Each artwork (pictures, videos, etc.) has its unique identifier - origin_id. Artworks can have however multiple representations (multiple language versions for instance), called manifestations. Each manifestation is described by also unique oml_id. Metadata gathered during the first stage, stored in the temporary tables of the DBA-database, are then grouped according to the origin_id and oml_id fields separately. The third stage consists in generating the Daily Cache table as concatenation of the temporary tables. Temporary tables simplify accelerate and minimise failure of the Daily Cache building process. They give possibility to process metadata on the DB-Adapter side. Connection to the database server of partner is held only during the first stage.
Process of the Daily Cache generation is illustrated in the figure below.
Generation of the Daily Cache
Process of the Daily Cache generation can be supported by additional algorithms specified in the DB-Adapter config file. If sequence of Daily Cache generation is like it was indicated above (by createCacheTable() method for instance), then each stage can be realised by the separated task.
DB-Adapter – query processing
Searching for the electronic arts is supported by Content Based Indexing Extension module, which is designated to collect the additional information describing the database objects. The additional information is gathered using complex indexing techniques for electronic documents.
Interface between Middleware and DB-Adapter
The interface between Middleware and DB-Adapter consists of several PHP scripts. All scripts are places in the same path - the URL of DB-Adapter. Middleare stores this URL in it's database as "base_url" for each DB-Adapter. The scripts are listed below.
Please find also in the Appendix on DBA the following scripts:
| SCRIPT: query.php
SCRIPT: auth.php
SCRIPT: getids.php
SCRIPT: cleanup.php
SCRIPT: load.php (substituted by detail.php)
SCRIPT: detail.php (after Marseille)
SCRIPT: multiload.php
SCRIPT: player.php
SCRIPT: institution.php
SCRIPT: logo.php
|
Description of issues of digital presentation (streaming etc.)
Digital presentation of the media is assured by the interface between the Middleware and the DB-Adapters. Each DB-Adapter uses unified rules of communication. The interface allows for data generating, loading and streaming to the Middleware. Middleware is responsible for the final data preparation and presentation, performed be the Frontend.
Remaining details on issues of digital presentations, have been already deeply investigated in the chapter: “How has the content been made available (referring to DB-adapters, modified DBs, middleware, automatic indexing)?”.
Quelle: Mikolaj, Referenzen korrekt einfügen
| 
