K A B I K A D J

Database for Manuscripts in Arabic Characters

Documentation: Introduction Access Catalog > Develop
  1. Code
  2. Updates
  3. Addition of descriptors
  4. Why not XML?

  1. Code

    1. Database core

      The central idea of the Kabikadj database is to store the catalog data as JavaScript variables and upload them all into memory with the first load of the Kabikadj webpages. As for the multilingual ability, it is achieved by using for the descriptive fields only a limited terminology that is translated in both ways between English and the other interface language.

    2. Files Flowchart

      The file ../KABIKADJ/INDEX.HTM (and it's localized variants INDEX_FR.HTM, etc.) is to be used as a portal to the cataloguing project. The cataloguer can present the collection, give links to other documents he produced, and provide the link to the database. While Kabikadj was produced by myself, the cataloguer is filling the database with information - the portal is where he can show himself.

      The portal file is calling a frame set, containing the search page and the future results page. The search page is loading in memory the catalog descriptive files as JavaScript variables, as well as the search engine, the lexicons and the numbered list of description fields.

      The result page is generated by the JavaScript search engine. It contains links to html files of the catalog, stored in each manuscript folder and needed to display the description data and the reproductions.

      These files contain themselves code to generate the image stripes and the detailed views of reproductions.

      3. ˆ top

    3. Notes

      File names follow the 8.3 all caps system to ensure compatibility of CD-ROMs versions of Kabikadj on PC and Mac.

      Each interface language folder contains it's own set of files necessary for the functioning of Kabikadj. They differ in the translated content of the html files, some particularities such as right-to-left writing direction and some minor aspects of data handling by JavaScript code. Although very similar, I considered to be too cumbersome to make a single set of files that could handle all languages. The downside is that every change has to be copied in as many files as languages there are.

      Since JavaScript cannot read the content of directories, it is necessary that the catalogue files MS_DATA.JS and their total number are specified at the end of SEARCH.HTM.

      The code in TABLE.JS is giving a sequential number to each description field denoted by a variable named after that field. The same happens with the query fields in the search page and then an equivalence table is build.

    ˆ top

  2. Updates

    3. Updating Kabikadj should be simple, by replacing folders and files. Adding a new interface language means adding folders to those already existent.

    The most important aspects of updating is not to touch at the structure of the cataloguing files and the cataloguing keywords. Such modifications mean not to be able to interchange data with other users of Kabikadj and/or a lot of work to open each individual catalog file and amend it.

    ˆ top

  3. Addition of descriptors

    4. In case new descriptors are needed, they should be appended at the end of the MS_DATA.JS files to ensure backward compability.

    ˆ top

  4. Why not XML?

    5. Kabikadj can work without XML, has a wider range of compatibility relying only on HTML and JavaScript and, if needed, the migration of catalogue files to XML encoding can be easly done.

    When I started in January 2001 working on Kabikadj I needed a solution that would work immediately. At that time the XML Query language was still under construction by the W3C and so even if I had described the catalogue files in XML, I would not had been able to querry the database.

    Also there is no DTD for manuscripts in Arabic characters. The Text Encoding Initiative is working on a standard for Latin manuscripts and the Institute of Research on the History of Texts (IRHT), Paris/Orleans, on standards for text editions of Arabic language manuscripts (but less codicology and paleography). Rather than tediously invent my own DTD and then some time later have to adopt new rules, I avoided XLM.

    If however catalogue files from Kabikadj should be incorporated in other databases - running in XML, MARC, or any other format -, it is very easy to make a module that would generate HTML pages with the data structured as needed. Theses pages can then be saved as files and used by the other databases.

    So, I prefere to have a JavaScript Kabikadj that works, rather than XML Kabikadj that won't work.

    ˆ top


2001 © Vlad Atanasiu
atanasiu@excite.com
Last update: 29 November 2009