Databases and Systems

268
The ace data definition language
Data in Acedb are organized in objects and objects are grouped in classes. Each
object belongs to a unique class, and has a name which is unique in its class. Rather
than having a fixed number of fields determined by their class, objects have a flexible
internal structure, organized hierarchically as a tree. This tree contains basic data
elements, such as numbers, character strings, and pointers to other objects, as well as
identifiers called "tags" that give structure and meaning to the tree. The database
schema consists of tree specifications, which in Acedb terminology are called class
"models". A formal BNF definition and several examples and tutorials are available
at [2]. Consider the following simple example:
?Person Paper ?Paper
Address Street Text
City ?City
State ?State
?City State ?State XREF Cities
?State Cities ?City XREF State
This schema defines models for three classes: Person, City and State, prefixed by
question marks, and six tags: Paper, Address, Street, City, State and Cities. Inside
trees, the symbols “?classname” represent pointers to objects in the specified class.
The XREF tells the system to maintain automatically the cross referencing between
State and Cities.
Note that in class Person, under the tag Address, we have three tags on equal
footing: Street, City and State. This nesting brings several benefits. First, it remains
clear when the model becomes complicated. Second, this construction provides an
automatic clustering of the contents. Any person for whom State is specified
automatically gains a partial Address and can be selected and retrieved on this
criterion allowing natural queries and automatic classification. Finally, this provides
a very simple way, explained below, of de-correlating the methods from the schema.
The tag[2] system
The greatest problem we encountered with the early versions of Acedb was a tight
coupling of the display to the schema, which has come to be known in the Acedb
community, particularly among data curators, as the "magic tag" syndrome. The
meaning is this: features presented in the applications and in the graphic interface
were obtained from the database by reference to explicit tags in the class definitions.
Consider a simple example where one wants to write a program for addressing
envelopes. The easy way is to look at the definition of class Person, to retrieve the
Street, City and State values and print them. But this piece of code turns the tags