Changing attributes

Introduction

The goal of the DRA web application is to be a better rock art research tool. One key toward achieving this goal is the set of attributes used to describe rock art elements. The attributes must be concise and descriptive to simplify recording and enable researchers to easily search for similar elements of interest.

Defining and reaching consensus on element attributes appropriate for a computer based application like DigitalRockArt is expected to be a lot of work. An approach is to try to first resolve what is rock art (does it include cupules, groves, metates?), then determine the list of rock art classes (anthropomorphic, zoomorphic...), and then define the appropriate attribute sets (gender, arms...) and finally define the attributes for each set (arms.up, arms.down, arms.curved,...).

There are few restrictions on what attributes or attribute sets can be used to describe rock art elements or panels. The restrictions are generally esthetic in nature. Words or phrases should be short enough to fit into the screen layout, and the number of attributes in an attribute set should be about 10 or less.

It is desirable (but realistically impossible) to create a stable set of attributes before attempting to record large numbers of rock art elements. Categories, rock art classes, attribute sets, and attributes are data that is input to the DRA web application. Changing this data has an adverse effect on previously recorded rock art elements. For example, if an existing attribute Black or Gray is deleted and new attributes of Black and Gray are added, all of the elements having the former attribute must be reviewed and corrected to carry the proper new attribute.

Changing Attributes

There are several program tools and processes that make it easier to modify attributes.

When the DigitalRockArt application is started it reads the current categories, classes, attribute sets, and attributes from its database, or SQL tables.

Persons recording rock art or using the reporting functions see the current set of attributes as check box alternatives. Recorders being trained or requiring clarification may consult the DraAttributes page for the current attribute definitions.

The bottoms of these wiki pages contain an area reserved for defining future changes to attributes. It is least disruptive to make several changes to the attributes at once and to do so on a regular schedule. Doing so will help insure that proposed changes have received a consensus and recorders can rework any impacted elements on a timely schedule.

At the scheduled time, an administrator reviews all the suggested changes to ensure they are written per the format rules defined on each page. The administrator must decide which suggested changes should be implemented now, which require more review, and those which should be discarded. The standard for making a change is consensus among the recorders -- if there is none, no change is made.

Next, the administrator updates the wiki pages defining attributes. In most cases, this should be a simple matter of cutting whole attribute set definitions from the bottom discussion area of each page and pasting them into the appropriate place nearer the top. Doing so makes the documentation become out of sync with the database SQL tables so the remaining actions should be completed quickly.

A program (wiki2csv.py) is run which reads the wiki attribute definition pages and creates an intermediate file containing the revised attribute hierarchy. This is a harmless process because no SQL tables are updated and the application server need not be stopped. If there are errors because the format rules were not followed, the administrator must correct the wiki page and rerun the program.

Next, the administrator uses a DigitalRockArt application function (Preview Attribute Changes) to review the differences between the new intermediate file and the existing database SQL tables. If there are changes which are simple word substitutions (such as gray vs. grey), the SQL tables can be updated manually to save recorder time. The application server must be restarted to see the effect of these manual changes to the SQL tables. Note that if a class name is changed, the table containing the class name and the corresponding entry in the attribute table must be both updated manually.

If there are changes that will require many elements to be reviewed individually by their respective recorders (delete the attribute black or gray and add new attributes black and gray) the administrator can use another function to requeue the effected elements. If new attribute sets are added that effect a particular classification, all elements in that class can be requeued.

Finally, the administrator stops the DigitalRockArt application server, and another program (aaLoadAttributes.bat which executes ReviseAttributes.py) is run. This takes a backup of the database SQL tables and updates the database SQL tables with the values in the intermediate file. Differences between the old and new attributes are identified and obsolete attribute data is removed from the database. The DRA application server is then restarted. NOTE: Apache must be restarted because CompiledCategories is loaded.

Recorders must then review and correct each effected element using the newly modified attributes. This is less work than the original pass as unchanged attribute data remains intact.

Assuming the changes made amount to a minor tweaking of the attribute definitions, research functions continue to operate with the existing data. As the recorders complete their updates, searches and comparisons can be made using the new attributes.

If an entirely new attribute set is added, updates can be quickly made using the CheckAttributeSet function.

The process of requeuing elements and restarting the DRA application takes a few minutes. Persons with active sessions may not even notice the restart. In practice this is likely to occur during early morning or late evening hours when there are no active users.