7 Common Reference Schema

7.1 Introduction

7.1.1 The schema in a Directory context is normally made up of the following key components:

• a statement of the place holders, or attributes, that the Directory can accommodate

• a statement of how various of these attributes, objects or object classes are to be grouped in order to give a sense of order and internal structure to the data

• a statement of the "tree" that provides a hierarchical view as to the various objects or object classes and in turn gives them an overarching structure.

7.1.2 Appendix 1 contains a summary document that covers the first two items of this list. This document does not, however, cover the third item (a "tree" statement), for reasons which are discussed later in this section.

7.2 Groupings of Attributes: Object Classes

7.2.1 The names given to the core objects in the S.E.E. Directory are intended to be generic and do not reflect any particular legal or governmental language. Rather, they are synonyms for a range of alternatives. These include:

Object Name	Synonymous with:
Person	People, Individual
Role	Role, Function, Affiliation, Position, User
Community of Interest	Group, Team, Club
Organisational Unit	Organisation, Agency, Department, Ministry, Company
Location	Address, Place

7.2.2 In order to help understand how the schema has been structured, the following diagram depicts both the broad groupings (objects) into which the attributes have been collected, and also the inter-relationships that exist between these groupings.

7.2.3 The outer ring in this diagram represents the Directory itself. Where an arrow is shown from one object to another in the diagram, this indicates that the first object has an attribute within it that is capable of holding a value that can be used to identify one or more instances of the other object.

7.2.4 The inner circle demonstrates the types of interactions that are likely to take place with the repository that is envisaged to result from the Metadata project. These are shown as dotted lines to indicate that at this stage the final interaction with the Metadata initiative is still unclear and needs to be clarified. A Directory and a metadata repository have quite differing strengths and weaknesses while outwardly sharing a similarity of purpose. It is therefore important to ensure that the boundaries between the two are clearly defined.

7.3 Role, Function, Affiliation, Position, Person and User

7.3.1 For the purposes of the S.E.E. Directory, it is important to distinguish between persons, their functions and activities, and the organisations to which they belong.

7.3.2 Stakeholder discussions have raised points of distinction between "position", "role" and "function". The following diagram demonstrates one possible way of representing the interrelationships between these terms.

7.3.3 A person may be 'affiliated' with an organisation, as opposed to filling a position within it. While this is a looser form of association, an organisation may still wish to be able to identify an affiliated person to the Directory.

7.3.4 Clearly, precision is essential in order to avoid ambiguity. However, from the point of view of a Directory, precision can be counter-productive. The purpose of a Directory is to facilitate the location of information about persons, organisations and other objects when in possession of only a fragment of information about them. In this context, paradoxically, the more precise the grouping of information, the more complex the searching process becomes.

7.3.5 So far as the S.E.E. Directory is concerned, a decision has been made to use the term "role" in a deliberately general fashion to cover all of Position, Role, Function, Affiliation and User.

7.4 Attribute Naming and Values: Standards and Taxonomy

7.4.1 In the schema outlined in Appendix 1, two columns are used to propose possible names for the attributes that make up the objects in the Directory, labelled 'Attribute' and 'LDAP name'.

7.4.2 The 'Attribute' column suggests names that are intended to make sense to people who have no background in data modelling or directories. These names are not intended to be prescriptive, but rather to form the basis for discussion and agreement as to the best terminology to use in order to make the S.E.E. Directory as usable as possible by non-specialist persons.

7.4.3 As well as being understandable by lay persons, the S.E.E. Directory also requires a common, agreed and standard means of locating those same attributes at a system level. For example, when the e-government Portal needs to present information about a person, their role and organisation, then the Portal system needs to know the precise names to use in order to get the information required. This it will do via the S.E.E. Directory LDAP name. In line with the Referential Architecture project, which has strongly endorsed the LDAP Version 3 standard, we have adopted the standard LDAP naming convention for attributes where this is appropriate.

7.4.4 While it is essential to agree on the naming of attributes (at both human and system levels), it is also important to agree on what values certain of those attributes should take. This is a potentially very large undertaking. An obvious example of this is in ensuring that all government agencies are given their correct statutory, common and Maori names. Another is deciding how people with more than one part to their family names are to be consistently handled within the Directory. These are all issues of taxonomy and belong in the domain of an agency which has responsibility for maintaining consistency across government, for example National Archives. This is a matter that the Directory's governing body will need to address.

7.5 Distinguished Name (DN)

7.5.1 An area that needs to be addressed for the PKI project is that of understanding how the DN, or Distinguished Name, is formed for digital certificates [ See the S.E.E. PKI Decision Paper 5 (Identity, Evidence of Identity, and the Registration Process for S.E.E. Keys) for a discussion of the proposed DN format for S.E.E. PKI.] .

7.5.2 The distinguished name or 'DN' is a concept which has acquired considerable currency in the area of directories and which is used to specify how an entry is uniquely identified.

7.5.3 The S.E.E. Directory architecture and schema proposed in this document do not require any particular structure or content for any DN's that might be required. A choice has been made to remain deliberately independent of any particular design approach in this regard. Therefore it is recommended that the PKI project determine the form of the DN that will best meet their specific requirements. The Directory schema is designed so as to be readily able to accommodate any format which is chosen.

7.6 Directory Tree

7.6.1 Directory trees tend to reflect a particular context, need or purpose, and sometimes are also influenced by the demands and approach dictated by a particular vendor's product. Alternatively their structure is sometimes dictated by outside forces, such as a decision to follow the X.500 standard. For these reasons it was decided not to propose a specific tree structure for the S.E.E. Directory especially in view of the S.E.E. principles of vendor neutrality and respect for agency autonomy.

7.6.2 It was also apparent that, once the policy statement, Directory architecture and the attribute and object classes of the schema were all specified, it did not matter which particular tree structure was adopted. For the purpose of transparently synchronising data between locations, tree structure is not relevant.

7.6.3 In terms of the actual tree structure that is eventually adopted for the S.E.E. Directory, however, the following guidelines should be followed in order to help preserve flexibility and openness to future needs:

• Organisational structures should NOT be reproduced in the tree

• The tree structure should be kept as flat as possible

• The tree structure should be kept simple

7.6.4 This approach allows additional Object Classes to be added as and when needed. It also allows other instances of the Directory to be structured or re-structured for particular purposes without having first to disentangle the structure of the S.E.E. Directory itself. Such specific purposes might be for (say) an electronic all-of-government White Pages for use by the public service internally or for a more controlled government-oriented Yellow Pages for the e-government Portal.

7.7 Evolution of the Schema

7.7.1 The Policy framework proposed in this document already allows for the development of appropriate processes for the evolution of the Directory to meet changing needs. It should be particularly noted, however, that a flat and modular structure has deliberately been given to the object classes proposed.

7.7.2 This structure has the advantage of making it very easy to accommodate new object classes as they are added to the S.E.E. Directory. For example, should the need arise to hold information about certain types of electronic government services within the Directory (as distinct from the Metadata project's orientation towards consumers and citizens), then this can occur with little or no change to either the Directory or any of the interfaces that interact with it.

7.7.3 An example of this might be the inclusion of information about the SEE Shared Workspace system or application. Sufficient information could be published in the Directory as a vehicle to enable quick and easy mapping of teams or communities of interest and organisations into aspects of the Shared Workspace services.

[ Previous | Next ]