1.0 Title: Data Dictionary
2.0 Purpose:
2.1 To create a “controlled vocabulary” for a given discipline or recognized area of study which inherits much of its meaning from previous and commonly understood practice but can be tailored for specific applications.
2.2 To provide the basis for future automation of data sheet lookups and automated engineering calculations and configuration management.
3.0 Recommended Usage:
A Data Dictionary (dd) can be created for any recognized subject discipline to define the jargon and “keycodes” which are to be used in specific way for the general case in whatever organization is using the data dictionary. For an individual project with very specialized or confidential terminology a Project Data Dictionary (pdd) can be created by importing the common terminology and modifying the key codes to the project – however – it is recommended that even in that case the standard definitions be used as much as possible and only the unique jargon be defined in the pdd.
Data Dictionaries can be created for all well recognized disciplines (for example Mechanical Engineering <dd:me>, Chemical Engineering <dd:che>, Finance <dd:fin> and Law <dd:leg>) however there needs to be a “common” data dictionary which is defines key codes which can be used for all classes. For example the artifact filenames starting with the well understood mnemonics a) “txt”, b) “dwg”, c) “doc”, and d) “ppt” are defined to be (in sequence) a) an Ascii or Unicode text message b) a drawing – (not necessarily an AutoCAD drawing) c) a computer formatted document (not necessarily MS Word) and d) a presentation – not necessarily in MS PowerPoint format.
In addition the key codes used to label the Data Dictionaries themselves are defined in the common or “default” Data Dictionary – which in the absence of any DD key code precursor indicates that the key code is defined in the common DD. For example ME = Mechanical Engineering is assumed to be the “common” usage. There are debatable cases – for example EE means Electrical Engineering whether or not Electronics Engineers (ElE) because the author of the common DD said so.
4.0 Frequency:
4.1 Organizational Data Dictionaries
There should be a standard Data Dictionary for each organization created once and continuously maintained. As much as possible the organization should license the Data Dictionary from the Domain Authorities for the subject matter area rather than attempt to create new Data Dictionaries for “Mechanical Engineering” for example. Trying to duplicate that sort of effort is both costly and hazardous as the whole idea of Domain Authorities is to develop a consistent and accurate view of the domain subject matter by means of excellence in research and experience.
4.2 Project Data Dictionaries
Projects are free to develop their own Data Dictionaries for specific aspects of the project. Duplicating and (especially) re-defining organizational and external keycodes and nomenclature is not recommended however.
5.0 Reference Documents:
5.1 http://en.wikipedia.org/wiki/Controlled_vocabulary
6.0 Responsibility: Each Special Interest Group (SIG) will define and maintain its own Data Dictionary. In addition there may be Data Dictionaries within individual projects if the project owner feels that is warrented. ince the whole concept of the Data Dictionary is an open source knowledge capture mechanism this is not encouraged.
7.0 Ownership: The SIG data dictionary is owned by the SIG. Project Data Dictionaries are owned by the project owner.
8.0 Level of Effort (costs) Data Dictionaries can be very expensive and time consuming and therefore Project Managers should avoid creating their own except where the project jargon is new or unique – in which case the key codes and cdid’s should be added to the corporate or public data dictionary, unless Intellectual Property or National Security considerations prevent that.
9.0 Risks: If a key code is improperly defined or its derivation is in error – and this results in a loss of life, injury or major property or environmental damage then there is nothing to protect the author and publisher from legal action within the scope of this project. Even if the information is absolutely correct but has been improperly used by untrained or reckless users; the author can expect to be blamed in some jurisdictions. Disclaimers should be built in to advise the end user of the limitations and assumptions of the various calculations and procedures.
10.0 Contents
10.1 Data Dictionary:
10.2 Key Codes:
11.0 Data Typing: The Data Dictionary is intended to be the driving force in the ability of the information system to automate its functionality using key codes. The Data Sheets and Data Dictionary are themselves human readable documents - but the formats and the “relationship” descriptions are intended to be directly translatable into XML and RDF procedures. The CDID section 11’s should follow this pattern and be consistent with the Data Sheets in their reference calculation descriptions.
Future Data Dictionaries can be expected to define their key codes in ways that permit the codes to be machine read and the data from data sheets extracted and generated by procedures which may or may not be part of other data dictionaries.
12.0 File Handling Policy
12.1 Backup:Backup policies must be stated for time of retention.
12.2 Privacy: PIPEDA (Canada), Sorbanes Oxley (USA) and equivalent privacy handling methods must be specified.
12.3 Security
Appendix:
How to create a Data Dictionary for web publication: