The Author:
Bekir Kemal Ataman is a lecturer at the Department of Archives and Records Management, Marmara University, Istanbul, Turkey. He also runs projects for the private sector as a consultant, as well as the only BBS on earth serving the archives and records management profession at <http://www.archimac.org>

Keywords:
archive management, archive automation, finding aids, database, FileMaker Pro, Yapi Kredi Bank Archives.

Abstract:
Archivists, records managers, and librarians need to manipulate large amounts of data every day. Many people believe that this requires specially designed, complicated and expensive software. However, depending on your setting, the specifics of what you want to do and how comfortable you feel with computers, many information processing tasks can be automated with the use of ordinary, simple and inexpensive software. In most cases, all that an information professional would need is a good word processor and a piece of decent database management software. In addition, if the amount of data to be handled is large, then a powerful computer would help to speed things up. This paper describes how this was achieved in one setting: the Archives Museum of the Yapi Kredi Bank in Turkey.

Background

The Yapi Kredi Bank, the first private bank in Turkey, has been involved in organizing plenty of cultural activities since its foundation in 1944, mainly because its founder was very much interested in the arts. As the leader in private banking, the Yapi Kredi Bank led the way in starting a tradition among Turkish banks-- and in many other sectors, too, for that matter -- to be heavily involved in organizing cultural activities.

As for its banking activities, theYapi Kredi Bank has also had a tradition of leading the way in many aspects. Its commercials, for example, have become case studies for students of Faculties of Communications because they have always led the way in the advertising sector with fresh ideas and ground-breaking methods. The bank was also the first in Turkey to automate its tasks. Unfortunately, this lead was not reflected in the way that the bank documented its own history. There were no proper archives, in the modern sense of the term. There was a records center which destroyed all documents after 10 years -- the minimum legal requirement -- unless otherwise instructed. The only material that documented the Bank’s history consisted primarily of newspaper clippings, ephemera and photographs, originating in and documenting the activities of mainly the public relations department. The only exceptions to this were the minutes of the administrative board, and the records of the bank in its first year which were kept as some sort of a souvenir.

Task

At the archives of the Yapi Kredi Bank, the main task was to arrange collected material and prepare archival finding aids for them. The material had to be handpicked from different buildings, including the headquarters, branches, several materials depots, and record storerooms. Donations from retired personnel constituted another major source. Fortunately, this task was carried out by a retired member of the public relations department who happened to have a very good memory, knew every single branch, depot and storeroom quite well and had excellent social relations with many of the staff.

As expected, there was no order nor arrangement to the documents when they were received by the Archives Museum. They came mostly at irregular intervals, sent to us as they were discovered. They consisted of all sorts of material imaginable, including artifacts like old typewriters, mechanical calculators and telephone receivers -- thus the concept “Archives Museum” rather than mere “archives”. Some of the material received by the Archives Museum had been arranged at the time of their creation, but these did not amount to more than a few folders. In most cases, especially when ephemera were concerned, they came as individual documents of all sorts, packed into large boxes. Thus, almost all material had to be handled and processed individually rather than on a file-by-file basis. The total amount of material covered around 40 meters of shelving to start, and reached about 200 meters by the end of the project.

Method

Although we knew that almost all the material originated in the public relations department, we ended up deciding to use the provenance concept in arranging and describing the material -- with a slight twist. By its nature the public relations department had to deal with and promote the activities of all other departments. As a result, the material that we acquired documented the activities of all the departments of the bank. Therefore, we decided that they had to be arranged and described not according to their origins -- since almost all came from the same source -- but according to the activity of the department with which they were associated. There was one big problem in establishing this in real life, however: there was no information about the administrative history of the bank, since none of its departments had kept those records. We were unsure how we should arrange the material; we simply did not have any criteria. It was possible that we could find something within the material itself to guide us, but that meant we would have had to go through every single item one by one. On the other hand, we had to do this anyway, because of the scattered nature of the material.

The solution that we developed was to give everything a temporary shelf number, describe and enter them all into a database, then give every different subject or activity a temporary arrangement code as we go. While doing this we hoped to get an idea about the activities and the administrative structure of the bank and thus develop a better understanding of the material and how to arrange it. While this data entry was in progress, we realized that the physical shapes of some of the material required special treatment, so we started adding more and more fields such as dimensions, meterage, time and duration to our database as we moved on. Our list consisted of a shelf number (consisting of a type, a box/folder number and an item number), activity/subject code, date, description, format, reference date and source (for clippings), names index, place names index, organizations index, buildings index, dimensions, number of copies, meterage and type (for films), time duration (for films and sound recordings), colour, language, sound quality (for films) and notes.

Once the data entry stage was over, we took a look at all the temporary codes that we had created. Having developed an idea of how to do the arrangement by this time -- and having uncovered the administrative history -- we grouped related material under single codes and worked our way from there. Because the descriptions would be entered into a computer database by this stage, we hoped that it would be a very simple process to replace the temporary codes with new and final ones. Our plan was to then sort the database according to the new codes, giving us the final physical arrangement for the material (see Figure 1). In this way, we could change the ordering of the documents and put them into our “provenance” order.

