| Design for an Archival Description System, Application
of ISAD(G): A Study
Table of Contents
Backgrounds and purpose of the Study Description is generally recognized as one of the core activities of an archives, producing the interface between the users and the archival holdings. Perhaps in some degree stimulated by the expected possibilities of the computer, in many countries archivists are re-conceptualizing their description methodologies. Although the Principle of Provenance widely has been accepted as the theoretical basis for both arrangement and description, methods and techniques of description show a big variety, according to national or institutional practices. This lack of standardization is not only confusing for users, but might also be an obstacle for successful implementation of international archival networks and information systems, and consequently for the dissemination of archival information. As a contribution to solve this problem, the ad-hoc commission on archival description, established by the International Council on Archives, drafted and published the International Standards for Archival Description (General) (Ottawa, 1992). The study has been carried out as one of the work items of the 1992-1996 workplan of the ICA Committee on Archival Automation (P-IA). The ISAD(G) rules contain basically data structure standards, and data contents standards. They describe the data elements of archival description, but do not analyse in great detail the relationships between the data elements. The generic model, presented as an appendix in the ISAD publication, makes clear how the elements should be interpreted, but this straight-forward model is not meant to be a formal design of an archival description system. The relationships in a records system are more complex; the ISAD model, for example, does not contain the context, the organizational part, although in the text these elements are mentioned. Therefore the ICA Committee on Archival Automation has taken the task to develop a more elaborate model, that may serve as a basis for system development or software selection, as well as the exchange formats. This data model, however, does not pretend to be a comprehensive system design, but rather a framework for such a system. A complete system design consists in both a data model and a process model. The data model describes the structure of the descriptive elements. Besides this part the objectives and the functionality of an archival description system should be defined as well. This second part of the design, however, is only briefly discussed, being not within the scope of the study that primarily focuses on the data structure. Terminology This study is about archival automation. The primary readers are supposed to be archivists, from whom some knowledge of data modelling might be expected. Moreover the readers are considered to be conversant with archival theory. With respect to archival terminology the Dictionary of Archival Terminology has been the main source. Where divergent terms are used, is such indicated. Structure of the Study Though this study pays some attention to the process model, the emphasis is on the data model. Chapter 1 describes the functionality in natural language, rather than to present it in a formal model, such as a set of Data Flow Diagrams. Eventually such diagrams could be developed in order to obtain a complete, formal reference model of an archival description system. In addition to the functionality the entities and their interrelationships are analysed in chapter 2: the Universe of Discourse. What is the object of description, or rather: which are the objects. The whole chapter is rather theoretical. It aims to present a conceptual description of records and their context, not to be a design for a database. Chapter 3 puts the results of the analysis together into a formal data-model, of which in Appendix 1 an Entity Relationship Diagram is presented. The text defines and describes the entities and their interrelationships, and eventually their major attributes. Formal table descriptions, based mainly on the conceptual model, are presented in Appendix 2. As much as possible the entities in the model are one-to-one translated into database tables. These table descriptions help to understand and evaluate the diagram. Since the previous chapters are basically theoretical, some attention should be paid to the implementation. This is the subject of chapter 4. A few alternatives are discussed, according to required level of detail, or application area. The systems functionality, briefly sketched in chapter 1, will be elaborated. Appendix 3 describes the database tables related to one implementation model. The data model is matched with the ISAD(G) standards in chapter 5. Similarities and differences are identified and commented. The chapter shows how and where the ISAD standards should be applied in an archival description system.
1 Functions of an archival description system 1.1 Purpose of description systems The purpose of an archival description system is the generation of archival descriptions to be available for retrieval in a finding aid system, either automated system or manual. An ideal system supports national or institutional methodologies and standards, and complies to international standards as well. The main functions of the system are traditionally described here as input functions, store functions and output functions. The models, presented in this document are a blueprint of an archival description system that provides information to users of the archives, both from inside or outside the records creating organization; internal archives management functions, however, are not directly taken into consideration. 1.2 Input Functions Summarized, the input consists in archival descriptions at all distinguished levels: collection (such as Fonds, record group, or whatever highest level may be distinguished); series, sub-series (theoretically an unlimited number of sub-series), files, items. According to ISAD(G) an archival description consists of a creation of a representation of any archival unit and its component parts, if any (established during the arrangement process as a unit of description), using the multi-level technique (a technique by which the representation of the archival unit is the sum of its single description with each single description of its component parts). ISAD(G) proposes a top-down presentation of the archival descriptions. Yet, in order to support the process archival description in all stages of the records life cycle (or records continuum), an archival description system supports bottom-up description as well. Higher levels of arrangement may be established after identifying the lower level units. Regardless the various archival practices, what is expected of an archival description system is functional flexibility. Any unit may be subdivided. A Series may be established according to national or institutional standards: based on pre-defined criteria. A Series can be settled down based on form of material (formal series), business functions (functional series), or on the recordkeeping system (classification series). A Series can be split into Sub-series, etc. A (custodial) Fonds may be divided into sub-fonds. The question whether a sub-fonds is an archival concept or not, is not of any importance for the system design. A sub-fonds may be considered as being the highest level Series (based on the organizational structure), or as a (sub) record group. These structures may have been established by the current record keeping system, or have been established by a former one. The structure may have been presented in the form of a classification scheme. Apart from description of the record groupings in archival items, such as files, the system supports the description of the structure of the Fonds. This structure may be established by the current record keeping system, or have been established by a former one. The structure may have been presented in the form of a classification schema. Another possibility would be that not such an explicit structure has been set up, but that the inter relationships between the records is derived from the relationship of the records with the business functions of the organization. A third possibility is that the records should be directly linked to organizational units. A combination of two or three structures is possible as well. The system supports all of this possibilities, eventually an archival item could be linked to both a classification schema, a function, and an organizational unit. These linkages may be complicated; a record may be linked over time to different functions, organizational units, or even classification schemes. Two or more linkages could be occur at the same time. Each of the linkages may have a specific meaning, and may have last a limited time. The Data Model describes all of these possibilities in detail. The description of the relationships between records should be made as easy as possible. Although theoretically the relationships between the Fonds and its creator are established at the records level (being all higher levels, such as item, series, etc, record keeping constructs), it should be possible to describe them at the highest possible level. If, for example, all the records belonging to a Series, have the same classification number, and/or are the result of one business function, description of this relationship at the series level will be sufficient; the system automatically links all the lower levels to the structure. (In Object Oriented terminology: the lower levels inherit the attributes of the higher levels). Exceptions at the lower levels may be described by over-writing the default value. The system supports the description of the business functions of the record creating organization(s), as well as the organizational structure, and the organization's formal mandate. The description of the structure of the Fonds, discussed in the previous section, is rather a matter of linking records descriptions to those of business functions, and organizational units, than a real description activity. The description of organizations and their functions should be supported by authority control functionality. The functionality, discussed in the previous paragraphs, supports the basic requirements of modern archival description: to make explicit why records were created, how they were used, and for what mandate they were needed. 1.3 Output Functions First of all: a description system is not a retrieval system. The system supports the archivist in his archival task, not directly the researcher in his work. Yet, the results of the system, the archival descriptions themselves, are essential for identifying records. After completion, the descriptions become part of another system, specifically for information retrieval. Such a system may have the form of a manual finding aid system, an institutional automated system, or an inter-institutional network system. At the conceptual level the output functions of the descriptive system support any kind of interface with the retrieval system, both hard-copy or automated. At the implementation level the required interfaces should be identified and developed. Interfaces may include: hardcopy guides, inventories, and other kind of finding aids; MARC records for data-exchange, records for a proprietary database, SGML-files, or WWW pages. Also conceptually, the system supports the reconstruction of a Fonds (as a logical concept) by reporting all the descriptions of items created by one single person or organization. The system does not need a specific definition of what constitutes a record creator; this might be rather a matter for institutional or national standards. The structure of the database will support this, as will be shown in the next chapter. 1.4 Store Functions The logical structure of the store of archival descriptions is the very heart of this study. The system stores descriptions for further processing, though it must be recognized that the system is not a database in itself. One should keep in mind that the purpose of the system is supporting description. The Data Model, described in chapter 3, presents the logical structure of the store. Ideally the implementation should be a data base management system, to enhance the possibilities of further processing. The descriptions are at least stored during the whole description process. The store function supports simultaneous describing of more than one Fonds. By this functionality integral description of a set of inter-related Fonds, and multi-provenance Fonds will be supported. A general requirement of the database is to support a variety of output formats, as listed below in the next section.
2 Analysis of the Entities to be described 2.1 Purpose and method The data model is the kernel of the system, and forms the basic design of the database. To a great extent, the data model can be gathered from the system functions. The functional requirements of the archival description system determine the data to be processed. For a model supporting international standards, however, the data structure should primarily be not too function dependent, being the functions of a description system in their turn strongly dependent of institutional practice. The data model is developed from scratch. Afterwards the ISAD rules will be applied to it. This approach offers even the possibility of testing ISAD(G). To make this comparison easy, the ISAD terminology has been adopted as much as possible. According to current archival theory a clear distinction is made between the records and the filing structures at the one side (records system), and the organizational context at the other side (record creating system, or functions system). This twofold concept is supported by ISAD(G). Both worlds consist in a number of entities. The next sections describe these entities and their relationships, in the form of short sentences, with explanations where appropriate. The sentences have basically the form <noun - verb - noun>, in which the noun refers to an entity, and the verb to a relationship. The formal sentences are numbered for reference. 2.2 Theoretical Issues From the moment that archivists have to deal with electronic records, the debate about what constitutes a record has lived a revival. Contrary to the paper world, a record in the electronic environment cannot be considered as a physical entity. This Study does not go into this debate, but seeks its starting point at the lowest level: the Item, being the smallest archival construct, such as a file, or a volume. (In the chapter on the data structure shall be discussed that the meaning given to this term differs slightly from those assigned to it by ISAD.) A record (logical item) is the result of a business transaction, an archival item is the result of recordkeeping or archives keeping practice: putting records together for records and archives management purposes. Similarly the higher levels, such as sub-series, series, and so forth are archival constructs. Another discussion regards the concept of the Fonds. The ad-hoc commission on descriptive standards considers the Fonds as being the highest level; the commission seems even to consider the Fonds as a manageable, and physical entity. Again a long debate may be held on this point. The Study again does not go into this discussion, and introduces the Custodial Fonds as the highest level construct, equivalent to concepts such as Archives Group, or Records Group. Where in this document the word Custodial Fonds is used, it may be replaced by any other word that reflects another archival tradition. The model, developed in this document, also supports, however, the concept of the Fonds as a logical entity. This will be demonstrated in the discussion on implementation in chapter 4. 2.3 The records This section discusses the entities related to the records, and the recordkeeping system. Again, to avoid a debate on archival matters that does not contribute to this model, the concept of the record, or logical item, will not be discussed in detail. We consider a record to be an equivalent to an archival document, a result of a business transaction. Usually the single document is not the lowest level of description, but a file, or any other kind of groupings of documents (records) that will be produced for consultation (e.g. in a reading room.). ISAD reserves the word Item for the smallest, intellectually indivisible archival unit, e.g. a letter, memorandum, report, photograph, sound recording. Since a File is an organized unit of documents ... there is no term for the amalgam of units that usually form the basic elements, properly labelled and numbered. Therefore, we propose to use Item for those basic units: sometimes a file (folder), sometimes a single document, such as a report, a map or a sound recording. Eventually the system supports the description of parts of Items, such as single documents, or even of parts of documents, such as seals. For a more detailed discussion on this subject, see chapter 3. In sentences:
Both, records and (physical) archival items may be grouped into aggregates, archival constructs, such as Series or Sub-series, etc. The criteria for such a grouping may be implicit or explicit. Explicit criteria are such criteria as classification codes, or labels, assigned to the items or records by the record keeping system. Implicit criteria usually derive from the business function or from the form of material. These implicit criteria might have been made explicit by the record keeping system, and used as the basis for the classification system, or might have been kept implicit until archival description. Such Series might be called respectively Classification Series, Functional Series, and Formal Series. The highest grouping (record group, fonds) is determined by provenance. According to archival theory, including the most recent opinions about multi-provenance fonds, we reserve the word Fonds for the logical whole of records created by a person, or body. Physical Fonds (or Record Groups) may be, due to record management activities, reorganisations, and so on, exist in records from different conceptual provenance. The criteria for grouping in such cases are custodial. Therefore we call the highest levels of grouping Custodial Fonds. The Logical Fonds is the mere sum of all the records created by an entity to be considered as an independent records creator. A Custodial Fonds may be defined as a body of archival items, preserved in one repository, and for administrative purposes considered to be a whole, and the highest level of administrative control. A Conceptual Fonds may be physically scattered over more than one custodial fonds. We are well aware of the fact that this concept is not a part of ISAD(G), but as we will demonstrate later in this study, it is not in conflict with it, but rather an extension. We recommend the commission on descriptive standards to include in the standards the distinction between record and physical item, and consequently between logical fonds (the whole of records created by a person, or body etc) and the custodial (or physical) fonds. In sentences:
A few additional remarks might be useful. Items may be grouped (or have been grouped) into one or more Series. Because of the fact that the grouping can happen according to different criteria, and the grouping is rather an aggregation than a physical arrangement, an Item can belong to more than one Series, simultaneously, or during different periods. Consequently the grouping into a Custodial Fonds does conceptually not occur via the Series, but directly. Yet, in many cases grouping within a Custodial Fonds is pure hierarchical; the system should support this in the implementation. Over time an Item may belong to different custodial fonds; being transferred from the one fonds to the other is not the same as changing custodian, although that can be the case as well. A custodian has one or more custodial fonds under his custody (or series if that is the highest level). The custodial function is carried out by (an organizational unit of) the record creator, it successor(s), and/or eventually by an archives. In sentences:
2.4 The organization and its functions The second part of the data model concerns the organizational context in which the records are created. Again we start at the bottom line: the business transaction, and again we do not go into the discussion what a business transaction is. We define a business transaction as an activity that is part of a business process, and produces one or more records. At this level occurs the conceptual link with the recordkeeping part, described in the previous section. In the implementation, discussed in chapter 4, the link may be established at higher levels, recommended by ISAD. Ideally all the records produced by one transaction (or set of transactions) constitute an Item. According to some archival theories all the recorded information created by one transaction constitute one record. The model discussed here supports this opinion, as well as the notion of multiple record creation per transaction, and the notion that one record is created by more than one transaction. Appendix 1, sheet 2 works this out in the form of a detailed Entity Relationship Diagram. All the documentation created by one business transaction might be considered as being a logical record. The item, as result of the recordkeeping system, is a physical record. Rather for record-keeping systems than for archival description systems might be of interest the use-relation between a business transaction and a record: the observation that a record my be used by one or more business transactions, and that a business transaction may use one or more records. (The modify relationship is considered to be creation). A business process consists in one or more transactions. Consequently a business process result in one or more records. The business processes carry out the organizations functions. The operationalisation of a societal function requires one or more business processes. For public organizations the societal functions are based on law; the functions of private organizations may be rooted in formal mission statements, but also be unwritten. In the next chapter we introduce the generic term Actor for a body to which societal functions are attributed. Societal functions are attributed or mandated to the whole organization. The business processes are likely distributed over the organizational units. Putting the previous aline in formal sentences:
Most of the organizations consist in smaller units, over which specific business functions are distributed. Organisations may be abolished after a certain time, or succeeded by another organisation, either completely (all functions), or partially. In fact, succession means taking over one ore more functions. Eventually even a part of a function (a competence) may be transferred. Again in sentences:
3.1 Introduction and method The entities and their interrelationships are formally presented in an Entity-Relationship Diagram, in Appendix 1. This chapter explains the diagram by means of a textual description of the entities, the relationships between them, and the major attributes. Each of the entries has the same structure: definition and/or description, main attributes (if appropriate to list these), and relationships with other entities. Entity names are printed in Italic.. The chapter follows the same sequence of discussion as chapter 2; the diagram should be read from the bottom to the top, and the right hand part first. 3.2 The Record System Record The International Dictionary of Archival Terminology (forthcoming) defines a record as: "A document created or received and maintained by an agency, organization, or individual in pursuance of legal obligation or in the transaction of business." An alternative term, more in line with ISAD, would be Logical Item. However, we prefer the term Record. For the purpose of this document many definitions of record may be used. A record is considered to be the smallest logical whole of information, recorded in the course of conducting one Business Transaction. A record might have the form of any kind of document, such as a letter, a memorandum, a receipt, but also be a part of a physical document, such as the minutes of one meeting recorded in a register of minutes, an entry in a cashbook, or a piece of recorded information in electronic form. The main attributes of the entity are the contents, the informational representation of the transaction, the logical form in which the information is presented (e.g. letter, memo, map), and the date of recording. The relationship with Business Transaction is twofold: creation/modifying (many to many), and use (many to many). A Business Transaction creates none, one or more Records (optional relationship). A Record is created by one or more Business Transactions (mandatory relationship). A Record is used by none, one or many Business Transactions (optional); a Business Transaction uses none, one or many Records (optional). (See Appendix 1, sheet 2). Item ISAD(G) defines an Item as "the smallest intellectually indivisible archival unit, e.g., a letter, memorandum, report, photograph, sound recording.' This Study would rather define this as a Record. We prefer to reserve the word (Archival) Item for the smallest physical archival unit; in many cases it might be possible to divide it in smaller parts (for example a folder, which can be divided in the single documents that are kept by it), but is de facto kept as a whole (either by records manager, or archivist). It is the unit that will be produced in a search room for research, or loaned to a staff member of the record creating organization. The entity Item includes archival units such as File, Register, Card-tray, etc. An alternative term might be Piece. Compare the ISAD definition of File: "An organized unit of documents grouped together either for current use by the creator or in the process of archival arrangement, because they relate to the same subject, activity, or transaction. A file is usually the basic unit within a record series." Main attributes of the Item are reference code and physical form. Attributes such as date are deduced from the Records they contain. Attributes such as classification number are deduced from the relationship with Record-keeping System. The relationship with Record is complex: an Item contains one or more Records (mandatory). A Record is part of one or more Items (mandatory). The first relationship might be obvious after the explanation of both Record and Item. The latter is less obvious. A Record may change Item (result of a record keeping action). In this case at one moment a Record would only be part of one Item. Depending of the chosen definition of Record, and its relationship to the Business Transaction, even one logical Record might be recorded at one time on more than one Item. An example: if a complete financial transaction, such as the payment of a purchase would be considered as one Business Transaction, the recording of this will likely be scattered over more than one Item in the book-keeping system (daybook, ledger, etc.). Consequently the relationship, in the model presented as associative entity Arrangement, between Record and Item has at least own attribute, such as Timespan. Series ISAD(G) defines the Series as: "Documents arranged in accordance with a filing system or maintained as a unit because they result from the same accumulation or filing process, or the same activity; have a particular form; or because of some other relationship arising out of their creation, receipt, or use. A series is also known as a records series." Basically this definition serves the model, except for the word Document, which might be replaced by Record or by Item. A Classification can be attributed to the Item, but implicitly it is attributed to the Records the Item contains. Arrangements based on form of material, or activity always concern Records. (In the implementation, discussed in chapter 4, other solutions might be chosen, however). Series are aggregates, archival constructs, and consequently they receive their attributes from the aggregated elements. Yet, in practice, a Series has something like a title, assigned by the record keeping system, or by archival description. The dates, and physical extent are theoretically calculated. (Again, in implementation the values for such attributes will often be obtained by user input). A Record , or an Item can be arranged into none, one or more Series, even simultaneously, since Series are created by applying different criteria. In the course of time too, Records can have been arranged into different Series. The relationship between Records and Series is consequently a many to many relationship, optional at the Record-side, mandatory at the Series side (a Series does not exist when it does not have any part). The relationship (called Aggregation) has attributes by itself, such as date, and refers to the Record Keeping System as well. A Series may be a part of a higher Series (recursivity). The number of Series levels is theoretically unlimited. Record Keeping System The Record Keeping System defines (or defined) the arrangement of the Records during the period that they were a part of the creator's information system. Respecting the original order, a describing archivist uses the Record Keeping System as a basis. As has been pointed out in the section on Series, in the course of their active life Records may have been subject to one or more Record Keeping Systems. There is always a Record Keeping System, even if it has never made explicit. An important part of archival descriptive work is reconstructing the Record Keeping System, and making it explicit. A classification schema, designed and applied afterwards by an archivist, is considered to be the representation of an implicit Record Keeping System. The measure in which this representation deviates from the original order (Record Keeping System) is a matter of quality. Attributes of the entity Record Keeping System are type of system, and arrangement rules (such as chronological, or systematic). The Record Keeping System relates Records to Items, and both Items and Records to Series by applying its rules (criteria). A Record Keeping System is maintained by an Organizational Unit (or an archives). By establishing this relationship, the provenance of the Record Keeping System is made explicit. In fact, more than one Record Keeping System could have been in place. The model supports this phenomenon. The Record Keeping System may have been maintained by one or more Organizational Unit (see next section); an organizational unit may have developed and maintained one or more record keeping system. This relationship between organizational unit and the record keeping system is represented in an associative entity: Recordkeeping. Custodial Fonds As has been clarified in chapter 2, the idea of Custodial Fonds, may be exchanged for Record Group, Archives Group, or any other kind of high level grouping used by an archives. ISAD(G) considers the Fonds as the highest level: "The whole of the documents, regardless of form or medium, organically created and/or accumulated and used by a particular person, family, or corporate body in the course of that creator's activities and functions." Apart from the word documents, to be read as Records, the definition meets the concepts of the model, but such a Fonds is rather conceptual than physical. High level archival constructs, although sometimes called Fonds (or particular language dependent translations), consist very often in Records from more than one provenance (Multi-provenance fonds). The Fonds (conceptual) is the whole of Records created by a record creator; the Fonds archivists have in custody is the whole of records (or even actually: Items) brought and kept together as result of records and archives management activities. For this type of "Archival Collection" we use the word Custodial Fonds, as a neutral term. A Custodial Fonds is the whole of Items, kept together for records or archives management purposes, and preserved in one repository. Consequently the Custodial Fonds is of a different nature than (Records) Series. The Series is theoretically a logical construct, based on Record attributes. The Custodial Fonds is a physical construct, based on custodial criteria, regarding to Items. As far as the orginal Record Keeping System implemented the logical arrangement criteria on Items, the Series in which they are arranged is physical as well. The model does not explicitly deal with the Sub-Fonds, but considers this rather to be a Series. Since in fact the Custodial Fonds is a gathering of the Items, its attributes are aggregated from the Items. Yet, the custodian will assign a name and/or identification to the Custodial Fonds. In the implementation attributes such as dates, and physical extent will be keyed in, rather than being calculated. A Custodial Fonds has its own history, describing mainly the record management developments. A Custodial Fonds consists in one or more Items (mandatory). An Item may be or have been part of none, one or more Custodial Fonds. At one time an Item can only be part of one Custodial Fonds (optional). An Item changes Custodial Fonds by Transfer, identified by attributes such as date. Custodian A Custodian is a keeper of records or archives. The custodian might be a separate organization (e.g. an archives) or an Organizational Unit within the records creating organization, such as a records management group. The latter relation has not been made explicit in the diagram. Consequently the attributes of a Custodian are the same as Organization(al unit), see below in the section dealing with the Organization System. A Custodian keeps one or more Custodial Fonds (mandatory). A Custodial Fonds is kept at one time by one Custodian (mandatory), but can be transferred from one custodian to another Custodian. (See Custodial Fonds for the notion of Transfer). 3.3 The functions system Business Transaction A Business Transaction is a discrete activity carried out in the course of a Business Process. A series of related Business Transactions may constitute a case, but this has not been worked out in the model. Such might be the subject of workflow management systems. The relations between the Business Transactions and the Records would be subject of document flow management systems. In this model we distinguish Use and Create Relationships. The way how the results of Business Transactions are reflected in archival Items depends of the Record Keeping System. A Business Transaction may be described by a name, date, as well as the reference to the Business Process of which it is a part. A Business Transaction is part of one Business Process (mandatory). Business Process A Business Process is the operationalisation of the Functions which the Organization has to perform both for its environment (Societal Functions, tasks), and for its internal house keeping. A Business Process has a name, derived from the Function it fulfils. A Business Process may be carried out by one or more Organizational Units (optional), during a certain time. The attribution of the Business Function to an Organizational Unit is usually based on internal regulations. Business Processes can be transferred from one Organizational Unit to another one. Splitting up a Business Process is considered to be abolishing the Process, and establishing new ones. Since the Business Process is the "translation" of the (Societal) Function into concrete procedures and activities, it is dependent of the organization's Competence. The many-to-many relationship between Business Process and Business Transaction is called Labour Division. Societal Function A legal or natural person fulfils functions for its environment. Likely public functions are based on legislation, and accordingly assigned to legal bodies. A Societal Function can be assigned to one or more legal bodies, both public and private. The assignment may include a limitation in competence (such as market segment, region, jurisdiction). Private organizations do not necessarily have a limited competence. A Societal Function has a name as the principal attribute. The other attributes are received from related entities, such as Actor, Competence, Legal Basis, and Business Process. A Societal Function is based on none, one or more Legal Basis. The Legal Basis assigns a Function to an Actor, and defines the Competence. An Actor to which a Societal Function has been assigned, makes these within its Competence operational in Business Processes. Legal Basis The role of the Legal Basis has been explained before, in the lemma Societal Function. A Legal Basis might be a formal law, a ministerial regulation, a local bylaw, Statute, Covenant, or a formalized Mission Statement. Internal Organizational Regulations might be considered as a Legal Basis as well. For public bodies the Legal Basis is more developed than for private organizations. Attributes of the Legal Basis are the name of document in which the basis has been recorded; this might have be the form of a regular bibliographic description. Reference to the section should be made as well. A Legal Basis may be the basis of one ore more Agencies, Societal Functions, and Competencies (all optional). Each of the entities can be based on none, one or more Legal Basis. Actor The term Actor has been used in a general way, and may be replaced by any other term that reflects the notion, such as Actor. It refers to any kind of legal or natural person, including public bodies, private organizations, associations, families, and single persons. The Actor may be considered as the Record Creator, but also parts of the Actor (Organizational Units) may be considered as record creator. An Actor is the body responsible to performing the Societal Functions that are assigned to it. An Actor has a name, a date-span, eventually a formal residence. The name might change over time, without changing the Actor itself. The relationships of the entity Actor are described before: an Actor has none, one or more Competencies, by which one ore more Societal Functions are assigned to it. The Actor assigns, based on the Competence, Business Processes to its constituent Organizational Units. (Labour Division). Successor - Predecessor relationships are theoretically established via the Function, by transferring (a part of) the Competence. Organizational Unit An organization exist by the fact that a body is sub-divided into two or more units. An Organizational Unit has a name. An Organizational Unit may be sub-divided into lower levels of Organizational Units. The number of levels is theoretically unlimited. An Organizational Unit carries out one or more Business Processes (mandatory relationship). A special kind of relationship is Recordkeeping, that relates an Organizational Unit to the Record Keeping System it maintains. Competence The entity Competence is a complex relational entity, to establish the many tot many relationships between Actor, Societal Function, and Legal Basis. A Competence has a few attributes, such as description of the limitation, and time-span. The relationships of Competence has been discussed before.
4.1 Purpose and method of the chapter The previous chapters described the conceptual model of the descriptive system, particularly focusing on the data model, the entities to be described and their relationships. An operational description system, however, may deviate from the model, due to institutional requirements, or the proper function the system should perform. An ideal implementation in an automated system would be a one to one mapping of the entities on the data base structure, but other solutions are possible as well. The next sections discuss alternative implementations. 4.2 Recordkeeping Implementation an archival description in a record-keeping environment would likely put the emphasis on the relationship between business transactions and records, and on the filing mechanism. The relationship between record and transaction can be established according to institutional standards. Use of the records might be recorded by the system. Likely the system will maintain one system of arrangement, and consequently the relationships between series and records are more straightforward than in the model. Since a record-keeping system should be based on the organization's functions, attention would be paid on this part of the model. The system should support the organizational changes, as well as the changes in tasks and business processes. Since the record keeping system works for one organization, the relationships between societal function, competence and business process might be implemented directly from the point of view of the organization. Basically the description will take place bottom-up: the Series follow the Records. Despite of some simplifications, for the greater part the conceptual model, as presented in Appendix 1, with the extension of sheet 2, may serve as basis for the implementation. 4.3 Archival description The description in an archives, keeping many fonds, will possibly be carried out top-down; preceded by analysis of the material, first the Fonds is described as a whole, than the Series, the Sub-series, etc. The contextual part of the description could be done as elaborate as the model shows, but since this might be too labour intensive, entities may be put together in a free text description, such as an administrative history. Ideally, however, the relationship between the function (business process), and the records (Series, Items) is described at the appropriate level. The lowest levels, the business transaction and records, likely will be skipped. Relationships between records and the Series, may be established via Items. Top-down description implies that the lower levels inherit the attributes of the higher levels. For example, if a Series is linked to a particular process, all the Items are automatically linked to this process. The system should support however 'over-writing' per Item, in order to describe 'mistakes' by the record keeping system, and/or variations due to transfer of records, or transmissions of functions. Appendix 3 presents such a simplified implementation model, both in the form of an Entity Relationships Diagram, and of Table descriptions.
The Data Model Study, at issue, has been drafted from scratch, though it should support the ISAD(G) rules, or at least examine the applicability of ISAD(G) in an archival description system based upon the model presented in this Study. This chapter makes a comparison between this model and ISAD(G). This comparison may test the validity of both the model itself, an the ISAD(G) standards. The first table lists the major data model concepts, and refers the ISAD(G) concepts to them. The second table lists all the ISAD(G) data elements, and refers them to the entities of the model, and how they might be applied. Table 3, finally lists the data elements of the conceptual model, and refers them to ISAD(G), in order to identify the data element not mentioned in ISAD(G), and eventually subject to further standardization. Table 1: Data Model - ISAD(G) Comparison
Table 2: ISAD(G) elements - Data Model Comparison
Conclusion on Table 2: The conceptual model, as described in this Study, covers all ISAD(G) data elements. In the simplified implementation model, as described in Appendix 3, the ISAD(G) data elements are added explicitly. Table 3: Conceptual Model Tables - ISAD(G) Comparison Only the major tables are taken into consideration for this comparison; not the associative tables. Neither are the system assigned keys and the foreign keys listed.
Conclusion on Table 3 Most of the data elements are covered by ISAD, except of the tables
regarding the creators functions and its legal basis.
![[Go to ISAD Appendix 1]](gifs/asap_right_dbg.gif){kind=small}
|
Published by: Australian Science Archives Project on ASAPWeb
Comments or questions to: ASAPWeb
(asapweb@asap.unimelb.edu.au)
Prepared by: Barbara Cytowicz and Lisa Cianci
Graphics by Lisa Cianci
Date modified: 4 March 1998