NOTE: Collaborative work with CIDOC's Data Model Working Group has been conducted since the release of Version 1.1. This has resulted in substantive changes to this document (annotated in the following text) but a Version 2 has not been released. The HTML-coded Version 1.11 has been prepared for the sake of historical completeness of the World Wide Web archives that the authoring groups have established.
Statement of purpose
Sample attribute description
Rules for forming attribute names and alias designations for them
Forming attribute names and their alias designations - Appendix 1.
This document was prepared for simultaneous release to INSAM, which is a coordinating body for information systems at Swedish museums, and to CIMCIM, which is the International Council of Museums (ICOM) International Committee for Musical Instruments. The material presented here represents the efforts of separate working groups within both organizations. The Swedish version is entitled, SWETERM (the present text) and the CIMCIM version is entitled, CIMENT. They were identical at the time of their initial release but are expected to diverge during further development within their respective organizations.
The narrative portion of this document and Appendix 1 were written by Cary Karp who was involved in both working groups. The authors of any other appendices that may subsequently be included will be named in the individual headings.
All other material was prepared by the following members of the working groups:
Anne Murray, The National Museum of Ethnography, Stockholm
Christer Larsson, The Nordic Museum, Stockholm
Cary Karp, The Swedish Museum of Natural History, Stockholm
Gary Sturm, Smithsonian Institution, Washington, D.C.
Arnold Myers, University of Edinburgh Collection of Historical Musical Instruments, Edinburgh
Hélène La Rue, Pitt Rivers Museum, Oxford
Cary Karp, The Swedish Museum of Natural History, Stockholm
Acknowledgment is also made of the efforts of numerous colleagues who have followed the progress of the working groups and made invaluable contributions to them.
Much of what is presented below will be found in easily recognizable form in the technical literature pertaining to database design. Several other efforts in establishing standards for museum computerization have influenced our work and deserve acknowledgement. Most notable among these are the recommendations published by the Swedish SAMOREG Committee, the data dictionaries prepared by the Canadian Heritage Information Network, and documents currently being developed within CIDOC.
It should be noted that the recommendations made below are subject to modification both in light of CIDOC's continuing normative efforts, and as a result of user response to the initial version of this document. It cannot be overemphasized that the material presented here does not in any way pretend to be a standard and must not be regarded as one. Further development of this document is, however, dependent on those who have read it and tested it reporting their experiences and criticism to the working groups.
SWETERM is intended to serve as a support document in the creation and use of databases for the registration of collections of museum objects. It is designed to be equally applicable both in conjunction with pre-existing systems and in the establishment of new systems. Therefore, no proposals are made which require adherence to a prescribed data model or necessitate specific systems capabilities with two exceptions, the first of which is mentioned elsewhere on this page, and the second under the heading "Rules for forming attribute names and alias designations for them".
SWETERM is directed towards a readership with prior familiarity with the basic concepts of database design. Additional tutorial material necessary to render SWETERM fully comprehendible to the neophyte reader will either be provided in appendices or under separate cover.
It is assumed that the initial testing of the material provided here will be in its application to systems which are already in use. Depending on the success with which this is accomplished, the prescriptive scope of SWETERM may be expanded to encompass a more elaborate standardized nomenclature and a formalized data model.
The current primary intent of SWETERM is to propose a means for the standardization of two aspects of database systems. First, it describes a procedure for the documentation of attributes. (Attributes are the individual concepts used in describing an object, such as its accession number and its name.) Second, it provides rules for the formation of abbreviated aliases for attribute names. (The ability to equate an alias with the full name of an attribute is the first of the system requirements made here.)
Uniform procedures for describing attributes are regarded as desirable in that they will enable someone familiar with the documentation of one system more easily to become oriented in the documentation of any other system. The uniform descriptions will also enable the future production of a compiled and normalized term catalog for general use within the museum community, if this is determined to be desirable.
It is assumed that the casual user of a database may not require detailed knowledge of all the aspects of an attribute as it is used in a specific system. It will, however, be necessary to understand at least the names of all the attributes. Any system which accepts the alias designations described in SWETERM will render that system reasonably useful to anyone who understands the rules for alias formation provided here.
The alias designations are also intended to be included in statements expressed in formally standardized query languages such as SQL (= "Structured Query Language") and CCL (= "Common Command Language") thereby facilitating intersystems communication.
The description of an attribute should contain the information listed below.
NAME - the full name of the attribute in the primary language of the database.
TAG - the abbreviated designation for the attribute formed according to the rules presented below.
ALIASES - any additional designations which may be used to refer to the attribute when querying the database. The sources for aliases should be indicated in parentheses.
DEFINITION - an extensive definition of the attribute.
RULES FOR USE - the format and syntax which are used when assigning values to the attribute.
EXAMPLES - examples of the use of the attribute.
LANGUAGE - If a system is maintained in more than one language, all linguistic considerations pertaining to the use of an attribute are indicated here. The designation "multilingual" may be used to indicate that there is no need to differentiate between the values assigned to the attribute in the different system languages.
REQUIREMENT - The system may require values to be assigned to certain attributes. Attribute values which are not required in this manner may nonetheless be essential for the description of an entity. The extent to which a value is needed is indicated here.
VALIDATION - Restrictions may be placed on the values which can be assigned to an attribute. Any such limitations are indicated here.
LINKS - Some attributes may require the use of other attributes in order to be meaningful. All links to other attributes are listed here.
DATE OF BIRTH - the date on which the attribute description was created.
DATE OF CHANGE - the date on which the attribute description was most recently modified.
COMMENTS - additional information about the attribute.
The preceding information will be necessary for the description of all attributes and should therefore be available in the publicly accessible documentation for the system. It is also possible for a system to contain a number of attributes which should be accessible on a restricted basis only. These might include the price paid for an object, the identity of its seller, its insured value, its storage location, etc. The documentation for any restricted attributes should be maintained separately. Since this is a matter of local concern, the use of the preceding standardized attribute description format is optional. For purposes of security, the documentation of a restricted attribute should include the equivalent of the following heading:
DATE OF ACCESS - a record of all dates on which the description of an attribute was examined. If possible this should also include a record of the individuals who made these references.
NAME - Personal or corporate name
TAG - PERNAM
ALIASES - PERNAM (SWETERM); 381 (SAMOREG); 581 (SAMOREG)
DEFINITION - This field contains the names of individuals and corporate entities associated with the object.
RULES FOR USE - Names are entered in upper case, last name first, followed by a comma, single space and initials for all other names separated by spaces only. Each name is entered on a single line. A compound manufacturer's name should not be split into separate lines. In this case, list the company's name as commonly known using ampersands instead of the word "and".
EXAMPLES - DENNER, J C ; AHLBERG & OHLSSON
LANGUAGE - Multilingual
REQUIREMENT - The entry of all names marked on the object itself is essential. Names known through positive attributions should also be given. See also the comments below.
VALIDATION - Entries are restricted to values given in a biographic authority file.
ASSOCIATED FIELDS - PERNAMSPE ; PERNAMASC
DATE OF BIRTH - 19870101
DATE OF CHANGE - 19900314
COMMENTS - Since folk groups are not normally registered in this database, there is no dedicated attribute for this purpose. The name of a folk group may therefore be entered in PERNAM if PERNAMSPE indicates that this has been done.
(Note: An extensive discussion of the derivation of these rules is given in Appendix 1. If the rules which follow immediately below are confusing, the reader may wish to read that appendix before continuing.)
The full name given to any attribute may be chosen freely as long as it can be derived from one entity type and one class type. The permissible entity and class types are listed on the following pages.
Each attribute name must be assigned an alias which consists of concatenated three-letter abbreviations for the entity and class types, in that order.
It may be necessary to include a qualifier type in an attribute name. Each qualifier type will have a three-letter abbreviation which must be suffixed to the six-letter entity and class type abbreviation. Restrictions on permissible qualifier types are not made in the present release of this document. Although locally defined qualifier types may be provided with three-letter abbreviations, it is assumed that the meanings of these will not always be obvious to an external user. Any system which uses locally defined qualifier types must, therefore, provide the user with a fully comprehendible listing of them. The means for producing this list must also be immediately obvious to the user. (This is the second, and final, system requirement made in this document.)
Repeated uses of an attribute name are indicated by sequential numerical suffixes. The alias designation is also suffixed with that number (EEECCCQQQ1, EEECCCQQQ2, etc.).
It is permissible (and often desirable - see Appendix 1) to link attributes together in such a manner that the entire linked group is necessary to provide the desired information.
The tables in which the attributes may be included are named according to the lists of entity and qualifier types. A separate master table will contain both all attributes unique to a specific object and any necessary references to the other tables.
The master table has the alias designation MAS. Every other table must be assigned an alias which is identical to the three-letter abbreviation for an entity or qualifier type.
When abbreviated reference is made to an attribute name which may be found in more than one table, the attribute name must be prefixed by the name of the table in which it is used. The three-letter abbreviation for a table is separated from rest of the abbreviation for the attribute name with a period. The lengthiest alias designation would therefore have the form TTT.EEECCCQQQn, for example, MAS.OBJMEASPE1.
OBJ - Object. Data which describe an object in generic terms.
PER - Person. Data which describe an individual person or a company that may be associated with an object or any other entity type.
FOL - Folk. Data which describe a folk group or similar demographic aggregate which may be associated with an object or any other entity type.
GEO - Geography. Data which describe a geographic location that may be associated with an object or any other entity type.
MAT - Material. Data which describe a substance of which some part of an object may consist.
TEC - Technique. Data which describe a technique which may be employed in the examination, handling, treatment or manufacture of an object.
EXT - External reference. Data which describe a source external to an object or any other entity type, which provide information relevant to that object or entity type.
[Note: The means for distinguishing between individual persons and groups of people is the primary difference between SWETERM as originally formulated and the approach adopted as a result of the CIDOC effort. The types PER and FOL are therefore subject to redefinition.]
Note: These class types and their abbreviations have been selected in specific adherence to a draft framework for the establishment of museum documentation standards which has been proposed by CIDOC. Continued work with the "CIDOC Framework" may result in changes to the following list.
AMT - Amount. Data which indicate an amount of money associated with an entity.
CDE - Code. Data which provide a standardized abbreviated designation for an entity as, for example, its position within a classification system such as the Dewey decimal system or the Outline of Cultural Materials.
CNT - Count. Numeric data which indicate the number of component parts which a composite entity may have. For example, if a single record describes a group of individual objects, their number would be given in MAS.OBJCNT.
FLG - Flag. Data which indicate a logical state, such as "yes", "no" or "undetermined".
IDN - Identifier. Data which uniquely identify an entity. This will normally either be a number which is arbitrarily assigned by the database management software or, when dealing with specific objects, may be an accession number or equivalent.
LOC - Location. Numeric data which describe a geographic location, such as the numeric portion of a coordinate. LOC may be used in the name of an attribute which does not have a numeric value if that attribute is linked to one which does have a numeric value, for example, GEOLOC and GEOLOCSPE (the former providing numerical coordinate values and the latter designating the coordinate system)
MEA - Measurement. Numeric data which describe a physical measurement of an entity. MEA may be used in the name of an attribute which does not have a numeric value if that attribute is linked to one which does have a numeric value, for example, OBJMEA, OBJMEAUNI and OBJMEASPE.
NAM - Name. Data which provide a name for an entity such as the proper name of a person or the accepted designation for an object.
TME - Time. Data which describe an entity in chronological terms. These may include both the numerical designation for a calendar date, or the name of a historical period.
TXT - Text. Data which describe any aspect of an entity which cannot be described in terms of any other class type listed here. This may include form, surface appearance, physical condition, functional integrity, etc.
The following class types are not given in the CIDOC Framework.
VEC - Vector. Vectorized image data expressed in alphanumeric form, such as a DXF file.
BIN - Binary. Data which are not presented directly in alphanumeric format. This includes compressed alphnumeric data as well as bit-mapped image files, audio files, executable programs, etc.
Qualifier types may be defined locally if every such type is given a three- letter abbreviation and the meanings of these abbreviations can be displayed by the system in a manner which is immediately obvious to the user. At present, only three explicit qualifier types are defined here:
LAN - Language. This indicates the language of a data element value.
UNI - Unit of measurement. This will be linked to other attributes which provide or describe numerical data about physical measurements.
TOL - Tolerance in measurement. This will be linked to other attributes which provide or describe numerical data about physical measurements.
In addition to explicitly defined qualifier types, a qualifier may be treated as a discrete attribute which is linked to another attribute to which it refers. The following two attribute types are of particular utility in this regard:
ASC - Mode of association. This indicates the manner in which one entity relates to another. For example, the name of a person associated with an object would be given in PERNAM. The fact that this person was the initial owner of the object would be given in PERNAMASC. (Note that both attributes must be linked together for either of them to be intelligible.)
SPE - Detailed specification. This provides a further level of specificity to an attribute name. For example, if it were unclear whether a name given in PERNAM was that of an individual or a corporation, PERNAMSPE would indicate which. (This also requires the use of linked fields.)
Note that ASC specifies a relationship between two entity types (in the example given above, an object and a person) whereas SPE refers solely to one entity type.
There are a large number of attributes of a museum object which can be included in a descriptive record. When designing a registration system it is convenient, if not necessary, to gather these attributes into smaller groups. One obvious group contains all attributes which refer directly and solely to a specific object. This will include such data as the object's accession number and its physical measurements. The name of an individual person who is associated with the object might be regarded as specific to it, but information about the date of birth of such an individual relates primarily to that person and not directly to the object. Similarly, although the name of a specific object may be "guitar", there is much information relevant to that term which does not relate exclusively to any single guitar. This is also true of geographic locations. The site at which an object was acquired relates to the object. The date on which the site was given its present name relates to the site.
It is of obvious utility for a group of people sharing a common database to apply the same terms to the same concepts. Towards this end, it is convenient to divide a large descriptive terminology into several discrete vocabularies. Some of these will describe entities, such as people or places. A typical entry in the first of these two vocabularies might be "John Smith", in the second, "Stockholm". Vocabularies will also be needed for the description of the associations which may exist between entities, as for example, between an object and the site of its acquisition. In addition to the vocabulary providing a geographic name, an additional one would be needed to provide the term "acquisition" (or "manufacture", "excavation", "examination", etc.).
The system for naming attributes which is being developed here uses six primary entity vocabularies. The first contains the names of objects. The second contains the names of people and corporate entities. The third contains the names of folk groups. The fourth provides names for geographic locations. The fifth lists the materials of which objects may consist and the sixth lists techniques which may be employed in their examination or manufacture. There is also one secondary vocabulary which contains terms used to modify the meaning of primary terms. (The primary vocabulary for object names would contain the term "saxophone". The secondary vocabulary would contain the term "tenor".) Although using a single secondary vocabulary could easily be deemed inadequate, the "what-who-where" division of the primary entity vocabularies should prove satisfactory in most, if not all, museum situations.
It is less easy to provide a small group of vocabularies for the various conceivable modes of association between entities. As with the use of a single secondary vocabulary for use in modifying entity names, the material presented here makes reference to a single vocabulary for all modes of association. Even if this is not regarded as adequate, the basic approach to attribute naming will retain its validity. The definition of any term in a primary entity vocabulary may be subdivided into different types of data. For example, the name of an individual will be given alphabetically, whereas as that person's date of birth will contain numerical data. The name of a geographic location is also given as text but its coordinates are provided in numerical terms.
The data given on this second level can also be placed into a small number of ordered groups. One such group could be restricted to textual data which indicate an entity's name, another could contain chronological data, and a third could contain numerical data describing the physical measurements of an object.
A structured system for naming various attributes can be developed on the basis of what has thus far been said, giving each name in the form of an abbreviated "tag". (This document makes no attempt at prescribing standardized attribute names and none are suggested here. The tags, however, are intended to provide a standard set of aliases for locally defined attribute names.) For example, the first three letters in the name of an attribute could indicate its entity type. Anything taken from the geographic vocabulary could start with GEO. Something from the vocabulary containing the names of individual persons might start with PER. An entry in the vocabulary for types of object could start with OBJ. If it were noted that a database contained an element which started with any of these three-letter combinations, it would be clear within broad limits to what that attribute referred.
The second level could provide an additional three letters in a similarly structured manner. For example, MEA could indicate numerical measurements and TME could signify chronological data (adding "when" to the "what-who- where" given by the three primary entity vocabularies). The name of an attribute giving the physical dimension of an object could thus start with OBJMEA. The period in which it came into being could begin with OBJTME. The date on which a manufacturer was born could start with PERTME, the coordinates of an excavation with GEOLOC, etc.
The six-letter combinations should be as easy to interpret as the three- letter combinations, and would allow an attribute to be understood within narrower limits. In conventional terminology the first level terms (that is, those referred to by the first three letters in the abbreviation) are called entity types. The second level terms (the second three-letter group) are called class types, and indicate the type of data which is provided about the entity; alphabetic, numeric, chronological, etc. A third level may also be used to provide qualifier types. Thus PERTMEBIR could indicate the date of birth of a named individual, the length of an object might be OBJMEALEN, the use of Greenwich coordinates GEOLOCGRE, etc.
It should be immediately obvious that the number of possible qualifier types is extremely large. However, as long as the meaning of the composite abbreviation is clear it should be possible to designate any attribute of a museum object by a limited number of entity and class types, linked with one of the potentially much larger number of qualifier types.
There are two ways of determining qualifier types. The first is simply to provide an extensive list of all terms that may be used, indicating three- letter abbreviations for each. Such a list might contain:
all of which would be suffixed to PERNAM. A list of physical quantities might include:
Rim DIameter (RDI)
for use in conjunction with OBJMEA. (The term "quantity" is a somewhat less than intuitive, but nonetheless standard designation for that aspect of an object which is being quantified. Note that a quantity may be expressed without a unit of measurement as, for example, when a numerical value refers to the number of legs on a table.)
A major disadvantage with this procedure is that there are far more conceivable qualifier types than there are intuitively understandable three-letter abbreviations for them. If the intent of SWETERM is to be followed, any system which contains locally defined qualifier types must therefore provide the user with an obvious means for obtaining descriptions of these qualifier types.
An alternative approach requiring only a single qualifier type can be devised in the following manner. In the preceding example PERNAMCON, PERNAMDON and PERNAMOWN were considered. Additional qualifier types might include such things as "previous owner", "seller", "maker", etc. Instead of providing a long list of more or less comprehendible abbreviations for all of these, the attribute PERNAMQUA (where QUA simply signifies "qualifier") could be assigned the value, "donor", "previous owner", "conservator", or anything else without there being any risk of confusing ambiguous abbreviations. Each PERNAM entry would provide the name of an individual, and the corresponding entry in PERNAMQUA would provide the necessary qualification of the name being given.
These two models differ in that the former uses explicit qualifier types, and the latter uses linked attribute designations to provide all necessary information. It should be noted that the repeated use of an explicit qualifier type, as for example if the names of several previous owners are to be given, may easily be accomplished by sequential numbering: PERNAMOWN1, PERNAMOWN2, PERNAMOWN3, etc. If linked qualifier types are used, it will be necessary to ensure that a linked pair such as PERNAM2 and PERNAMQUA2 unambiguously refer to each other. This may present some difficulty if, say, only the third occurrence of the first attribute requires linking with a second attribute.
The use of an "empty" qualifier type in the form xxxxxxQUA will provide particular difficulty if more than one qualifier type is needed to describe an attribute. Since the suffixed numbers are used to indicate repeated occurrences of linked sets of attributes, simple sequential numbering does not provide a means for linking more than one qualifier type to another attribute.
It will not be necessary to abandon linked attribute designations because of this, but the use of a single empty qualifier type is clearly insufficient. It may, however, be possible to reduce the preceding difficulty to acceptable proportions by using no more than two different empty qualifier types. This may be done by dividing qualifier types into groups, the first of which refers to a single entity only, and the second of which refers to two separate entity types.
The qualifier type which refers to a single entity provides a more detailed specification of that entity. This can be abbreviated as SPE. The qualifier type which indicates the mode of association between two entity types can be abbreviated as ASC. Exemplifying this with geographic data would allow for the following set of linked fields: The first would be GEONAM, containing the name of a geographic location, such as "Swan Lake". The second would be GEONAMSPE, indicating that Swan Lake is a city. The third would be GEONAMASC, stating whether Swan Lake was the site of the object's acquisition, manufacture, primary use, or any other possible mode of association. (Further attributes which might be linked into this group are GEOLOC for the numerical value of Swan Lake's coordinates, and GEOLOCSPE for the coordinate system, such as "Greenwich".)
Returning to the example of PERNAM, PERNAMSPE might be used to indicate an individual's professional title, and PERNAMASC to indicate the relationship of that individual to an object; if "previous owner" or whatever.
The qualifier SPE may also be used to indicate the level of classification or taxonomic rank of an object. The OBJNAM, "spoon" would probably not be linked with an indication of its level of classification. The OBJNAM, "Canis", could however be linked with the OBJNAMSPE, "genus" (unless OBJNAM were used to contain an entire bi- or trinomial scientific name). A tuba could be OBJNAM "tuba" and OBJNAMSPE "Bb", whereas a foreign dialectic name for a little-known wind instrument could put the vernacular name in OBJNAM, with "aerophone" in OBJNAMSPE.
As a final example, the recording of physical measurements will be considered. There are a particularly large number of metric attributes which might be recorded depending on the individual requirements and preferences of different workers. Legitimate demands could be made for the definition of a virtually limitless series of attributes such as "rim diameter", "maximum length", "base weight", "number of legs", and "shoulder angle". Any one of these quantities could, however, be described with the three attributes, "numerical value", "unit of measurement" and "quantity".
In accordance with the previous treatment of this example, an alternative designation for numerical portion of a measurement could be OBJMEA. "Quantity" could be given as OBJMEASPE, indicating if the numerical value was the length, width, number of legs, rim diameter, or any other quantifiable aspect of the object. The unit of measurement would require the dedicated qualifier type UNI. The degree of accuracy in a measurement can be given with the dedicated qualifier type TOL.
Typical values for OBJMEA, OBJMEATOL, OBJMEAUNI and OBJMEASPE and might be: "45", "± 0.5", "mm"," rim diameter" or "72", "± 1", "degrees","shoulder angle". Since several numerical aspects of a single object may be recorded, the provision for one occurrence of each of may not be sufficient. Although it would be possible explicitly to define a series of attributes such as OBJMEA1, OBJMEA2, OBJMEA3, there would be no objective way to determine their maximum permissible number, nor would there be any differences in their basic descriptions. It is therefore left to the user to append any numerical suffixes which are necessary for the repeated use of any attribute. It should, however, be noted that identically numbered occurrences of any associated attributes are to be treated as a single logical unit. That is, OBJMEA3, OBJMEAUNI3 and OBJMEASPE3 are linked with each other.
The ordered structure which has now been given to the various vocabularies can conveniently be represented as a "table". Each row (horizontal line) in a table corresponds to a single primary term. In the table which presents the geographic vocabulary, for example, the first row might be for "Sweden", the second for "Chicago", and the third for "Europe". The columns (vertical structures) of the table would correspond to the individual attributes as derived above, such as GEONAM, GEONAMSPE, GEOLOC, GEOLOCSPE, etc. Each of the other vocabularies may be seen as a table consisting of rows and columns. It will be useful from here on to refer to each of these vocabularies as a table.
The system being developed does not yet provide a means for distinguishing between descriptive aspects of an entity in the generic sense and in the specific sense. A "teaspoon" may be defined as having an average length of 140 mm. This would be given in OBJMEASPE. The actual length of a particular teaspoon might be 120 mm, which would also be given as OBJMEASPE. One obvious way to avoid any confusion that this might cause would be to use different qualifier types for these two cases. It would not be adequate to use LENgth instead of SPE, since this would not eliminate the ambiguity. Some means is necessary to indicate the generic length as opposed to the specific length. Defining qualifier types such as GLE (generic length) and SLE (specific length) would soon result in a plethora of attribute names which would defeat any attempt at their presentation in an intuitively intelligible manner. There are other examples of this type of ambiguity and it will be necessary to provide some other systematic way of indicating a distinction between generic and specific attributes.
The opening paragraph of this appendix made reference to a group of attributes which refers directly and solely to a specific object, including such data as the object's accession number and its physical measurements. These attributes may also be given in tabular form with each row in the table being identified by an accession number (or equivalent) and the columns corresponding to the various attributes which it contains. Each row in this "master table" will contain unique data, and will also either duplicate or make reference to data provided in the other tables.
The attribute OBJMEASPE in the OBJ table will contain generic data about an object. The attribute OBJMEASPE in the master table will, however, contain data specific to an individual object. The generic length of a teaspoon could therefore be given as OBJ.OBJMEASPE and the length of a specific teaspoon as MAS.OBJMEASPE (where MAS is an abbreviation for the master table).
The abbreviations for the table names should not be seen solely as prefixes to the abbreviations for the attribute names. The use of SQL and other query procedures can require separate references to be made to the tables and the attributes which they contain.
All this having been said, the main body of the text lists those entity, class, and qualifier types which presently appear sufficient for use in providing an alias designation for any attributes which might be included in a museum database. Only the qualifier types specifically derived above are listed. The alternative multiplicity of qualifier types can be presented as a standard only by the presentation of extensive prescriptive terminological authority lists. The development and publication of such lists lies outside the current scope of this document.
The normative intent of the material provided here is such that the terms listed will not be altered subsequent to a several-month period of review of its initial release. Additional terms may, however, be added to the lists of entity, class, and qualifier types at any time. It should also be noted that there is latitude for discussion about the proper list into a which a term should be entered. (For example, "unit of measurement" is given as OBJMEAUNI to indicate clearly its conjunction with the other attributes beginning with OBJMEA. Units of measurements can, however, also be treated as entities and could properly be given as entity types. A unit of measurement would, in that case, be UNINAM.) This is of little consequence as long as the abbreviated designation for an attribute is immediately comprehendible by the user. It is assumed that this will invariably be possible on the entity and class levels, but that some ambiguity on the qualifier level may be unavoidable. It is for this reason that the use of additional levels of detail has not been contemplated.