Software Selection

Right from the beginning we knew that we would need two main types of software: database management software and word processing software. We could enter everything into the database as our major source of information, then later transfer these onto the word processor to manage the page layout and print hard copies.

Choosing a word processor was easy because our only special requirement was that it should be capable of handling large files and processing large tables with ease. Microsoft Word, the most commonly used word processor, fulfilled these requirements. Choosing the database software was trickier because our first requirement was that it should be able to sort text in Turkish. Almost all office software, including some word processors, can sort in English, but Turkish has 6 additional letters in its alphabet and does not use the letters Q, X and W. The second requirement was that it should have a localized Turkish version because our staff did not speak English at all. Running a program in English would require some additional training. Third, the software should be able to handle large files, since we had about 24 fields in each record and an estimated 100,000 records. We needed something that could perform the sort, search and omit functions in a large file at high speeds. Fourth, in the final tabulated output, we would need to alter the wording of the original descriptions. For example, the reference date and reference source fields should be expressed as “clipping from (reference source) dated (reference date).” For this and similar cases, we would need to insert additional words between some of the fields to make the final finding aid more intelligible but less complicated to the user. Thus, our choice of software should be scriptable to make life easier when transferring records into the word processor. Lastly, the description field would carry quite long information in certain cases increasing the overall file size. However, the greatest problem would not be file size, but the length of the field itself.

These criteria led us to two common pieces of database management software: Access by Microsoft and FileMaker Pro by Claris. Both could fulfill almost all our requirements. However, the first one posed a particular problem because MS Access could not handle text fields larger than 255 characters. To force it to go beyond this limit, you needed to define the field as “memo”; but when you do this, you could not perform any sort, search and omit functions on those fields. We decided to either limit our descriptions to 255 characters, or go with the Claris product. On the one hand, Access had the additional advantage of being fully compatible with MS Word, making file transfers from the database to word processor very smooth. On the other hand, FileMaker Pro, had the additional advantage of being cross-platform, because it had a Macintosh version, too.

We ultimately settled with the second option, FileMaker Pro, not only because using Apple products is easier and their total cost of ownership is much lower, but because we did not like the idea of limiting ourselves to 255 characters in describing archival material.

As a result, transferring our files from FileMaker Pro to MS Word would have to be in text only format, but this did not pose a big problem because converting them into tables with MS Word is quite easy. The only problem then lies with file sizes, since MS Word seems to not handle this conversion process properly on files larger than 700KB. We solved this problem by dividing our text files into smaller sections of less than 500 KB each.

With all descriptive activity complete, we could use the hardcopy lists produced with MS Word for structured searches, and the database for all keyword searches. This means that, to find the records for a certain event or activity, one has to refer to the finding aids on paper. For searching single items, or items relating to keywords such as personal or place names, one needs to consult the database. Figure 2 shows the record structure that we defined in FileMaker Pro.

Currently the Yapi Kredi Archives Museum is closed to the public, awaiting upper management's decision regarding access policy. The only users allowed are those that are granted special permission by the management. If it is opened for public access, the database is still going to be kept closed to public search, since it will be too time consuming for our staff to train users to use the software. So far we do not expect more than a few visitors a day but if there comes a time when the burden becomes unbearable because of an excessive number of users, we may consider changing this policy.

Problems encountered

This plan worked quite smoothly. However, we were faced with a few issues. The first of these involved having to process all material on an item-by-item basis rather than file-by-file. This meant multiplying the amount of material to be described by some 200 to 250 times, since typically a file groups together about that many items. Naturally, this adversely affected the time that it took to finish the project.

Another issue involved the continuous flow of materials as our bank contact, the retired PR staff member, visited each branch, depot and storeroom. This meant that the material that we had in our hands eventually increased five-fold, from what we had started with initially. More staff had to be hired, more computers had to be purchased, and of course new budgets had to be negotiated with the upper management every time that there was another large accrual of new material.

Yet another issue came up involving the date field entry, which we had to divide into three separate fields for day, month and year because it was not possible to discover the exact date, if any date at all, for all items. Sometimes we would be able to find the month, and sometimes we would find only the year. Even some clippings did not have dates nor sources recorded. This posed a unique problem because not all database software can handle partial date data. Most times the software would just beep and send an error message asking for complete information. However, by separating the date into three fields and defining them to be of number type, we overcame all sorting problems originating from software.

At this point, another thing that we were forced to discover was the importance of defining the number fields as being of number type, and not text type. This did not seem that important at first since text fields can always handle numbers. However, after the first attempt at sorting, we discovered that text fields did not sort numbers in the way that we wanted. If defined as text, computers treat numbers as any ordinary character. The data would be sorted in ASCII order instead of numeric order. Fortunately the software that we had chosen could convert text fields into number fields without any problems for these cases.

As for our plan, we realized that not everything in this setting could be grouped under a single code. Normally there would be only one creator, so it would be much simpler to arrange the material according to its provenance. The only exception to this rule would be when there is a change in the organization structure, resulting in the transfer of a function from one department to another. This type of change has always been problematic for archivists. In our case, the problem arose not out of organizational changes, but due to the fact that some of our material, especially clippings, was related to more than one function or subject. For example, an art exhibition, a concert and a play could all be covered by the same clipping. In these cases, we had to use more than one arrangement code. Organizational changes occurred also, but did not pose a big problem for us since our method was essentially based on function (like the Australian records continuum concept) (McCarthy, 1999).

Another problem arose when there were just too many entries under a certain code. For these cases, we had to develop subheadings and codes at a later stage to break the bulk into more manageable chunks. Our initial idea was to arrange the material physically according to the “provenance” principle that we had adopted, once the computer sorting was finished. However, it did not work that way in practice. First, we would have had to duplicate items that carried duplicate codes by photocopying or using cross-reference dummies. This would mean increasing the whole lot at a considerable level. Second, the material consisted of all sorts of formats that one could imagine in an archive. The list consisted of photographs, negatives, slides, clippings, a variety of ephemera (posters, invitations, brochures, catalogues, etc.), 16 and 35 mm films, video films, a variety of sound recordings (reel tapes, cassette tapes, disks, CDs, etc.), sculptures, tiles, a variety of small artifacts, paintings, bonds, stamps, stationary material, press releases, books, magazines, accounting books and of course correspondence. Once we saw the composition of the holdings, we realized that there was no way we could bring material of the same “provenance” or subject together physically. The only viable alternative would be to group them according to their physical shapes, which we had already done. As a result, reality forced us to give preference to the Australian, rather than the continental method of archival arrangement. This meant having very good physical and intellectual control of your holdings; it does not matter where they are shelved physically (Brunton, 1987).

One final problem that I will mention is related to similar records. For example, several clippings from different newspapers about one event may repeat the same description. These had to be combined into single entries in the final hardcopy descriptive list, to make life easier for the researcher. Eventually, this was the task that took the most from our staff time, since it was labor intensive and there was no way that it could be automated.

Looking into the future

Maintenance of the system will be taken care of by two professional archivists who have been on our team almost since the beginning of this project, and who will be employed by the bank fulltime. They will be in charge of the daily activities, as well as the arrangement and description of new acquisitions.

The next step, which we have been planning for a long time now, is to put all the finding aids onto the Internet. This would have two dimensions to it. The first would be to convert all our Microsoft Word files into web pages and the second would be to transfer our main database onto the Internet for keyword searching. The first of these may seem like a simple task since MS Word has the ability to save files as HTML. However, this is not the case for Turkish documents. Because Turkish uses Latin 5 (ISO-8859-9) rather than Latin 1, and because Microsoft has not taken the necessary steps for its products to function properly with Turkish characters, MS Word does not properly convert documents in Turkish to HTML.

However, there are many alternatives in this world and some of these can be quite simple and reasonably priced. The solution in our case came from a shareware product called r2h (short for Rich Text Format to HTML). It is a simple program that converts RTF files into HTML, simply by dragging the files into it. It is very fast, very well priced, and most importantly, it is flexible enough to be adjusted to all languages that use the Roman alphabet.

Our second task, transferring the main database onto the Internet, is much simpler. We are considering purchasing the newest version of FileMaker Pro, which has built-in Internet conversion capability. Using this feature, we hope to create a means for our future readers to search the database without the aid of our staff, and better yet, to do this without having to come to the archives personally.

One nice thing is that FileMaker Pro can handle the deeper problems related to the use of Turkish characters. Because the code pages used for Turkish characters are different on each platform -- MacTurkish, Windows-1254, IBM-857 and ISO-8859-9, use of Turkish characters pose a particular problem on the Internet. New browsers can handle this situation, but entering the search criteria using such software would mean entering different characters on each platform. Some people have solved this big problem by using the calculation fields in FileMaker Pro. After receiving the search data, which can also be defined using SQL, the software checks the platform on which the browser is running, converts the query into the native code page, then sends it in to perform the search. Once the results are obtained, they are converted into HTML pages on the fly. An even nicer capability that FileMaker Pro has is the ability to add extra words when displaying the results, through its scripting capability. I presume this can easily mean the ability to add SGML codes for Encoded Archival Description or even XML in the future.

Conclusion

Computers can be a great aid in automating archival tasks. For this, you do not need expensive, special or custom made software. We have managed this in preparing the finding aids of a relatively large collection by using only a common word processor, a decent database and some creative thinking. These three things are all that you need for a low budget and working solution to most of your professional problems.

References

• Brunton, P. and Robinson, T. (1987) "Arrangement and Description", Keeping Archives. Ed. Ann Pederson et al. Australian Society of Archivists Inc, Sydney, p. 156.
• McCarthy, G. (1999) "Engineering Utility: A visionary role for encoded archival authority information in managing virtual and physical resources" (Accessed 24 February 1999.) <http://www.library.yale.edu/~rszary/Authority/gavan3.html>

Go to page: Introduction | Contact | Education | Employment | Projects | Books | Articles | Papers | Interests | MWArticles | Hobbies | Miscellaneous | Photos

In Narratus Vitae, Go to page: Introduction | Archives | Records Management | Business Management | Computers | Research | Publishing | Teaching | History | Public Relations | Medicine | Hobbies | Disaster Preparedness |