iso/iec fdis 11179-1 - jtc1 sc32€¦ · web view0.3 what is new in iso/iec 11179-1 (edition 3)...

© ISO 2012 – All rights reserved

ISO/IEC JTC1 SC32 NnnnnDate: 2012-03-30

ISO/IEC CD 11179-1

ISO/IEC JTC1 SC32 WG2

Secretariat: ANSI

Information technology — Metadata registries (MDR) — Part 1: FrameworkTechnologies de l'information —Registre de métadonnées (RM) — Partie 1: Cadre de reference

Warning

This document is not an ISO International Standard. It is distributed for review and comment. It is subject to change without notice and may not be referred to as an International Standard.

Recipients of this draft are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to provide supporting documentation.

Document type: International standardDocument subtype: Document stage: (20) DraftDocument language: E

ISO/IEC CD 11179-1

Copyright notice

This ISO document is a working draft or committee draft and is copyright-protected by ISO. While the reproduction of working drafts or committee drafts in any form for use by participants in the ISO standards development process is permitted without prior permission from ISO, neither this document nor any extract from it may be reproduced, stored or transmitted in any form for any other purpose without prior written permission from ISO.

Requests for permission to reproduce this document for the purpose of selling it should be addressed as shown below or to ISO’s member body in the country of the requester:

ISO copyright officeCase postale 56CH-1211 Geneva 20Tel. +41 22 749 01 11Fax +41 22 749 09 47E-mail [email protected] www.iso.org

Reproduction for sales purposes may be subject to royalty payments or a licensing agreement.

Violators may be prosecuted.

II © ISO 2012 – All rights reserved

ISO/IEC CD 11179-1

Contents Page

Foreword.................................................................................................................................................. v1 Scope........................................................................................................................................... 12 Normative references................................................................................................................. 13 Terms and definitions................................................................................................................23.1 Objects and concepts................................................................................................................23.2 Concept systems, relations, and relationships........................................................................43.3 Signifiers and designations.......................................................................................................53.4 Data, metadata, information, and interoperability...................................................................63.5 Registration................................................................................................................................. 94 What is Metadata?.................................................................................................................... 104.1 Introduction............................................................................................................................... 104.2 Metadata is Data....................................................................................................................... 114.3 What is Data?............................................................................................................................ 124.4 What is Data Interoperability?.................................................................................................134.5 Metadata Re-use....................................................................................................................... 154.6 Metadata Modeled As Attributes.............................................................................................184.7 Relationship between Metadata and Data..............................................................................184.8 Metadata Computational Models.............................................................................................214.9 Variety Control and Metadata Registries................................................................................214.10 Metadata Governance..............................................................................................................215 The Lifecycle of Metadata........................................................................................................215.1 Overview.................................................................................................................................... 215.2 Creation..................................................................................................................................... 225.3 Observation............................................................................................................................... 225.4 Organization.............................................................................................................................. 225.5 Cataloging................................................................................................................................. 225.6 Storage...................................................................................................................................... 225.7 Retrieval.................................................................................................................................... 235.8 Processing................................................................................................................................ 235.9 Standardization......................................................................................................................... 245.10 Governance............................................................................................................................... 245.11 Retirement................................................................................................................................. 246 Metadata in ISO/IEC 11179.......................................................................................................246.1 Fundamental model of data elements.....................................................................................246.2 Data elements in data management and interchange...........................................................266.3 Fundamental model of value domains....................................................................................276.4 Fundamentals of classification schemes...............................................................................307 Metadata registries................................................................................................................... 327.1 Introduction............................................................................................................................... 327.2 Overview model for an ISO/IEC 11179 MDR...........................................................................327.3 Fundamentals of registration..................................................................................................348 Overview of ISO/IEC 11179, Parts 1- 6....................................................................................358.1 Introduction of Parts................................................................................................................35

© ISO 2012 – All rights reserved III

ISO/IEC CD 11179-1

8.1.1 Part 1.......................................................................................................................................... 358.1.2 Part 2.......................................................................................................................................... 358.1.3 Part 3.......................................................................................................................................... 358.1.4 Part 4.......................................................................................................................................... 368.1.5 Part 5.......................................................................................................................................... 368.1.6 Part 6.......................................................................................................................................... 368.2 Basic Principles for Applying ISO/IEC 11179, Parts 1-6........................................................37Annex A — Terminological Principles for Data..................................................................................38A.1 Principle: The General Nature of Objects (Things)................................................................38A.2 Principle: Concept and Extension...........................................................................................38A.3 Principle: Intension, Characteristics, and Properties............................................................39A.4 Principle: Concept Systems, Relationships, and Relations..................................................41A.4.1 Types of hierarchical relations................................................................................................41A.4.2 Generic relations...................................................................................................................... 41A.4.3 Partitive relations...................................................................................................................... 42A.4.4 Associative relations................................................................................................................42A.4.5 Concept systems...................................................................................................................... 42A.4.6 Developing concept systems..................................................................................................43A.5 Principle: Writing Good Definitions........................................................................................44A.5.1 Delimiting characteristics........................................................................................................44A.5.2 Types of definitions.................................................................................................................. 44A.5.3 Definition writing...................................................................................................................... 45A.5.4 Deficient definitions................................................................................................................. 46A.6 Principle: Signifiers, Designations, Terms, Appellations......................................................47A.6.1 Designations............................................................................................................................. 48A.6.2 Terms......................................................................................................................................... 48A.7 Principle: Value and the Terminological Nature of Data.......................................................48A.8 Principle: Terminological Aspects of Data Interoperability..................................................49A.9 Principle: Good Data Definitions.............................................................................................49Bibliography............................................................................................................................................. 50

IV © ISO 2012 – All rights reserved

ISO/IEC CD 11179-1

Foreword

ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies (ISO member bodies). The work of preparing International Standards is normally carried out through ISO technical committees. Each member body interested in a subject for which a technical committee has been established has the right to be represented on that committee. International organizations, governmental and non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.

International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.

The main task of technical committees is to prepare International Standards. Draft International Standards adopted by the technical committees are circulated to the member bodies for voting. Publication as an International Standard requires approval by at least 75 % of the member bodies casting a vote.

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. ISO shall not be held responsible for identifying any or all such patent rights.

ISO/IEC 11179-1 was prepared by Technical Committee ISO/IEC JTC1, Information Technology, Subcommittee SC32, Data Management and Interchange.

ISO/IEC 11179 consists of the following parts, under the general title Information technology — Metadata registries (MDR):

Part 001: Framework

Part 002: Classification

Part 003: Registry metamodel and basic attributes

Part 004: Formulation of data definitions

Part 005: Naming and identification principles

Part 006: Registration

© ISO 2012 – All rights reserved V

ISO/IEC CD 11179-1

0. Introduction

0.1 Background Information

Metadata is a kind of data that describes one or more objects. Objects can be of any type, such as books (e.g., resource metadata), databases and data itself (e.g., data semantics metadata), documents (e.g., records management metadata), equipment (e.g., device metadata), and data governance itself (e.g., registration metadata). Good metadata practices (consistent observation, consistent meaning, and useful cataloging taxonomies) can provide valuable benefits to the enterprise, such as:

— Better search and discovery of desired objects (e.g., documents, data, services, etc.) and their related objects (e.g., administrative services).

— Automated and semi-automated processing of on-demand data assets, e.g., using data assets in meaningful ways without prior knowledge.

— Better re-use of one's objects (e.g., data assets) via proper cataloging (applying and tagging metadata) and discovery by other users.

0.2 General Description of ISO/IEC 11179The International Standard ISO/IEC 11179 - Metadata registries (MDR), addresses the semantics of data (both terminological and computational), the representation of data, and the registration of the descriptions of that data. It is through these descriptions that an accurate understanding of the semantics and a useful depiction of the data are found.

The purposes of the standard are to promote the following:

Standard description of data

Common understanding of data across organizational elements and between organizations

Re-use and standardization of data over time, space, and applications

Harmonization and standardization of data within an organization and across organizations

Management of the components of data

Re-use of the components of data

ISO/IEC 11179 is six part standard. Each part is devoted to addressing a different aspect of the needs listed above. The parts and a short description follow:

Part 1 – Framework – Contains an overview of the standard and describes the basic concepts

Part 2 – Classification – Describes how to manage a classification scheme in a metadata registry

Part 3 – Registry metamodel and basic attributes – Provides the basic conceptual model, including the basic attributes and relationships, for a metadata registry

Part 4 – Formulation of data definitions – Rules and guidelines for forming quality definitions for data elements and their components

Part 5 – Naming and identification principles – Describes how to form conventions for naming data elements and their components

Part 6 – Registration – Specifies the roles and requirements for the registration process in an ISO/IEC 11179 metadata registry

VI © ISO 2012 – All rights reserved

ISO/IEC CD 11179-1

0.3 What is new in ISO/IEC 11179-1 (edition 3)This third edition of ISO/IEC 11179-1 contains significantly expanded text on metadata. Previous editions focused on a more narrow description; however the broader view is relevant to any application, system, or project concerning metadata. This way, this Part of this international standard now has wide applicability for the understanding, applicability, and use of metadata.

Previously, the term metadata was defined as “data about data”, but metadata are used to describe many kinds of objects, not just data. It is possible to define metadata from this wider view (“descriptive data about an object”) and, as defined, still observe its relevance for describing data. In addition, the new approach provides a means to make the idea of metadata more precise, and this in turn enables the developers of information systems to use metadata more accurately, making the new approach justified.

Metadata exist in some context – the one necessary to describe an object. This means metadata are firstly data; there is no distinction between data and metadata except by the existence of a descriptive relationship to some object. Therefore, a definition of data is given as well. This definition is new and differs from the one in ISO/IEC 2382-1:1993, sub-clause 01.01.02.

The semantics of data, the subject of ISO/IEC 11179, contains both terminological and computational components. Since a description of a datum has to have these components, then a definition of a datum must reflect these facts. So the new definition of a datum is presented in terms of terminology and computation.

The text in the 2nd edition concerned the description of the other five parts is included. An annex contains terminological principles for data.

© ISO 2012 – All rights reserved VII

FINAL DRAFT INTERNATIONAL STANDARD ISO/IEC CD 11179-1

Information technology — Metadata registries (MDR) — Part 1: Framework

1 ScopeISO/IEC 11179-1 – Metadata registries – Part 1: Framework specifies a general description of metadata. It is designed to work in conjunction with any of the other parts of ISO/IEC 11179, it can be used by itself, or it can be used with specifications other than ISO/IEC 11179. It contains a description of each of other the parts of ISO/IEC 11179.

Metadata is defined precisely as "descriptive data about an object". Thus, metadata is a kind of data. Data becomes metadata when the descriptive relationship is revealed between the data (now metadata) and the target object(s). Metadata that is the same for more than one object is metadata for a class of objects, e.g., this metadata would apply to an object-oriented class, a datatype, XML schema, etc., is of particular interest because the class of objects might have shared commonalities in computational models and/or semantics.

Metadata itself is modeled as attributes, which are comprised of:— characteristics

— property values (with respect to the characteristics)

— identifiers (that name the characteristics)

— datatypes (computational description of characteristics-properties)

— codings (symbols used to represent the property values).

Common attributes, e.g., standardized metadata1, affords common understanding of computational models (query, discovery, relationships, etc.) for data across application areas. At a higher level of description, metadata is organized into realms, such as descriptive data about data semantics (one realm), descriptive data about documents and resources (another realm), and descriptive data about ownership, lineage, and custody chain (yet another realm). Typically, each metadata realm has its own standardization and governance structure.2

2 Normative references

The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.

ISO/IEC Guide 2, Standardization and related activities — General vocabulary

1 The sense of agreement is particular to each effort: agreement within a project, among trading partners, nationally, regionally, internationally, or some combination.

2 Multiple realms might share common business processes and administrative organizations.

© ISO 2012 – All rights reserved 1

ISO/IEC CD 11179-1

ISO 704:1999, Terminology work – Principles and methods

ISO 1087-1:2000, Terminology work – Vocabulary – Part 1: Theory and application

ISO/IEC 11179-2 – Metadata registries, Part 2: Classification

ISO/IEC 11179-3 – Metadata registries, Part 3: Registry metamodel and basic attributes

ISO/IEC 11179-4 – Metadata registries, Part 4: Formulation of data definitions

ISO/IEC 11179-5 – Metadata registries, Part 5: Naming and identification principles

ISO/IEC 11179-6 – Metadata registries, Part 6: Registration

ISO/IEC 11404: 2007, Information technology – General purpose datatypes

ISO/IEC 19773: 2011, Information technology – Metadata modules

ISO/IEC 20944-1, Information technology — Metadata registries interoperability and bindings (MDR-IB) —Part 1: Framework, common vocabulary, and common provisions for conformance

3 Terms and definitions

For the purposes of this document, the following terms, abbreviations, and definitions apply. This Clause is organized thematically into four areas:

— objects and concepts

— concept systems, relations, and relationships

— signifiers and designations

— data, metadata, information, and interoperability

3.1 Objects and concepts3.1.1characteristicconcept that plays the role of a determinable in a determining relation [adapted from ISO 704]

NOTE The Oxford English Dictionary definition of "determinable (noun)" is: "That which is capable of being given a more determinate form or of being more precisely specified; spec. (in W. E. Johnson's use) a general term or concept (e.g. color) under which several specific terms or concepts fall (e.g. red, yellow, green)."

3.1.2comprehensive conceptconcept in a partitive relation viewed as the whole [ISO 1087-1]

3.1.3coordinate conceptsubordinate concept having the same nearest superordinate concept and same criterion of subdivision as some other concept in a given concept system [ISO 1087-1]

3.1.4conceptunit of thought differentiated by characteristics [adapted from ISO 704]

2 © ISO 2012 – All rights reserved

ISO/IEC CD 11179-1

3.1.5definitionrepresentation of a concept by a descriptive statement which serves to differentiate it from related concepts [ISO 1087-1]

3.1.6extensiontotality of objects to which a concept corresponds [adapted from ISO 704]

EXAMPLE The concept of "planet" has more than one object in its extension (a general concept) whereas the concept of "Saturn" has exactly one object in its extension (an individual concept).

3.1.7extensional definitiondescription of a concept by enumerating all of its subordinate concepts under one criterion of subdivision [ISO 1087-1]

EXAMPLE 1 The following is an example of an extensional definition for the concept ‘noble gas':

Noble gashelium, neon, argon, krypton, xenon or radon.

3.1.8general conceptconcept whose extension is intended not to have exactly one element [adapted from ISO 704]

3.1.9generic conceptconcept in a generic relation having the narrower intension [ISO 1087-1]

3.1.10individual conceptconcept whose extension is intended to have exactly one element [adapted from ISO 704]

3.1.11intensionset of characteristics which makes up the concept in some context [adapted from ISO 704]

3.1.12intensional definitiondefinition which describes the intension of a concept by stating the superordinate concept and the delimiting characteristics [ISO 1087-1]

EXAMPLE 2 The following is an example of an intensional definition for the concept 'incandescent lamp':

incandescent lampelectric lamp in which a filament is heated by an electric current in such a way that it emits light

3.1.13objectanything perceivable or conceivable [ISO 704]

NOTE Objects may be material (e.g. an engine, a sheet of paper, a diamond), immaterial (e.g. conversion ratio, a project plan) or imagined (e.g. a unicorn, a dragon).


ISO/IEC CD 11179-1

3.1.14partitive conceptconcept in a partitive relation viewed as one of the parts making up the whole [ISO 1087-1]

3.1.15propertyconcept that plays the role of a determinant in a determining relation [adapted from ISO 704]

EXAMPLE 3 The characteristic "[has] mass" is a feature of humans, yet one human has the property "[mass is] 80 Kg" and another human has the property "[mass is] 110 Kg". In this example, the determinable "mass" has a quantifiable determinant (mass measured in Kg). The same determinable could have a different range of determinants, such as a qualitative determinant (thin, fit, obese) or a Boolean determinant (true-false, which would be "true" for all humans).

3.1.16subordinate conceptnarrower conceptconcept which is either a specific concept or a partitive concept [ISO 1087-1]

3.1.17superordinate conceptbroader conceptconcept which is either a generic concept or a comprehensive concept [ISO 1087-1]

3.1.18specific conceptconcept in a generic relation having the broader intension [ISO 1087-1]

3.2 Concept systems, relations, and relationships3.2.1associative relationpragmatic relationrelation between two concepts having a nonhierarchical thematic connection by virtue of experience [ISO 1087-1]

NOTE An associative relation exists between the concepts 'education' and 'teaching', 'baking' and 'oven'.

3.2.2causal relationassociative relation involving cause and its effect [ISO 1087-1]

NOTE A causal relation exists between the concepts 'action' and 'reaction', 'nuclear explosion' and 'fall-out'.

3.2.3concept systemset of concepts and the relationships among the concepts [adapted from ISO 704]

3.2.4hierarchical relationrelation between two concepts which may be either a generic relation or a partitive relation [ISO 1087-1]


ISO/IEC CD 11179-1

3.2.5generic relationgenus-species relationrelation between two concepts where the intension of one of the concepts includes that of the other concept and at least one additional delimiting characteristic [ISO 1087-1]

NOTE A generic relation exists between the concepts 'word' and 'pronoun', 'vehicle' and 'car', 'person' and 'child'.

3.2.6partitive relationpart-whole relationrelation between two concepts where one of the concepts constitutes the whole and the other concept a part of that whole [ISO 1087-1]

NOTE A partitive relation exists between the concepts 'week' and 'day', 'molecule' and 'atom'.

3.2.7relationship systemset of objects and the relationships among them [ISO/IEC 20944-1]

EXAMPLE 4 A concept system is a kind of relationship system (the concepts themselves are treated as objects, which are organized by the relationships) and a database record is a kind of relationship system (in a database record its individual components are treated as objects, which are structured by the relationships among the components of the record).

3.2.8sequential relationassociative relation based on spatial or temporal proximity [ISO 1087-1]

NOTE A sequential relation exists between the concepts 'production' and 'consumption', etc..

3.2.9temporal relationsequential relation involving events in time [ISO 1087-1]

NOTE A temporal relation exists between the concepts 'spring' and 'summer', 'autumn' and 'winter'.

3.3 Signifiers and designations3.3.1designationassociation of a concept with a signifier that designates it [adapted from ISO 704]

3.3.2designation formationprocess of creating a signifier and associating it with its concept(s) [adapted from ISO 704]

3.3.3identifierlabel that is intended to be dereferenced [ISO/IEC 20944-1]

NOTE 1 An identifier is also a reference.

NOTE 2 This definition is consistent with IETF RFC 3986 which describes the Uniform Resource Identifier (URI) syntax and semantics.


ISO/IEC CD 11179-1

3.3.4to dereferenceto access the referenced object (the referent) [ISO/IEC 20944-1]

3.3.5labelreference to an object by a signifier [ISO/IEC 20944-1]

3.3.6locatoridentifier that includes an access method [ISO/IEC 20944-1]

NOTE This definition is consistent with IETF RFC 2396 which describes the Uniform Resource Identifier (URI) syntax and semantics.

3.3.7referentreference, nounobject that is referenced [ISO/IEC 20944-1]

NOTE: In one context, a reference is the opposite of a literal: the literal gives the data at hand, while the reference points to the data, which must be subsequently accessed, retrieved, or written.

EXAMPLE 5 An association created by proximity; a computer memory pointer; a database foreign key.

3.3.8signifiersign, noungeneral concept, whose extension is perceivable objects that are associated with objects [ISO/IEC 20944-1]

NOTE A signifier associated via a designating relationship to an object of the variety "concept" is known as a signifier designating a concept, i.e., a designation.

EXAMPLE 6 The signifier for the Arabic numeral 4 contains the following objects in the extension of the concept:

3.3.9terminologyset of designations belonging to one special language [ISO 704]

EXAMPLE 7 A special language could be a domain of discourse, a subject area, or an application area.

3.4 Data, metadata, information, and interoperability3.4.1characterizing operations (on a datatype)collection of operations on, or yielding, values of the datatype that distinguish this datatype from other datatypes with identical value spaces [ISO/IEC 11404]

EXAMPLE 8 The integers may have characterizing operations Add(), Negate(), Multiply(), Quotient(), and Remainder(), while the rational numbers include additional characterizing operations, such as Reciprocal().


ISO/IEC CD 11179-1

3.4.2data instanceselection of an element of the value space from a datatype [ISO/IEC 20944-1]

NOTE The instantiation of a datatype can be considered "creating data".

3.4.3data interchangedata exchangeevent described by the representation, transmission, reception, storage, and retrieval of data [ISO/IEC 20944-1]

3.4.4data interoperabilityinteroperability concerning the creation, meaning, computation, use, transfer, and exchange of data [ISO/IEC 20944-1]

3.4.5data meaningconcept portion of a datum

NOTE 1 See 3.4.10 datum, Note 1. The concept system and contexts of which the concept belongs to is considered part of the concept potion of a datum and, thus, affect the meaning of a datum.

NOTE 2 Terminological and computational descriptions of a datum are within the concept portion of a datum and, thus, affect the meaning of a datum.

NOTE 3 The signifier portion of the datum is not part of its meaning because alternate signifiers can always be chosen for any datum, yet the meaning is still retained.

3.4.6data repository (as a conformance paradigm)functional unit that stores and retrieves data [ISO/IEC 20944-1]

EXAMPLE 9 A data repository might support services such as search, indexing, storage, retrieval, and security.

3.4.7data terminologyterminology whose concepts are values

3.4.8datatypeset of distinct values, characterized by properties of those values, and by operations on those values [ISO/IEC 11404]

3.4.9datatype generatoroperation on datatypes, as objects distinct from their values, that generates new datatypes [ISO/IEC 11404]

3.4.10datum (pl. data or datums)designation whose concept is a value [ISO/IEC 20944-1]


ISO/IEC CD 11179-1

NOTE 1 A datum is created when its designating relationship comes into existence, such as when an instrument or observer records a datum or a computational device emits a datum. Thus, a datum can be thought of as having three parts: a concept, a signifier, and a designating relationship that associates the concept and the signifier.

NOTE 2 Computational devices, largely, are signifier processors not concept processors. The art of software engineering in data processing involves peeling the concepts from the signifiers, yet retaining them nearby via artful and careful programming, and via explicit metadata.

3.4.11informationgiven context of an object, such as a concept system, that gives it meaning [ISO/IEC 20944-1]

NOTE 1 It is possible to give context using techniques other than concept systems.

NOTE 2 A given context might apply to more than one object, such as a class of objects.

NOTE 3 With respect to data and information, a datum already has meaning: its value (concept). Additional meaning might be provided, such as: revealing one or more concept systems that datums (sic) belong to (e.g., relations and relationships among data); describing the circumstances of the act of designation (e.g., who-what-when-where-why-how the data was created or changed); providing mappings to/from the designations, their signifiers, and/or their values (concepts). Other methods are possible for giving additional meaning.

NOTE 4 It is possible to provide successive contexts of information for data, each revealing more information, the result of each iteration (information) can itself be considered data for the next iteration of revelation, which produce "layers" of information and data. The reverse process is possible, too: each layer of information is stripped of some context that produces data; then the data itself is treated as information and a second iteration of context is stripped from that information to produce data.

NOTE 5 Because of the successive nature of revelation or stripping, it may appear that terms data and information can be used interchangeably, but this is incorrect. Data is characterized by the signifiers, their associations with concepts, and their notions of equality; information is characterized by referencing the context(s) overlaid upon the data; and both might be present. Likewise, because context can always be added or stripped, it is impossible to say that something is purely data (but no corresponding information) or purely information (but no corresponding data).

EXAMPLE 10 One kind of context is defining the symbols used for communication, e.g., an encoding.

EXAMPLE 11 If X is a sequence of bits that represents an encrypted message (the object) whose meaning is merely a sequence of designations whose symbols are zero and one; then the decryption key is an example of context (a mapping) that gives additional meaning to the data to reveal information (i.e., the decoded message).

EXAMPLE 12 The designation "20" is a datum, a kind of object. The context "temperature in degrees Celsius of New York City at 2003-07-19 16:00 UTC" is information about this object.

3.4.12interoperabilitycapability to communicate, execute programs, or transfer data among various functional units in a manner that requires the user to have little or no knowledge of the unique characteristics of those units [ISO/IEC 2382-1]

3.4.13metadatadescriptive data about an object [ISO/IEC 20944-1]

NOTE The descriptive data might equally apply towards more than one object, e.g., a datatype is descriptive data about all its instances.


ISO/IEC CD 11179-1

3.4.14metadata interoperabilityinteroperability concerning the creation, meaning, computation, use, transfer, and exchange of descriptive data [ISO/IEC 20944-1]

3.4.15reify, vto regard or treat (an abstraction) as if it had concrete or material existence

NOTE The descriptive data might equally apply towards more than one object, e.g., a datatype is descriptive data about all its instances.

3.4.16valuevalue conceptconcept with a defined notion of equality to that concept [ISO/IEC 20944-1]

NOTE Although any signifier can designate a value, typically representation systems are used to afford computability among signifiers because digital computers are signifier processors, not concept processors. For example, a decimal positional numeration system (289 = 2×102 + 8×101 + 9×100) is used by hand calculators and a binary position numeration system (10001 = 1×24 + 0×23 + 0×22 + 0×21 + 1×20) is used by modern digital computers — both position numeration systems afford automated arithmetic computation by employing a pre-determined set of rules for processing signifiers (not processing concepts).

EXAMPLE 13 Given the concepts red (defined as "visible light in the range of wavelengths 650 to 700 nanometers") and yellow (defined as "visible light in the range of wavelengths 525 to 570 nanometers"), it is undefined whether red equals yellow and, hence, these concepts by themselves are not values. These concepts can become values once a notion of equality is defined (equality can be defined within the concepts' definition or defined external to the concepts' definition). If the notion of equality is defined as "has visible electromagnetic radiation?", then one can ask whether red equals yellow (true) and whether red equals infrared (false, because infrared is not visible). If the notion of equality is defined as "has overlapping ranges of wavelengths?", then red does not equal yellow (their wavelengths don't overlap) but cornflower equals blue (cornflower is a slice of the blue portion of the visible spectrum). If the notion of equality is defined as "has the same range of wavelengths?", then none of red, yellow, cornflower, or blue are equal to each other.

3.4.17value spaceset of values for a given datatype [ISO/IEC 11404]

3.5 Registration3.5.1objectunit of registration whose structure is unspecified3 [ISO/IEC 19781-1]

3.5.2registerset of tables (paper, electronic, or a combination) containing the assigned designations and the associated information [ISO/IEC 19781-1]

3.5.3registrysystem and its administration that implement one or more registers [ISO/IEC 19781-1]

3 The JTC1 Directives, Annex E Registration Authorities, define object registration.


ISO/IEC CD 11179-1

3.5.4registrationassignment of an unambiguous designation to a registration in a way which makes the assignment available to interested parties [ISO/IEC 19781-1]

3.5.5reclamationde-assignment of designation(s) for a registration and its subsequent de-registration [ISO/IEC 19781-1]

NOTE Reclamation may be initiated by the registrant, the registration authority, or another party, as specified in the registration authority process.

4 What is Metadata?

4.1 Introduction

Much of Clause 4 explains the main concepts of metadata, as grounded in terminology, linguistic, computer science, and information technology disciplines. These fundamental concepts are presented in a bottom-up ordering. It might seem pedantic to worry about these details (e.g., signifier vs. designation, value, number vs. numeral, data vs. information), but a clear understanding of these subtleties is essential for a precise understanding of data. For example, it is easy to avoid the meticulous conceptual or computational descriptions of data, but the use of the corresponding data might be significantly hampered because the subtleties of the data are not understood or worse, they are misunderstood.

EXAMPLE 14 The following is an example4 of ISO/IEC 11179 metadata that describes data semantics:

Registration of CD and DEC for "Textual Description"

1 Conceptual Domain (CD)

CD Context sample_registration_of_ieee_lom

CD Name textual_description

CD Definition Text describing an object.

CD Identifier/Version Number 01.36.04.0066.01.01

3 Data Element Concept (DEC)

DEC Context sample_registration_of_ieee_lom

DEC Name text

DEC Definition Text describing an object.

Object Class text

Object Class Qualifier

Property string

4 Example from ISO/IEC JTC1 SC36 WG4 N0066.


ISO/IEC CD 11179-1

Registration of CD and DEC for "Textual Description"

Property Qualifier

DEC Item Identifier 01.36.04.0066.01.03

5 Other Metadata Attributes

Origin IEEE 1484.12.1-2003

Comment (Not Applicable)

Submitting organization sample_registration_of_ieee_lom

Data Steward ISO/IEC JTC1 SC36 WG4 Data Steward

6 Classification

Keyword learning, education, training

Group standards, content metadata

Object textual_description

Layer of abstraction Conceptual Domain

7 Quality Control

Registration Status Standard

Administrative Status Final

In the example above, the metadata is intended to be a portion of the metadata for a data element. The reason this illustration is a portion of a data element description is that it illustrates that metadata can be registered (in metadata registries) for multiple re-use by multiple data elements, in this case a descriptive string is being reused across several implementations and specifications.

4.2 Metadata is Data

Metadata is descriptive data about objects, e.g., metadata may be descriptive data about other data.

The notion that metadata is "data about data" is incomplete (because metadata can be descriptive data about things other than data, such as museum artefacts and hardcover books) and inaccurate (because all data is about some other data).

EXAMPLE 15 The data from an ammeter that reports a current flow of 3.14 amps is about some other data concerning the number of electrons flowing.

EXAMPLE 16 The profit reported by some business entity is about that business’s gross income, expenses, and the difference between them.


ISO/IEC CD 11179-1

The essential characteristics of metadata include: it is descriptive data, and that it is descriptive about something. For example, if P is data and if PQ represents the descriptive relationship such that P describes Q, then P is metadata about Q. If there is no relationship from P to Q, then P is no longer metadata, i.e., P is merely data, because metadata is always relative to the object of description. Or, stated differently, P only becomes metadata once its descriptive relationship to Q is established.

Thus, it is impossible to determine, independent of context and relationships, that any data are `also metadata. The implications are: (1) because metadata is data, it can be exchanged like other data, but (2) to remain metadata, the exchange must include the associated context and relationships.

4.3 What is Data?

The concepts datum, designation, and value are defined as:5

datum: designation whose concept is a value

designation: association of a concept with a signifier that denotes it

value: concept with a defined notion of equality for it

A designation is a general notion, as there are special kinds depending on the subject field. In terminology, there are terms and appellations. A term is a linguistic designation of a general concept (e.g., planet, president), and an appellation is a linguistic designation of an individual concept (e.g., Mars, George Washington). The subject field of data has its own kind of designation: a datum is a designation whose concept is a value.

Sometimes, when using the idea of designations, people refer to the signifier as the designation, but this is incorrect. There are three basic parts to designations: the concept (which is a construct of the mind6 and can stand on its own), the signifier (which can stand on its own, e.g., a symbol), and the designation (the association of the signifier to the concept, e.g., "this word-symbol-etc X means the concept Y").

Likewise, sometimes when using the idea of values, people refer to the signifier as the value, but this, too, is incorrect: the value refers to the concept portion of the datum and not its signifier. For example, one can easily discuss the notion of the value of seventeen-ness, a number, (a concept) independent of any particular signifier, e.g., a numeral (a kind of signifier used to designate numbers).

The following diagram shows a stack of characteristics that comprise a composite concept for a hypothetical datum:

5 See the full definitions in Clause 3 for additional notes, footnotes, and examples.

6 Concepts exist in our minds. Concept definitions written in natural languages (e.g., prose) and artificial languages (e.g., mathematical equations, chemical equations, logic statements) are used to convey concepts. Good definitions cause people to conjure, effectively, similar concepts in their minds. Common understandings lead to better interoperability.


ISO/IEC CD 11179-1

Figure 1: Characteristic Stack for Derived Concept

The features in red are particular to this datum 17. The generic concept of the number 17 (the top concept defined by the characteristic of "seventeen-ness") is derived and specialized by additional characteristics that produce the derived concept of 17 (the bottom concept). Some of these characteristics are considered "defining", which is essential for interoperability, as per the hypothetical interoperability specification in this example.7 For example, if the precision and accuracy are different or the spatial and temporal extents are missing, the corresponding datum is incompatible with the interoperability specification and cannot be exchange reliably or combined with other data reliably. Some of these characteristics are considered "non-defined", which can be ignored or undefined. In the example in the figure 1 above, whether the measuring instrument is XYZ or PQR is irrelevant for this hypothetical data interchange.

4.4 What is Data Interoperability?

Characteristics (of a concept) and properties (of objects within the concept's extension) are used to create data. Data interoperability can be measured by the following three steps.Step #1: Reformulate data, data elements, datatypes, classes, object classes, etc. according to terminological principles8.

NOTE: This has commonality with data warehouse fact tables, but is not identical.

7 Interoperability is defined by a data exchange specification (technical specification), which might be incorporated into a data exchange agreement (a contractual obligation). Figure X merely depicts artifact s from a hypothetical interoperability scenario — different interoperability scenarios would have different requirements.

8 Terminological principles are described in ISO 704.


ISO/IEC CD 11179-1

Express data as designations with concept relationships. For example, a data element containing the value 17 might be reformulated in a single composite description as "The temperature in degrees Celsius on Roosevelt Island, NY on 9 July 2009 measured instantaneously at 10:00 am with accuracy 0.2 degrees and precision 0.1 degrees with instrument XYZ is 17."

Step #2: Express reformulation as series, lattice, etc. of the derived concepts. (See Figure 2).

Example 17 "The temperature in degrees Celsius on Roosevelt Island, NY on 9 July 2009 measured instantaneously at 10:00 am with accuracy 0.2 degrees and precision 0.1 degrees with instrument XYZ is 17."

Figure 2: Reformulation as Series, Lattice, etc., of the Derived Concepts

Step #3: Determine which characteristics are essential, which is the same as the terminological process for developing good definitions, and partition into essential and inessential characteristics.

Data interoperability is dependent upon essential characteristics.

Example 18 "The temperature in degrees Celsius on Roosevelt Island, NY on 9 July 2009 measured instantaneously at 10:00 am with accuracy 0.2 degrees and precision 0.1 degrees with instrument XYZ is 17" describes:

a kind of 17 — quantity is essential

a kind of temperature — dimension is essential


ISO/IEC CD 11179-1

a kind of temporal extent — interval dimension is essential

a kind of spatial extent — interval dimension is essential

a kind of precision — computation limitation is essential

a kind of accuracy — data quality criterion is essential

a kind of measuring instrument — instrument is inessential

a kind of measuring technique — technique is inessential

Thus, the interoperability specification concerns: number, temperature, temporal-spatial extent, precision, and accuracy, but not measuring instrument, or measuring technique. Likewise, another interoperability specification might include measuring instrument and measuring technique, but not spatial extent. By using well-defined characteristics and well-defined derivations, the metadata affords a well-defined computation model for examining data interoperability. Characteristics may be structured linearly, hierarchically, or in some other grouping. Typically, the organization of characteristics is optimized for re-use.

By understanding the meaning of actual data (collectively or in individual datums), there can be agreement upon interoperability.

Datums have a terminological portion (concept derivation) and a computational portion (e.g., characterizing operations). The following diagram shows the terminological portion as a concept derivation tree (see figure 2 above for an actual example). The computational portion of the datum's description includes: datatype properties (e.g., equality, ordered-ness, bounded-ness, arithmetic, etc.), characterizing operations (all datums include the operation "is_equal()"; arithmetic datums include the operation "add()" and "multiply()"; etc.), and value spaces (e.g., the boolean datatype includes the values true and false in its value space).

4.5 Metadata Re-use


ISO/IEC CD 11179-1

Figure 3: Computational Description

Through the software engineering process, portions of datums may be developed for re-use in multiple datums. For example, architectural analysis tools, programming languages, and database systems support a variety of mechanisms (classes, inheritance, typedefs, datatypes, records/structures, etc.) for creating bundles of terminological and computational features that can be reused to create datums.


ISO/IEC CD 11179-1

Figure 4: Grouping Characteristics

The above figure 4 shows both linear and non-linear concept derivations. The non-linear approach affords re-use of groups of characteristics.

Figure 5: Linear vs. Non-Linear Concept Derivations


A

B

C

D

E

F

G

H

I

composite notion

A

B

C

D

E

F

composite notion

G

H

I

Grouping of characteristicscan afford reuse for derivationfor other composite notions

Linear Concept Derivation Non-Linear, Grouped Concept Derivation

ISO/IEC CD 11179-1

The diagram in figure 5 above shows the best practice progressing descriptions from left to right: (1) single composite descriptions, to (2) partially factored descriptions, to (3) fully factored descriptions, to (4) fully factored and re-usable descriptions.

4.6 Metadata Modeled As Attributes

Metadata is modeled as attributes. Each attribute has the same features as an element of an aggregate datatype: a characteristic, a characteristic name, a set of property values, a set of property value meanings, and a representation for each property value.

The following are essential to describing data, data structures, and their meaning: The characteristics and their definitions (how something is being observed or measured)

The names/identifiers of the characteristics (used for navigating and accessing the data itself)

The property values associated with those characteristics (e.g., is temperature, a characteristic, measured in degrees Celsius or in categories Cold, Cool, Warm, and Hot?)

The meanings of the property values (e.g., in marital status, does Single mean Presently Not Married, Never Married, or something else?)

The data terminology for representing the property values (do the concepts male and female have the signifiers "M" and "F", "1" and "2", or something else?)

The following diagram shows the tuple of metadata: identifier, characteristic (name), property (value).

4.7 Relationship between Metadata and Data

As stated above, metadata is descriptive data about an object. For objects that are datums, i.e., metadata about data, there is a deeper understanding. In figure 1 above, the terminological portion of a datum is shown as a concept derivation tree. For several datums (e.g., temperature is 17, 18, and 19 degrees), significant portions of the concept derivation tree (and the computational description) are common among the datums. The fact that these concepts are shared among the datums is a portion of their metadata. However, the shared concepts themselves (see degrees Celsius, 2007-07-09 10:00, Roosevelt Island, NY, 0.1, 0.2 in the right column in figure 6 below) are not data per se, but must be reified into data that are known as descriptions, i.e., the strings ("degrees Celsius", "Roosevelt Island, NY"), dates ("2007-07-09 10:00"), and quantities ("0.1", "0.2") in the left column in figure 6 below are descriptions that themselves are data, i.e. reified versions of the concepts degree Celsius, etc..9

9 Reifying something is turning the object into data, i.e., to regard or treat (an abstraction) as if it had concrete or material existence. For example, concepts can be reified as textual descriptions, and relationships can be reified as a series of pointers or URIs.


Identifier characteristic property

ISO/IEC CD 11179-1

Figure 6: Turning Data into Metadata

In the above diagram, the left column is descriptive data (as an incomplete datum) that can describe multiple datums. 10 The description of data element, data element instance, or a database column are examples of common uses of metadata.

Metadata can describe other aspects of data, such as the business processes involved in the creation of data (e.g., a registration process for data element descriptions in a metadata registry; a business process that describes the quality of data) or the use of data (e.g., metadata support descriptive data about master data management or about authoritative data).

Metadata registries can store the explicit or implicit metadata that is created at various stages of development or use of data: at architecture time, at design time, at run time, within data exchange agreements, and so on (see figure 7).

10 This is an illustration of one common re-use strategy.


17 (seventeen-ness)

measuring instrument:XYZ

measuring technique:instantaneous

derived concept “17”from above factors

quantity: temperature

units of measure:degrees Celsius

temporal extent:2007-07-09 10:00

spatial extent:Roosevelt Island, NY

precision: 0.1

accuracy: 0.2

Metadata (Descriptive Data) asReified Concepts (turned into data)

Original ConceptsFrom Datum

MetadataAttributes

quantity:“temperature”

units of measure:“degrees Celsius”

temporal extent:“2007-07-09 10:00”

spatial extent:“Roosevelt Island, NY”

precision: “0.1”

accuracy: “0.2”

ISO/IEC CD 11179-1

Figure 7: Ways Metadata Can Be Created

The "triaging" process (as guided by business and engineering goals) moves the agreement of portions of the description to different development phases. For example, the units of measure is agreed upon in a data exchange agreement (e.g., not in programming code), the contextual attributes are stored in adjacent database table columns (e.g., treated themselves as data from the perspective of the database and its programming code), and the precision and accuracy are stored in a metadata registry (e.g., they were implicit in the original system implementation design and not recorded anywhere).

The following diagram shows how additional features are added over time.

Figure 8: Triage


17 (seventeen-ness)





precision: 0.1

accuracy: 0.2



the composite notionof “17” in database

Metadata

Interoperability Scenario #1

EssentialData Factors

(characteristics)

InessentialData Factors

(characteristics)

ArchitectureArtifacts

Datatypes

Adjacent Columns

MetadataRegistry

Data Exchange

Agreements

Triage

17 (seventeen-ness)





precision: 0.1

accuracy: 0.2



the composite notionof “17” in database

Metadata

Interoperability Scenario #1

EssentialData Factors

(characteristics)

InessentialData Factors

(characteristics)

ArchitectureArtifacts

Datatypes

Adjacent Columns

MetadataRegistry

Data Exchange

Agreements

Triage

New!

ISO/IEC CD 11179-1

The figure 8 shows that the factors that comprise the meaning of one or more datums can be "triaged" anywhere, i.e., the choice of where these factors are incorporated is arbitrary (not pre-defined) and they are incorporated as business, information, and technology needs dictate.

4.8 Metadata Computational Models

The following are the main computational models when using metadata:— Search/Query: In this model, metadata is treated as data (each attribute is data) and normal data query

operations apply. For example, "find all DOCUMENTS [the objects whose metadata to search] whose TITLE [an identifier that names a characteristic] is GONE WITH THE WIND [the property to search for]".

— Typing and Navigation: In this model, data must be traversed (navigation) and various kinds of data need to be processed according to their needs (typing).

— Association and Introspection: In this model, the connection between the metadata and its object(s) need to be discovered and/or an object needs to point to its metadata.

4.9 Variety Control and Metadata Registries

Variety control is an important element of standardization, such as the standardization of data:

variety control: selection of the optimum number of sizes or types of products, processes or services to meet prevailing needs;

NOTE — Variety control is usually concerned with variety reduction.

Normally, the variety control of data standards is:

variety control = 1: There is only one way to conform to the standard (i.e., only one class of implementations)

or

variety control = 2: There are two ways to conform. One way is "strictly conforming", where no extensions to the data are permitted. Another way is "conforming", where extensions are permitted, but there is no standard meaning of these extensions.

In certain areas of data standardization, it is impossible to achieve this degree of uniformity of data, so the variety control is a much larger number. In these cases, metadata is used to describe the different classes of implementations and their features (e.g., vendor-, user-, and institution-specific data elements in a database) and a metadata registry provides a centralized source of the metadata.NOTE: In this context, variety control is associated with the data exchange standardization process itself, not with the data and not with data quality

4.10 Metadata Governance

Metadata itself is an area of data governance: metadata is a kind of data, so its "data elements", i.e., attributes, need standardization (identifiers, characteristics, property value space, property value meanings, and symbols11 for communication).

11 Symbols for communication are a kind of data terminology (which is governed). Multiple levels of symbology might be used, such as "Divorced" used as element of a data terminology on marital status, which itself is represented by the letters "D", "i", "v", etc. by elements from a different data terminology on character sets, which themselves are represented by the binary codes 01000100, 01101001, etc. as elements from yet another data terminology on ASCII, which is stored as varying magnetic fluxes on a disk drive platter ... and so on.


ISO/IEC CD 11179-1

5 The Lifecycle of Metadata

5.1 Overview

Metadata, like data, is created, processed, stored, and communicated. The lifecycle of metadata has common features, not all of which are shared by general data. There are key stages in the metadata lifecycle — these stages do not necessarily imply a particular business, information, or technology process.

5.2 Creation

Metadata is created when a descriptive relationship is revealed between a datum (now to become metadata) and an object (the datum describes the object). Typically, descriptive relationships aren't created accidentally, but are created deliberately through a business, information, or technology processes. In other words, it is rare that metadata is created free-form without any guidance or constraints of what can/should be recorded.

The following are illustrations of when metadata is created:— Tagging objects with descriptive data, such as: entering keywords, names/titles, owners/authors, descriptions,

contextual information, etc. into a record that is embedded within, adjacent to, or associated with a target object.

— Existing data might be revealed as having a descriptive relationship with an object (in which case the data can be viewed as metadata). For example, a human has the following data associated with him: he weighs 200 pounds; he is carrying two pieces of equipment, X and Y, that have weights 5 pounds and 10 pounds respectively. Weight is a descriptive feature, so "200 pounds" is metadata about an individual human, the human is carrying X and Y (merely data because X and Y have an associative or partitive relation with the individual human), and "5 pounds" and "10 pounds" are metadata for X and Y (but not for the human). Furthermore, if a human flies on an airplane and one considers "passenger weight" (which includes things they carry on their person), then further descriptive relationships are revealed between the human-as-passenger and the items he is carrying.

— Metadata can be created by automated means, such as data roll-ups and summary data.

For the purposes of increased interoperability, one should reference the appropriate data exchange agreements, standards, and specifications when creating metadata.

5.3 Observation

Like much data, metadata is created as the result of some observation process, typically performed by humans, instruments, or computers. Observations range from the objective (e.g., counting the number of bytes in a file) to the subjective (the degree of interest in certain subject material).

Metadata, as descriptive data, needs to properly describe the object(s) it references. Thus, observations rendered as descriptive data need the same degree of attention as observations rendered as data. For example, as an instance of data, the date of registration of some metadata is no different than the recording date for a data sample, i.e., they are both dates concerning observations regarding some kind of event, although the degree of accuracy, degree of precision, measurement technique, etc. might differ.

5.4 Organization

Metadata, as descriptive data, is organized along structures that are required (e.g., for conforming to standards, specifications, and policies) and structures that afford re-use (e.g., stored a portion of shared descriptive data separate from the other descriptive data that references it).

5.5 Cataloging

Cataloging is essentially a librarian's effort: inspecting and observing objects (data, books, records, etc.) and recording the descriptive data in a metadata repository.12 The reason why most book libraries are useful to their patrons is that they use common taxonomies, cataloging processes, and common search and discovery techniques. Imagine if the librarians in New York City used different techniques than those in Los Angeles? Unfortunately, much technical metadata suffers from these kinds of inconsistencies. Careful research and studies along with ongoing process review are required to achieve uniformity (which typically takes many years to achieve).

12 A card catalog system is an example of a metadata repository. The domain naming system (DNS) servers of the internet are another example of metadata repositories.


ISO/IEC CD 11179-1

5.6 Storage

The storage of metadata can vary, as needed, across implementations and even within a single implementation — no single strategy is optimal for all circumstances. Metadata might be embedded in the object (e.g., inside the object, via introspection of the object), adjacent to the object (e.g., in adjacent columns in a table, in an XML header), associated with the object (e.g., referenced by the object, associated by a URI reference), assumed by the object (e.g., implied by data exchange agreements, implied by programming conventions), and so on. In some cases, a single copy of metadata is intended to describe multiple objects — this singular copy is necessary because if the metadata changes for one object, it changes for all of the objects. In other cases, multiple copies of metadata are used, such as one metadata record for each object, even though the metadata records contain the same descriptive data — individual copies are necessary because changes in description for one object don't affect other objects.

When metadata is embedded, it is typically stored within the technology of the implementation, e.g., the use of "introspection" is a Java-technology for Java objects.

When metadata is associated with objects, it is typically stored in a repository. Centralized metadata repositories typically use databases; in some cases, individual files are used for metadata records.

When metadata is adjacent to the target object, it typically makes use of the technology of the container, e.g., URIs and XML schemas for XML records; and additional columns (timestamp, geo locator) in database tables.

When metadata is assumed, it implied and might not be immediately visible. For example, for temperature data, the Units of Measure might be implied in an external data exchange agreement (a contract among parties) that is not readily visible while inspecting the data. As another example, data might stored and computed with two decimal places of precision, but this would not be visible in the data that was stored in IEEE 64-bit floating point format and would only be known be inspecting the programming code that processed the data.

5.7 Retrieval

Metadata can and should be accessed similar to data. Creating separate access systems for data and metadata are unhelpful because it is unclear whether or not data is also metadata, and these distinctions might be unknowable at design-time or run-time.

However, metadata access fits a profile that is different from typical data access. Much data access involves retrieving swaths of data (files, segments, tables, and streams) and the data is accessed, typically, in two modes; random access and sequential access. Metadata access is less likely to be sequential access; in fact, metadata access is likely to cross database systems and administrative realms as relationships are understood and global common descriptions are accessed (i.e., not via sequential data access paradigms). Because metadata inherently involves contexts and relationships, metadata access involves the reification13 and navigation of these context and relationships. While this kind of access is easily understood and implemented from a programming perspective, the broader access requires more consideration of security models, such as: How does a program gain access to the various kinds of metadata without hundreds of pop-up windows pestering the user for additional access credentials? These kinds of problems need to be addressed, especially in anticipation of The Use-Case of the Unanticipated Users14.

5.8 Processing

Much metadata processing involves supporting search-discovery requests, e.g., Is this the sought after item, based upon its metadata and the search query? This kind of processing involved various kinds of comparisons, e.g., numeric ranges, code set subsets, and full-text pattern matching. Without a comprehensive set of query techniques, search methods might be hampered because the desired item might not be found or too many items might be found.

Implementations should be cognizant of scaling issues: what happens if millions of objects need to be searched? What happens if millions of objects match the search? Flow-control mechanisms need to be incorporated to support large scalability. Likewise, search scaling solutions (parallelization, federation, etc.) should be addressed for large-scale solutions.

13 Reification is to transform into data, e.g., a relationship between datums is transformed into data itself.

14 For example, how will new users and systems access the metadata and interpret it and interoperate with it while achieving the desired level of success?


ISO/IEC CD 11179-1

5.9 Standardization

Metadata standardization involves standardizing the descriptive data itself: characteristics, naming those characteristics, property values of those characteristics, the meaning of those values, and the selection of signifiers (e.g., numbers, strings, code sets) to represent those values.

Standardization can occur at any level; project, community of practice, agency, national, regional, or international.

5.10 Governance

Governance is applied to business (non-technical) processes involved in metadata standardization. On a national level, the accredited standards development organizations (e.g., INCITS, IEEE, ASTM) provide standardization. At an international level, ISO, IEC, ITU, IANA provide standardization processes. Via consortia, organizations such as W3C and OMG provide standardization processes. Any level may be used to get the desired result (e.g., national standardization will produce national standards for a single country; international standardization will produce world-wide standards),

5.11 Retirement

Typically, once a particular kind of metadata is standardized, it takes a long while to retire it. The following are common reasons for retiring the use of a particular kind of metadata:

— The metadata is no longer in use (e.g., it is inadequate, it is prohibited by law or policy).

— The metadata is no longer economically feasible. The act of describing and cataloging objects consumes resources (typically financial and human resources). These kinds of costs should be considered before implementing and deploying metadata systems.

— The metadata no longer affords good computational benefits. For example, when searching for a particular item, search queries produce millions of results that offer little help in discovering items that are desired.

— The practice of cataloging metadata produces inconsistent results. For example, if there is a catalog of tests for students with the metadata attribute Difficulty (Easy, Medium, Hard) associated with each test, yet catalogers (those entering metadata into a repository) evenly choose Easy, Medium, and Hard for similar kinds of tests, then the Difficulty attribute has little value because it does not help distinguish among tests.

6 Metadata in ISO/IEC 11179

6.1 Fundamental model of data elements

Figure 9 illustrates the ideas conveyed in this sub-clause. The figure 9 itself is not normative, but it is used to illustrate the basic ideas.

For the purposes of ISO/IEC 11179, a data element is composed of two parts:

Data element concept – A DEC is concept that can be represented in the form of a data element, described independently of any particular representation.

Representation – The representation is composed of a value domain, datatype, units of measure (if necessary), and representation class (optionally).

From a data modeling perspective and for the purposes of ISO/IEC 11179, a data element concept may be composed of two parts:

The object class is a set of ideas, abstractions, or things in the real world that can be identified with explicit boundaries and meaning and whose properties and behavior follow the same rules

The property is a characteristic common to all members of an object class


ISO/IEC CD 11179-1

Object classes are the things for which we wish to collect and store data. They are concepts, and they correspond to the notions embodied in classes in object-oriented models and entities in entity-relationship models. Examples are cars, persons, households, employees, and orders. Properties are what humans use to distinguish or describe objects. They are characteristics, not necessarily essential ones, of the object class and form its intension. They are also concepts, and they correspond to the notions embodied in attributes (without associated datatypes) in object-oriented or entity-relationship models. Examples of properties are color, model, sex, age, income, address, or price.

An object class may be a general concept. This happens when the collection of objects corresponding to the object class is intended to have different than exactly one member. The examples in the previous paragraph are of this type. Record level data are described this way. On the other hand, an object class may be an individual concept. This happens when the set of objects corresponding to the object class has exactly one member. Examples are concepts corresponding to single objects, such as "the set of persons in the US" or "the set of service sector establishments in Australia". Aggregate data are described this way. Examples of properties are average income or total earnings.

It is important to distinguish an actual object class or property from its name. This is the distinction between concepts and their designations. Object classes and properties are concepts; their names are designations. Complications arise because people convey concepts through words (designations), and it is easy to confuse a concept with the designation used to represent it. For example, most people will read the word income and be certain they have unambiguously interpreted it. But, the designation income may not convey the same concept to all readers, and, more importantly, each instance of income may not designate the same concept.

Not all ideas are simply expressed in a natural language, either. For example, "women between the ages of 15 and 45 who have had at least stays one live birth in the last 12 months" is a valid object class not easily named in English. Some ideas may be more easily expressed in one language than in another. The German word Götterdämmerung has no simple English equivalent.

A data element is produced when a representation is associated with a data element concept. The representation describes the form of the data, including a value domain, datatype, representation class (optionally), and, if necessary, a unit of measure. Value domains are sets of permissible values for data elements. For example, the data element representing annual household income may have the set of non-negative integers (with units of dollars) as a set of valid values. This is its value domain.

A data element concept may be associated with different value domains as needed to form conceptually similar data elements. There are many ways to represent similar facts about the world, but the concept for which the facts are examples is the same. Take the DEC country of person's birth as an example. ISO 3166 – Country Codes contains seven different representations for countries of the world. Each one of these seven representations contains a set of values that may be used in the value domain associated with the DEC. Each one of the seven associations is a data element. For each representation of the data, the permissible values, the datatype, the representation class, and possibly the units of measure, are altered.

See ISO/IEC 20943-1:2002 – Procedures for achieving metadata registry content consistency – Part 1: Data elements for details about the registration and management of descriptions of data elements.


ISO/IEC CD 11179-1

Footnote – This figure is for informational purposes only. It is not normative.

6.2 Data elements in data management and interchange

Figure 10 provides a simplified picture to illustrate those situations in which data elements lie. Data elements appear in databases, files, and transaction sets. Data elements are the fundamental units of data an organization manages, therefore they must be part of the design of databases and files within the organization and all transaction sets the organization builds to communicate data to other organizations.

Within the organization, databases or files are composed of records, segments, tuples, etc., which are composed of data elements. The data elements themselves contain various kinds of data that include characters, images, sound, etc.

When the organization needs to transfer data to another organization, data elements are the fundamental units that make up the transaction sets. Transactions occur primarily between databases or files, but the structure (i.e. the records or tuples) of the files and databases don't have to be the same across organizations. So, the common unit for transferring information (data plus understanding) is the data element.


Figure 9: Fundamental model for data elements

DATA ELEMENT CONCEPT DATA ELEMENT

(1:1)(1:N)

(1:N)

Property

Object Class

(1:1)

(1:N)

Property

Representation

(1:1)

Object Class

ISO/IEC CD 11179-1


6.3 Fundamental model of value domains

Figure 11 illustrates the ideas conveyed in this sub-clause. The figure 11 itself is not normative, but it is used to illustrate the basic ideas.

A value domain is a set of permissible values. A permissible value is a combination of some value and the meaning for that value. The associated meaning is called the value meaning. A value domain is the set of valid values for one or more data elements. It is used for validation of data in information systems and in data exchange. It is also an integral part of the metadata needed to describe a data element. In particular, a value domain is a guide to the content, form, and structure of the data represented by a data element.

Value domains come in two (non-exclusive) sub-types:

Enumerated value domain – A value domain specified as a list of permissible values (values and their meanings)


Figure 10: Data elements and other data concepts

ISO/IEC CD 11179-1

Non-enumerated value domain – A value domain specified by a description

An enumerated value domain contains a list of all its values and their associated meanings. Each value and meaning pair is called a permissible value. The meaning for each value is called the value meaning.

A non-enumerated value domain is specified by a description. The non-enumerated value domain description describes precisely which permissible values belong and which do not belong to the value domain. An example of a description is the phrase "Every real number greater than 0 and less than 1".

Each value domain is a member of the extension of a concept, called the conceptual domain. A conceptual domain is a set of value meanings. The intension of a conceptual domain is its value meanings. Many value domains may be in the extension of the same conceptual domain, but a value domain is associated with one conceptual domain. Conceptual domains may have relationships with other conceptual domains, so it is possible to create a concept system of conceptual domains. Value domains may have relationships with other value domains, which provide the framework to capture the structure of sets of related value domains and their associated concepts.

Conceptual domains, too, come in two (non-exclusive) sub-types:

Enumerated conceptual domain – A conceptual domain specified as a list of value meanings

Non-enumerated conceptual domain – A conceptual domain specified by a description

The value meanings for an enumerated conceptual domain are listed explicitly. This conceptual domain type corresponds to the enumerated type for value domains. The value meanings for a non-enumerated conceptual domain are expressed using a rule, called a non-enumerated conceptual domain description. Thus, the value meanings are listed implicitly. This rule describes the meaning of permissible values in a non-enumerated value domain. This conceptual domain type corresponds to the non-enumerated type for value domains. See ISO/IEC DTR 20943-3 – Procedures for achieving metadata registry content consistency – Part 3: Value domains for detailed examples.

A unit of measure is sometimes required to describe data. If temperature readings are recorded in a database, then the temperature scale (e.g., Fahrenheit or Celsius) is necessary to understand the meaning of the values. Another example is the mass of rocks found on Mars, measured in grams. However, units of measure are not limited to physical quantities, as currencies (e.g., US dollars, Lire, British pounds) and other socio-economic measures are units of measure, too.

Some units of measure are equivalent to each other in the following sense: Any quantity in one unit of measure can be transformed to the same quantity in another unit of measure. All equivalent units of measure are said to have the same dimensionality. For example, currencies all have the same dimensionality. Measures of speed, such as miles per hour or meters per second, have the same dimensionality. Two units of measure that are often erroneously seen as having the same dimensionality are pounds (as in weight) and grams. Pounds is a measure of force, and grams is a measure of mass.

A unit of measure is associated with a value domain, and the dimensionality is associated with the conceptual domain.

Some value domains contain very similar values from one domain to another. Either the values themselves are similar or the meanings of the values are the same. When these similarities occur, the value domains may be in the extension of one conceptual domain. The following examples illustrate this and the other ideas in this sub-clause:

EXAMPLE 19 – Similar non-enumerated value domains

Conceptual domain name: Probabilities


ISO/IEC CD 11179-1

Conceptual domain definition: Real numbers greater than 0 and less than 1.

-----------------------------

Value domain name (1): Probabilities – 2 significant digits

Value domain description: All real numbers greater than 0 and less than 1 represented with 2-digit precision.

Unit of measure precision: 2 digits to the right of the decimal point

-----------------------------

Value domain name (2): Probabilities – 5 significant digits

Value domain description: All real numbers greater than 0 and less than 1 represented with 5-digit precision.

Unit of measure precision: 5 digits to the right of the decimal point

EXAMPLE 20 – Similar enumerated value domains

Conceptual domain name: Countries of the world

Conceptual domain definition: Lists of current countries of the world represented as names or codes.

-----------------------------

Value domain name (1): Country codes – 2 character alpha

Permissible values:

<AF, The primary geopolitical entity known as "Democratic Republic of Afghanistan">

<AL, The primary geopolitical entity known as "People's Socialist Republic of Albania">

. . .

<ZW, The primary geopolitical entity known as "Republic of Zimbabwe">

-----------------------------

Value domain name (2): Country codes – 3 character alpha

Permissible values:

<AFG, The primary geopolitical entity known as "Democratic Republic of Afghanistan">

<ALB, The primary geopolitical entity known as "People's Socialist Republic of Albania">

. . .

<ZWE, The primary geopolitical entity known as "Republic of Zimbabwe">


ISO/IEC CD 11179-1

Every value domain represents two kinds of concepts: data element concept (indirectly) and conceptual domain (directly). The Data Element Concept is the concept associated with a data element. The value domain is the representation for the data element, and, therefore, indirectly represents the data element concept, too. However, the value domain is directly associated with a conceptual domain, so represents that concept, independent of any data element.

See ISO/IEC DTR 20943-3 – Procedures for achieving metadata registry content consistency – Part 3: Value domains for detailed examples about the registration and management of value domains.


6.4 Fundamentals of classification schemes

For the purposes of ISO/IEC 11179, a classification scheme is a concept system intended to classify objects. It is organized in some specified structure, limited in content by a scope, and designed for assigning objects to concepts defined within it. Concepts are assigned to an object, and this process is called classification. The relationships linking concepts in the concept system link objects that the related concepts classify. In general, any concept system is a classification scheme if it is used for classifying objects.

The content scope of the classification scheme circumscribes the subject matter area covered by the classification scheme. The scope of the classification scheme is the broadest concept contained in the concept system of the scheme. It determines, theoretically, whether an object can be classified within that scheme or not.


Figure 11: Fundamental model for value domains

CONCEPTUALDOMAIN

(1:N)

(1:N) (1:N)

VALUE DOMAIN

ENUMERATEDVALUE DOMAIN

NON-ENUMERATEDVALUE DOMAIN

VALUEDOMAIN

CONCEPTUALDOMAIN

VALUEMEANING

PERMISSIBLEVALUES VALUE DOMAIN(1:N) (1:1) (N:1)

Non-exclusive sub-types

CONCEPTUALDOMAIN

ENUMERATEDCONCEPTUAL

DOMAIN

NON-ENUMERATEDCONCEPTUAL

DOMAIN

Non-exclusive sub-types

ISO/IEC CD 11179-1

Concept systems, and classification schemes in particular, can be structured in many ways. The structure defines the types of relationships that may exist between concepts, and each classification scheme can be used for the purpose of linking concepts to objects. In a particular classification scheme, the linked concepts together with the other concepts related to the linked concept in the scheme provide a conceptual framework in which to understand the meaning of the object. The framework is limited by the scope of the classification scheme.

A concept system may be represented by a terminological system. The designations are used to represent each of the concepts in the system and are used as key words linked to objects for searching, indexing, or other purposes.

A special kind of concept system is a relationship system. There, the concepts are relationship types. A relationship type has N arguments, and it is called an n-ary relationship type. The statement "a set of N objects is classified by an n-ary relationship type" means that the N objects have a relationship among them of the given relationship type.


ISO/IEC CD 11179-1

7 Metadata registries

7.1 Introduction

Metadata is also data, so metadata may be stored in a database. A database of metadata that supports the functionality of registration is a metadata registry (MDR). A conceptual model of an MDR for describing data is provided in ISO/IEC 11179-3. The requirements and procedures for the ISO/IEC 11179 aspects of registration are described in ISO/IEC 11179-6. For actual metadata registries, there may be additional requirements and procedures for registration, which are outside the scope of this International Standard. Rules and guidelines for providing good definitions and developing naming conventions are described in ISO/IEC 11179-4 and ISO/IEC 11179-5, respectively. The role of classification is described in ISO/IEC 11179-2. Recommendations and practices for registering data elements are described in ISO/IEC TR 20943-1. Recommendations and practices for registering value domains are described in ISO/IEC TR 20943-3.

An MDR contains metadata describing data constructs. The attributes for describing a particular data construct (e.g., data elements) are known, collectively, as a metadata object. When the attributes are instantiated with the description of a particular data construct, they are known as a metadata item. Registering the metadata item (i.e., entering the metadata into the MDR) makes it a registry item. If the registry item is also subject to administration (as in the case of a data element), it is called an administered item.

NOTE In common parlance, registering a metadata item describing a data construct is known as registering that data construct. Actually, the data construct is not stored in the MDR, its description is. This is analogous to the registries maintained by governments to keep track of motor vehicles. A description of each motor vehicle is entered in the registry, but not the vehicle itself. However, people say they have registered their motor vehicles, not the descriptions.

7.2 Overview model for an ISO/IEC 11179 MDR

The conceptual model for an ISO/IEC 11179 MDR contains two main parts: the conceptual level and the representational (or syntactical) level. The conceptual level contains the classes for the data element concept and conceptual domain. Both classes represent concepts. The representational level contains the classes for data element and value domain. Both classes represent containers for data values.

Clause 6 contains descriptions of each of the classes represented in Figure 12.


ISO/IEC CD 11179-1

Figure 12 pictorially represents several fundamental facts about the four classes:

A data element is an association of a data element concept and a representation (primarily a value domain)

Many data elements may share the same data element concept, which means a DEC may be represented in many different ways

Data elements may share the same representation, which means that a value domain can be reused in other data elements

Value domains do not have to be related to a data element and may be managed independently

Value domains that share all the value meanings of their permissible values are conceptually equivalent, so share the same conceptual domain

Value domains that share some of the value meanings of their permissible values are conceptually related, so share the same conceptual domain in the concept system of conceptual domains that contain their respective conceptual domains

Many value domains can share the same conceptual domain

A data element concept is related to a single conceptual domain, so all the data elements sharing the same data element concept share conceptually related representations

Many other facts are not illustrated in Figure 12, but some of these are described in Clause 6. Two facts not described in Figure 12 are worth stating:

Relationships among data element concepts may be maintained in an MDR, which implies that a concept system of data element concepts may be maintained


(N:1)DATA ELEMENTCONCEPT

CONCEPTUALDOMAIN

DATA ELEMENT VALUE DOMAIN

(1:N) (1:N)

(N:1)

CONCEPTUAL LEVEL

REPRESENTATIONAL LEVEL

Figure 12: Overview Model for ISO/IEC 11179 Metadata Registry

ISO/IEC CD 11179-1

Relationships among conceptual domains may be maintained in an MDR, which implies that a concept system of conceptual domains may be maintained

Some fundamental issues of registration and administration of metadata in an MDR are described later in this clause.

7.3 Fundamentals of registration

The registration and administration functions specified in ISO/IEC 11179-6 are what separate an MDR from a database of metadata. The means to accomplish these functions are a large part of the design of the metamodel specified in ISO/IEC 11179-3.

Registration is the set of rules, operations, and procedures that apply to an MDR. A detailed description of registration as it applies in ISO/IEC 11179 is found in ISO/IEC 11179-6. The three most important outcomes of registration are the ability to monitor the quality of metadata, provenance (the source of the metadata), and the assignment of an identifier to each object described in an MDR. Registration also requires a set of procedures for managing a registry, submitting metadata for registration of objects, and maintaining subject matter responsibility for metadata already submitted. For actual implementations of a metadata registry, there may be additional requirements, which are outside the scope of this International Standard.

Each administered item is maintained in a uniform and prescribed manner. Identifiers, quality measures, responsible organizations, names, and definitions are all part of the general metadata that falls under administration. Registration is the process of creating or maintaining administrative and other detailed metadata.

Metadata quality is monitored through the use of a registration status. The status records the level of quality. Each level is specified in ISO/IEC 11179-6. Every administered item is assigned a registration status, and this status may change over time. In addition, metadata quality is multi-faceted. That is, there are several purposes to monitoring metadata quality. The main purposes are

Monitoring adherence to rules for providing metadata for each attribute

Monitoring adherence to conventions for forming definitions, creating names, and performing classifications

Determining whether an administered item still has relevance

Determining the similarity of related administered items and harmonizing their differences

Determining whether it is possible to ever get higher quality metadata for some administered items

The rules for creating and assigning identifiers are described in ISO/IEC 11179-6. Each administered item within an MDR is assigned a unique identifier.

The registration authority is the organization responsible for setting the procedures, administering, and maintaining an MDR. The submitting organization is responsible for requesting that a new metadata item be registered in the registry. The steward is responsible for the subject matter content of each registered item. Each of these roles is described in ISO/IEC 11179-6.


ISO/IEC CD 11179-1

8 Overview of ISO/IEC 11179, Parts 1- 6

8.1Introduction of Parts

This sub-clause introduces each part of the multi-part standard ISO/IEC 11179. It summarizes the main points and discusses the importance of each.

8.1.1 Part 1

ISO/IEC 11179-1, Framework, introduces and discusses fundamental ideas of data elements, value domains, data element concepts, conceptual domains, and classification schemes essential to the understanding of this set of standards and provides the context for associating the individual parts of ISO/IEC 11179.

8.1.2 Part 2

ISO/IEC 11179-2, Classification, provides a conceptual model for managing concept systems used as classification schemes. Concepts from these schemes are associated with administered items through the process of classification. Librarians, terminologists, linguists, and computer scientists are perfecting the classification process, so it is not described here. The additional semantic content derived from classification is the important point.

Associating an object with one or more concepts from one or more classification schemes provides

Additional understanding of the object

Comparative information across similar objects

Understanding of an object within the context of a subject matter field (defined by the scope of a classification scheme)

Ability to determine slight differences of meaning between similar objects

Therefore, managing classification schemes is an important part of maximizing the information potential within an MDR. ISO/IEC 11179-2 provides the framework for this.

8.1.3 Part 3

ISO/IEC 11179-3, Registry metamodel and basic attributes, specifies a conceptual model for an MDR. It is limited to a set of basic attributes for data elements, data element concepts, value domains, conceptual domains, classification schemes, and other related classes. The basic attributes specified for data elements in ISO/IEC 11179-3:1994 are included in this revision.

The registry metamodel is expressed in the Unified Modeling Language. It is divided into six regions for readability. All the provisions represented in the model are described in the text. Several provisions represented in comment boxes in the diagrams are described in the text.

The document contains a dictionary of all the modeling constructs (classes, attributes, and relationships) used in the model. This collection of attributes are known as the "basic attributes". All the attributes described in Parts 2, 4, 5, and 6 are contained in the registry metamodel.


ISO/IEC CD 11179-1

The registry metamodel is not a complete description of all the metadata an organization may wish to record. So, the model is designed to be extended if required. However, extensions are, by their nature, not part of the standard.

A clause describing conformance criteria is provided. Conformance is described as either strictly conforming (all provisions met) or conforming (all provisions met, but additional provisions may exist).

8.1.4 Part 4

ISO/IEC 11179-4, Formulation of data definitions, provides guidance on how to develop unambiguous data definitions. A number of rules and guidelines are presented in ISO/IEC 11179-4 that specify exactly how a data definition should be formed. A precise, well-formed definition is one of the most critical requirements for shared understanding of data; well-formed definitions are imperative for the exchange of information. Only if every user has a common and exact understanding of the data can it be exchanged trouble-free.

The usefulness of definitions is one aspect of metadata quality. Following the rules and guidelines provided in Part 4 helps establish this usefulness.

8.1.5 Part 5

ISO/IEC 11179-5, Naming and identification principles, provides guidance for the designation of administered items. Designation is a broad term for naming or identifying a particular data construct.

Names are applied to data constructs through the use of a naming convention. Naming conventions are algorithms for generating names within a particular context. There are semantic, syntactic, and lexical rules used to form a naming convention. Names are a simple means to provide some semantics about data constructs, however the semantics are not complete. Syntactic and lexical rules address the constituents (e.g., allowable characters), format, and other considerations.

Data constructs may be assigned multiple names, and one may be identified as preferred. Usually, each assigned name is used within the context for which it was created.

Identifiers are designations meant for dereferencing data constructs for metadata management and exchange. An RA assigns a unique identifier for each data construct, unique within the context of the registry. Thus, identifiers are assigned to data constructs for use in unambiguously locating data constructs.

8.1.6 Part 6

ISO/IEC 11179-6, Registration, provides instruction on how a registration applicant may register a data construct with an RA and the assignment of unique identifiers for each data construct. Maintenance of administered items already registered is also specified in this document. Registration mainly addresses identification, quality, and provenance of metadata in an MDR.

An administered item identifier is formed by the combination of the RA Identifier, the unique identifier assigned to the administered item within an RA, and the version. Each registry is maintained by an RA, to which data constructs logically and functionally belong. For example, data constructs related to chemical matter would likely be registered under a Chemical Manufacturer Registration Authority

Registration is more complex than a simple indication whether a metadata item is either registered or not. Although it is tempting to insist that only "good" metadata may be registered, that is not practical. Therefore, improvement in the quality of administered items is divided into levels called registration status. In addition, there are status levels for administration between each of these quality levels. Collectively, these status levels are called administrative status. They indicate the point in the registration life cycle currently attained for an administered item.


ISO/IEC CD 11179-1

The provenance of metadata, the chain of responsibility is managed in an MDR, too. The tasks and roles of the registration authority, data steward, responsible organization, and submitting organization are described. A framework for the registration process to be used in an MDR is provided.

Registration is both a process and a goal. The assignment of an identifier, quality status, life-cycle status, and describing provenance are goals. The rules by which these goals are accomplished is the process.

8.2Basic Principles for Applying ISO/IEC 11179, Parts 1-6

Each Part of ISO/IEC 11179 assists in a different aspect of metadata creation, organization, and registration; and each Part shall be used in conjunction with the other Parts. ISO/IEC 11179-1 establishes the relationships among the Parts and gives guidance on their usage as a whole. ISO/IEC 11179-3 specifies metadata items a registration applicant shall provide for each object to be registered. Detailed characteristics of each basic attribute are given. Because of their importance in the administration of metadata describing data constructs, three of the attributes (name, definition, and identification) are given special and extensive treatment in two documents. ISO/IEC 11179-4 shall be followed when constructing data definitions. Identification and naming shall follow principles set forth in ISO/IEC 11179-5. ISO/IEC 11179-2 specifies a set of attributes for use in the registration and administration of classification schemes and their components. Metadata items are registered as registry items and administered as administered items in an MDR. ISO/IEC 11179-6 provides guidance on these procedures.


ISO/IEC CD 11179-1

Annex A — Terminological Principles for Data

The following is a synopsis of terminological principles as they apply towards data. The following has been excerpted and summarized from ISO 704, ISO 1087-1, ISO/IEC 11179-1, and ISO/IEC 11179-4. This information and guidance is extremely valuable in understanding and using metadata across the enterprise.

A.1 Principle: The General Nature of Objects (Things)Formally, objects are anything perceivable or conceivable.15 For example, objects can be material (human, river) , immaterial (conversion ratio, the probability of success), or imagined (unicorn). For the purpose of this document, objects are assumed to exist and discussions of whether or not an object actually exists is outside the scope of this document and, largely, irrelevant to data and metadata.16 Attention should be focused on how one deals with objects for the purposes of communication (via humans, computers, etc.). Implicitly, objects can be referenced, which allows us to distinguish among objects (e.g., this vs. that).

Example 21 Objects include: a human, a data file, a web service

A.2 Principle: Concept and ExtensionTo communicate, not every individual object in the world is differentiated and named. Instead, through observation and a process of abstraction called conceptualization, objects are categorized into mental constructs or units of thought called concepts which are represented in various forms of communication (object → concept → communication). This annex does not deal with all concepts represented in language but only with those represented by terminologies and, possibly, codified as data. The notion of terminology is in its broadest sense: a set of designations belonging to a special language17. For terminology, concepts are to be considered mental representations of objects within a specialized context or field. For example, the notion of terminology applies to non-data scenarios (e.g., the notion of color and individual colors themselves, such as pink, red, yellow) and to data scenarios (e.g., the electrical resistor color codes of black=0, brown=1, red=2, orange=3, etc.).

Concepts are not to be confused with abstract or imagined objects (i.e., concrete, abstract or imagined objects in a given context are observed and conceptualized mentally and then a designation is attributed to the concept rather than to the objects themselves). For this document, the link between an object and its designation or definition is made through the concept, a higher level of abstraction.

Producing a terminology requires understanding the conceptualization that underpins knowledge in a subject area. Because a terminology always deals with special language in a particular field of knowledge, the concept shall be viewed not only as a unit of thought but also as a unit of knowledge.

The concepts contextualized in the special language of the subject field can be expressed in the various forms of human and computer communication according to the system used (e.g., the notion of "tank" in the special language of military vehicles is different than the notion of "tank" in the special language of pet supplies). In natural language, concepts can take the form of terms, appellations, definitions or other linguistic forms; in artificial language, they can take the form of codes18 or formulae while in graphics, they can take the form of icons, pictures, diagrams or other graphic representations. Concepts may also be expressed with the human body as they are in sign language, facial expressions or body movements.

15 The notion of "object" is similar to the lay notion of "thing".

16 For example, although unicorns do not exists, it is possible to collect data from children asking them how many legs unicorns, and it might be possible to get agreement upon shared characteristics of unicorns (e.g., horse-like, having a single horn on the head), which signal a common concept and common definition wording.

17 According to ISO 1087-1, a special language is used in a subject field (a field of special knowledge) and characterized by the use of specific linguistic means of expression.

18 The subject of code sets and their development is outside the scope of this document.


ISO/IEC CD 11179-1

When the concept depicts a single object, it is called an individual concept and is represented in special language as an appellation (e.g., United Nations, Internet, Worldwide Web) or a symbol (e.g.: Möbius Loop; Africa; Statue of Liberty). When the concept depicts a set of two or more objects, it is called a general concept and, in special languages, the designation takes the form of a term (e.g., CD-ROM, liquidity, money market fund, etc.) or a symbol (©, ≤, $). The extension is the totality of objects to which a concept corresponds. For example, Earth and Mars are within the extension of the concept "planet" and, by recent agreement of scientists, Pluto is not in the extension of "planet".

A.3 Principle: Intension, Characteristics, and Properties Concept formation plays a pivotal role in organizing knowledge19 because it provides the means for recognizing objects and for grouping them into meaningful units in a particular field. Objects perceived as sharing the same properties are grouped into units. Once similar objects, or occasionally a single object, are viewed as a meaningful unit of thought within a branch of knowledge, the properties of an object or common to a set of objects are abstracted as characteristics which are combined as a set in the formation of a concept. In some cases, the characteristics are known first (e.g., mass) and properties are determined for individual objects (e.g., object A's mass is 5 Kg, while object B's mass it 10 Kg).

Formally, a concept is unit of thought differentiated by characteristics; a characteristic is concept that plays the role of a determinable in a determining relation; a property is a concept that plays the role of a determinant in a determining relation.20 It is important to note that characteristics are associated with concepts, while properties are associated with the objects in the extension of the concept.

Characteristics are constantly being combined in order to create concepts, although differently in different cultures, fields or schools of thought. The combination of unique sets of characteristics is represented in special language by a designation (i.e., a term, appellation or symbol). Since a designation is not attributed to every individual object, terminological analysis cannot begin unless the specific object in question corresponds to a concept represented by means of a designation or a definition. Therefore, the methodology used in the analysis of terminologies requires identifying the context or subject field in question, identifying the properties attributed to objects in the subject field, determining those properties which are abstracted into characteristics, and then combining the characteristics to form a concept (which differentiate this unit of thought from other units of thought). It may be useful to begin an analysis with those concepts corresponding to concrete objects, since the characteristics are more easily abstracted given that the properties of the objects can be physically observed or examined. Properties should be ascribed only to objects.

Terminological analysis should begin with the objects in question and the subject field contextualizing the objects in question. Knowing the context of the subject field will greatly help determining and defining the concept. For example, a pencil might be used in the subject field of office supplies or the subject field of musical instruments21 and the choice of subject field might produce different definitions: "a writing instrument consisting of a wooden barrel that encases a graphite core" vs. "a percussive instrument, similar to drum stick, but with at least one rubber end".

Characteristics should be used in the analysis of concepts, the modeling of concept systems, in the formulation of definitions and, as often as possible, in the formation of designations.

The set of characteristics that come together as a unit to differentiate the concept is called the intension. The objects viewed as a set and conceptualized into a concept are known as the extension. The two, intension and extension, are interdependent. For example, the characteristics making up the intension of ‘lead pencil’ determines the extension, those objects that qualify as lead pencils and vice versa.

This interplay of intension (characteristics) and extension (corresponding objects) is important for determining precise definitions of concepts. When defining a concept, for a given intension, one can imagine the corresponding objects in the

19 The notion of "knowledge" here is used in its broadest sense, i.e., what is known but not necessarily proven to be true. In this broad sense, "knowledge" also includes statements that are known "2+2=5" but obviously false. The determination of what is true or false is outside the scope of this document. For terminology, the scope is limited to: determining whether or not objects are within the extension of a concept, the degree of applicability of characteristics towards concepts and objects, and the degree of applicability of properties towards objects. In many practical applications, stronger assertions of true and validation are necessary, e.g., a data element for Date-Of-Birth actually corresponds to the person's birth date.

20 This explanation might seem circular in that characteristics are defined as a kind of a concept and the definition of concept uses characteristics, but there is no circularity. Characteristics and properties are kinds of concepts. A concept is a unit of thought (i.e., it is not a characteristic itself), but these units of thought are differentiated by other units of thought of a special kind (characteristics), i.e., concepts are not comprised of characteristics, they are differentiated by characteristics.

21 Think of Johnny Carson's use of pencils in the Tonight Show.


ISO/IEC CD 11179-1

extension; if the set of objects inside the extension correspond to the concept and the set of objects outside the extension do not correspond to the concept, then one has arrived at a candidate definition; otherwise, the intension needs to be revised/refined to correctly corresponded to the intended set of objects.

EXAMPLE 22 An example of improving the intension of a concept is to look at the concept of metadata itself. Many years ago, a popular definition of metadata was:

[circa 1999] metadata: data about data

This definition's intension has two characteristics: (1) metadata is data, and (2) metadata is about data. By applying the methods above, we can see what is faulty. The first characteristic implies that all data can be metadata, but this is not true: only descriptive data can be metadata. This is an example of the original concept's intension includes too much in the extension, so the characteristic needs to be narrowed:

[after correcting first characteristic] metadata: descriptive data about data

The second characteristic implies that metadata is only about data and not about other things. Based upon this characteristic, Dublin Core Metadata (metadata about books, movies, media, resources, etc.) would not be considered metadata. This is an example of imagining the concept's extension and discovering that things considered to be metadata are not actually outside the extension. Thus, the original concept's intension includes too little in the extension, so the characteristic needs to be broadened:

[corrected characteristics, present definition] metadata: descriptive data about an object

EXAMPLE 23 A well-known example of a terminological issue occurred in 2006 when the International Astronomical Union (IAU) revised the definition of the concept of "planet". In essence, the IAU changed the intension of the definition22:

With the discovery during the latter half of the 20th century of more objects within the Solar System and large objects around other stars, disputes arose over what should constitute a planet. There was particular disagreement over whether an object should be considered a planet if it was part of a distinct population such as a belt, or if it was large enough to generate energy by the thermonuclear fusion of deuterium.

A growing number of astronomers argued for Pluto to be declassified as a planet, since many similar objects approaching its size had been found in the same region of the Solar System (the Kuiper belt) during the 1990s and early 2000s. Pluto was found to be just one small body in a population of thousands.

Some of them including Quaoar, Sedna, and Eris were heralded in the popular press as the tenth planet, failing however to receive widespread scientific recognition. The discovery of Eris, an object 27 percent more massive than Pluto, brought things to a head.

Acknowledging the problem, the IAU set about creating the definition of planet, and eventually produced one in 2006. The number of planets dropped to the eight significantly larger bodies that had cleared their orbit (Mercury, Venus, Earth, Mars, Jupiter, Saturn, Uranus, and Neptune), and a new class of dwarf planets was created, initially containing three objects (Ceres, Pluto and Eris).

The result was splitting the original concept of "planet' into two new concepts of "planet" and "dwarf planet", which caused Pluto to move from the extension of "planet" to "dwarf planet". The following definition of planet is an intensional definition containing 4 characteristics ("a celestial body" plus the 3 enumerated characteristics).

The definition of "planet" set in 2006 by the International Astronomical Union (IAU) states23

In the Solar System a planet is a celestial body that:

22 Taken from http://en.wikipedia.org/wiki/Planet

23 Taken from http://en.wikipedia.org/wiki/2006_definition_of_planet


http://en.wikipedia.org/wiki/2006_definition_of_planet

http://en.wikipedia.org/wiki/Planet

ISO/IEC CD 11179-1

1. is in orbit around the Sun,

2. has sufficient mass to assume hydrostatic equilibrium (a nearly round shape), and

3. has "cleared the neighbourhood" around its orbit.

A non-satellite body fulfilling only the first two of these criteria is classified as a "dwarf planet".

A.4 Principle: Concept Systems, Relationships, and RelationsConcepts do not exist as isolated units of thought but always in relation to each other. Our thought processes constantly create and refine the relations between concepts, whether these relations are formally acknowledged or not.

In organizing concepts into a concept system, it is necessary to bear in mind the field of knowledge that gave rise to the concept and to consider the expectations and objectives of the target users. The subject field shall act as the framework within which the concept field, the set of related but unstructured concepts, is established.

To model a concept system, the concepts of the concept field have to be examined and compared. For the purposes of this document, at least the following relations should be used to model a concept system:

— hierarchical relations:

— generic relations;

— partitive relations;

— associative relations.

A.4.1 Types of hierarchical relationsIn a hierarchical relation, concepts are organized into levels where the superordinate concept is subdivided into at least one subordinate concept. Subordinate concepts at the same level and having the same criterion of subdivision are called coordinate concepts. The coordinate concepts resulting from the application of the same criterion of subdivision to the superordinate concept constitute a dimension. A superordinate concept can have more than one dimension, in which case the concept system is said to be multidimensional. Concepts are superordinate, subordinate or coordinate, not on their own, but always in relation to each other in a hierarchy.

In this document two types of hierarchical relations are recognized:— generic relations;

— partitive relations.

A.4.2 Generic relationsA generic relation exists between two concepts when the intension of the subordinate concept includes the intension of the superordinate concept plus at least one additional delimiting characteristic. The superordinate concept in a generic relation is called the generic concept and the subordinate concept is called the specific concept.

In a generic relation, there is an inverse relationship between the intension of a concept and its extension. Hence, if a concept has a narrow intension, its extension will be relatively broader and, inversely, if the intension is broad, the extension will be relatively narrower.

Comparing the essential characteristics of a concept and its related concepts (i.e., generic, coordinate and specific) may require an adjustment and refinement of the intension.

A sequence of concepts reflecting generic relations constitutes a vertical series of concepts, whereas a group of coordinate concepts, i.e., concepts that rank at the same level of abstraction in a concept system, form a horizontal series of concepts.

In a generic relation, there may be several ways of subdividing a concept into subordinate concepts depending on the criteria or type of characteristic chosen. When more than one criterion are used in the construction of a generic concept system, it is considered multidimensional. Only subordinate concepts on the same level and in the same dimension are


ISO/IEC CD 11179-1

called coordinate concepts. In a generic concept system, a node may not have an established designation, or may have a designation in one language but not in another.

EXAMPLE 24 There is a generic relation between "mammal" and "feline" and between "quantity" and "temperature observation".

A.4.3 Partitive relationsA partitive relation is said to exist when the superordinate concept represents a whole, while the subordinate concepts represent parts of that whole. The parts come together to form the whole. The superordinate concept in a partitive relation is called the comprehensive concept and the subordinate concept is called the partitive concept. Subordinate concepts at the same level and sharing the same dimension are also called coordinate concepts.

Partitive, like generic relations can be expressed as vertical and horizontal series.

The parts that make up the whole may be similar in nature (e.g., atom in an oxygen molecule) or distinctly different from each other. One or more parts may be compulsory (i.e., essential) or optional (i.e., non-essential). Some parts are not only essential but delimiting in that they allow the whole to be distinguished from other similar comprehensive concepts. Some parts may be multiple (e.g., concept of ‘page’ as part of a book) or variable within a range (e.g., a pen may have as a part an ink reservoir, an ink cartridge or an ink refill).

A partitive concept system does not always allow for a complete analysis of a concept. If a partitive concept is not particular to the comprehensive concept, then the extension of the partitive concept is not accounted for completely and essential characteristics of its intension may be lacking. A partitive concept shall be defined on the basis of a partitive relation only if the complete extension and the essential characteristics of the intension can be determined.

EXAMPLE 25 There is a partitive relation between "automobile" and { "engine", "passenger compartment", "drive train", and "wheels" }; and between "mailing label" and { "addressee", "street address", "city", "state", and "zip code" }.

A.4.4 Associative relationsAssociative relations are non-hierarchical. An associative relation exists when a thematic connection can be established between concepts by virtue of experience.

Some associative relations exist when dependence is established between concepts with respect to their proximity in space or time. These relations might involve raw material – product, action – equipment/tool, quantity – unit, material – property, material – state, matter/substance – property, concrete item – material, concrete item – shape, action – target, action – place/location, action – actor, etc.. Some relations involve events in time such as a process dependent on time or sequence; others relate cause and effect.

Typically, for the purposes of interoperability, the selection of associative relations is determined by a community of practice and standardized via a standardizing body using a governance process.

EXAMPLE 25 There is a partitive relation between "employee" and "payroll record".

A.4.5 Concept systemsNature of concept systems

The terminology of a field should not be an arbitrary collection of terms. The terminology of a subject field is the collection of designations attributed to concepts making up the knowledge structure of the field. The concepts should constitute a coherent concept system based on the relations established between concepts. The unique position of each concept within a system is determined by the intension, i.e. the unique set of characteristics constituting the concept, and the extension.


ISO/IEC CD 11179-1

Different subject fields view the same bodies of knowledge in different ways. The same objects may be combined to form different units of knowledge with different intensions and extensions, thus resulting in different concept systems and distinct designations. For example: hypothetical-deductive approaches such as mathematics may create concept systems based on statistics or abstract mathematical formulae, whereas the natural sciences may view the same body of knowledge, but draw up systems resulting from the classification of observed phenomena. Engineering and technology may structure a system according to production processes, whereas specialists in law or sociology can view the same phenomena in terms of legal liability or social interaction. A concept system serves to:

— model concept structures based on specialized knowledge of a field;

— clarify the relations between concepts;

— form the basis for a uniform and standardized terminology;

— facilitate the comparative analysis of concepts and designations across languages;

— facilitate the writing of definitions.

Types of concept systems

The types of concept systems include:— generic concept system: a system in which all the concepts in a vertical series relate to each other as generic

and specific concepts, e.g., a taxonomy of plants.

— partitive concept system: a system in which all the concepts in a vertical series relate to each other as a whole and its parts, e.g., a decomposition of an automobile into subsystems (engine, passenger compartment, etc) and into further decomposition of components (block, cylinder, piston, etc.).

— associative concept system: a system in which all the concepts relate to each other by association. The type of associative relation between any two concepts may vary within a system

— mixed concept system: a system constructed using a combination of the concept relations.

EXAMPLE 26 Some concept systems provide a partitioning24 of the observations, such as { "underweight", "normal", "overweight" }. Other concept systems are not partitions and more than one description might apply, such as { "African descent", "Americas Descent", "Asian descent", "Australian descent", "European descent" }.

A.4.6 Developing concept systemsA concept field is the group of unstructured but thematically related concepts that shall be used as the starting point for building a concept model.

The modeling of concept systems involves a series of interactive operations leading, for example, to the compilation of a vocabulary in a specific subject field. These operations generally include:

— selecting the concept field, the preliminary designations and concepts to be treated by taking into account the subject field, the user group and its needs;

— analyzing the intension and extension of each concept;

— determining the relation and position of these concepts within the concept system;

— formulating and evaluating definitions for the concepts based on the concept relations;

— attributing designations to each concept.

The steps involved in modeling concept systems and defining concepts are closely related. Definitions shall reflect the concept system; the relations within the system shall be established primarily by analyzing the characteristics of each concept included in its respective definition, if a formal definition already exists. Consequently, modeling and diagramming the structure of a concept system, and writing definitions for the concepts treated in that system, can require review and repetition of some operations.

24 A partition means that there is only one choice possible.


ISO/IEC CD 11179-1

EXAMPLE 27 For data systems, the choice of concept systems can greatly affect computing applications. For example, in categorizing human sex, one can use a simple gender-based system (male, female) or a genomic-based system (chromosomes: XX, XXX, XY, XXY, XYY). The genomic system might be more accurate, but the gender system affords better computability in typical business scenarios (e.g., determining the number of and kind of toilet facilities at an event). There is no single right choice of concept system: the decision-making is based upon the ones that afford the best computability for the applications.

A.5 Principle: Writing Good Definitions Not all characteristics are equally important. For practical purposes, the essential characteristics of the intension shall be the focal point of any analysis and may differ according to specific fields. Characteristics are considered essential if they are indispensable for the understanding of the concept in a particular field of knowledge; the absence of an essential characteristic fundamentally changes the concept. The absence of an essential characteristic in the course of an analysis will lead to poor or even erroneous understanding of the concept. In the example of the ‘lead pencil’, if the characteristic graphite core is encased in wood were removed, the concept would be radically changed. It would represent a different concept corresponding to a different set of objects. Therefore, this is an essential characteristic. On the other hand, if the characteristic one end may be sharpened to a point were removed, the concept would not be altered. Although a lead pencil must be sharpened in order to write, it still qualifies as a lead pencil, even if it has not been sharpened. Therefore, this characteristic is not essential to the understanding of the concept of ‘lead pencil’. The essential characteristics of a concept, such as ‘lead pencil’, shall be identified. It is not always necessary to categorize the characteristics explicitly as in the examples above; only in cases where the concept in question is highly complex.

A.5.1 Delimiting characteristicsAfter identifying the essential characteristics that make up the intension of a concept, the terminological analysis shall be taken a step further. Each essential characteristic of the concept under study shall be analyzed in relation to the related concepts in the concept system. Common or shared characteristics indicate similarities between concepts; delimiting characteristics signal differences which set a concept apart (see examples 7 and 8). A delimiting characteristic is an essential characteristic that distinguishes one concept from another. However, delimiting and common are relative terms. The same essential characteristic may be delimiting in relation to one concept but common in relation to another related concept. Analyzing the similarities and differences between concepts will result in the unique set of characteristics that typify a given concept. This unique combination of characteristics will situate the concept within a network of related concepts with similar or different characteristics. The relations between the concepts shall be used to determine the basic structure of the concept system. Understanding the characteristics used to develop the concept system simplifies the task of defining a concept.

A definition should define the concept as a unit with a unique intension and extension. The unique combination of characteristics creating the intension should identify the concept and differentiate it from other concepts. The quality of most terminological products will be determined by the quality of the definitions.

Some terms are so long and complex that they could almost serve as definitions; some definitions are so short they could almost be thought of as terms. In spite of this, the definition should not be confused with the designation.

A definition may be complemented by a note or a graphic representation.

EXAMPLE 28 A "graphite core" is a characteristic of a pencil and it is a delimiting characteristic in the context of other writing instruments, e.g., "graphite core" is not a characteristic of a pen.

A.5.2 Types of definitionsIn terminology, the following types of definitions are recognized:

— intensional definition;

— extensional definition.

Intensional definitions

Intensional definitions shall indicate the superordinate concept, either immediately above or at a higher level, followed by the characteristic(s) that distinguish the concept from other concepts. The superordinate concept situates the concept in


ISO/IEC CD 11179-1

its proper context in the concept system (e.g., pencils among writing instruments, trees among plants). In practice, intensional definitions are preferable to other concept descriptions. Intensional definitions should be used whenever possible as they most clearly reveal the essential characteristics of a concept within a concept system.

The intensional definition should be based on the concept relations determined during analysis. A definition based on a generic relation shall state the generic concept sharing the same dimension, either immediately above or at some higher level, followed by the essential characteristics that differentiate the given concept from coordinate concepts in a generic concept system.

By stating the generic concept, the characteristics that make up the intension of the superordinate concept are implicitly assumed in the definition.

A definition based on a partitive relation should describe a concept as a part of a particular whole or comprehensive concept. It is therefore necessary to analyze the comprehensive concept first and to indicate its relation to the partitive concepts. Partitive definitions typically begin with formulations that clearly indicate the partitive relation such as: part of, component of, section of, period of, element in, ingredients making up, etc., followed by the superordinate concept (i.e., the comprehensive concept) and the delimiting characteristics. To avoid circularity, defining concepts on the basis of a partitive analysis is to be restricted to one level, either the subordinate level or the superordinate level, not both.

A concept should be defined as a partitive concept only if it constitutes an essential part of the comprehensive concept and the extension of the concept is complete.

A comprehensive concept may be defined on the basis of a mixed concept system. The definition should state the generic concept above followed by the essential parts that make up the comprehensive concept in question. Optional parts shall not be included in the definition. Optional parts frequently associated with a concept may be mentioned in a note. This type of definition is practical only if the number of parts to be enumerated is limited.

A concept may be defined on the basis of the associative relation between two concepts. The definition should state the superordinate concept followed by characteristics that indicate the relationship between the concepts in question. It should be noted that, in many cases, the superordinate concept is not a specialized concept and therefore, care shall be taken to ensure that the complete intension and extension of the concept have been analyzed thoroughly before defining the concept on the basis of an associative relation. For example, the associative concept system in example 16 shows a "container-contained" relationship between pencil case and pencil. However, a pencil case is a container designed to hold and carry not only pencils but writing instruments in general.

Extensional definitions

In highly specialized terminological documents directed at field specialists, the definition can be formulated as a list of the subordinate concepts, in only one dimension, which correspond to objects making up the extension of the concept. The list of subordinate concepts may consist of either individual or general concepts. It is important to remember that the extension is not the same as an extensional definition. The list stands for concepts that depict the objects making up the extension and not the objects themselves. The operator "or" in the definition shall be used to indicate a generic relation between the subordinate concepts in the definition and the superordinate concept that is being defined; the operator "and" shall be used to indicate a partitive relation.

Extensional definitions are to be used only when intensional definitions are difficult to elaborate. Extensional definitions shall be used only if the number of concepts to be enumerated is limited, the list of concepts is complete in one dimension and the subordinate concepts can be clarified by intensional definitions or are well known

EXAMPLE 29 In data descriptions, intensional definitions might be used when the value space is very large or infinite, e.g., the datatypes of integers and reals describe their value spaces using (mathematical) characteristics that describe the value space (i.e., the extension of the concept). In some data descriptions where a general description is difficult or impractical, extensional definitions might be used to describe the elements of the value space, e.g., a value space containing the notions of Male and Female, or another value space containing the notions of Single, Married, Widowed, Divorced.

A.5.3 Definition writingPrinciples for definition writing


ISO/IEC CD 11179-1

A terminological entry shall be composed of a statement explaining what the concept is. The statement is made up of a subject, copula, and predicate.25 The subject is the designation, the copula is understood to be the verb "is" and the predicate constitutes the definition. Typographical conventions, such as a colon, a dash or by starting a new line of text, introduce the beginning of the predicate (see ISO 10241 for layout).

A definition shall describe a concept, not the words that make up a designation.

Before drafting a definition for a given concept, it is necessary to determine the relations between the concept and its related concepts and to model a concept system within which the concept is situated.

If a definition already exists, in an another specification for example, it shall be adopted as it stands only if it reflects the concept system in question. Otherwise, it shall be adapted.

When modeling the concept system and formulating the corresponding system of definitions, it is essential to determine which concepts are so basic and familiar that they need not be defined. Generally, one begins by defining superordinate concepts. When drafting a new definition, use shall be made of basic concepts or concepts defined elsewhere in the document as far as possible.

Systemic nature of definitions

A definition shall reflect the concept system describing the concept and its relations to others in the system. Definitions shall be coordinated so as to be able to reconstruct the concept system. The characteristics used in the definition should therefore be selected to indicate the connection between the concepts or the delimitation that distinguish one concept from another.

Conciseness

Ideally, definitions shall be as brief as possible and as complex as necessary. Complex definitions can contain several dependent clauses, but carefully written definitions contain only that information which makes the concept unique. Any additional descriptive information deemed necessary should be included in a note.

A definition shall describe only one concept. It shall not include hidden definitions for any concepts used to identify characteristics. Any characteristic that requires an explanation shall be defined separately as a concept or given in a note

The definition should not contain characteristics that belong logically to superordinate or subordinate concepts.

In the definition of ‘mechanical pencil’, it is not necessary to indicate the characteristic concreteness (all the objects in the extension are concrete) since this characteristic is part of the intension of the superordinate concept.

In the definition of ‘pencil’, it is unnecessary to note that a pencil can be either a ‘lead pencil’ or a ‘mechanical pencil’ because the generic concept ‘pencil’ allows for both of these subordinate concepts.

Subject field

The extension and the characteristics reflected in a definition shall be appropriate to the concept system in a given subject field.

If the specific field of the concept is not clearly indicated in the designation or is not generally understood, it shall be added to the beginning of the definition (see example 28 and ISO 10241 for layout).

Principle of substitution

The substitution principle shall be used to test the validity of a definition. A definition is valid if it can replace a designation in a text without loss of or change in meaning. For example, in the sentence "the metadata was stored in the repository", the word "metadata" can be substituted by its definition "the descriptive data about an object was stored in the repository".

25 For example, in the definition:

metadatadescriptive data about an object

the definition wording is formulated as a statement containing a subject, copula (implied joining words, e.g., "is" or "is a"), and a predicate: "[subject] metadata [copula] is [predicate] descriptive data about an object".


ISO/IEC CD 11179-1

EXAMPLE 30 For ISO 3166 country codes, the following is a the "country identifier" is defined as "an identifier for a primary geopolitical entity of the world".

A.5.4 Deficient definitionsCircular definitions

Common types of deficient definitions are: circular, incomplete and negative definitions.

If one concept is defined using a second concept, and that second concept is defined using the term or elements of the term designating the first concept, the resulting definitions are said to be circular. Circular definitions do not add to our understanding of the concept and shall be avoided as much as possible.

Definitions can be circular:— within a single definition;

— within a system of definitions.

Circularity within a definition occurs when the designation is repeated to introduce the definition or an element of the designation is used as a characteristic. When formulating a definition, it is not permissible to repeat the designation to introduce the definition. The use of an element of the designation, other than the head word, as a characteristic in the definition should be avoided as much as possible.

A definition is circular within a system of definitions when two or more concepts are defined by means of each other. The substitution principle clearly reveals repetition and circularity.26

Incomplete definitions

A definition shall describe the content of the concept precisely. It shall be neither too narrow nor too broad. Otherwise, the definition is considered incomplete. Non-essential or irrelevant characteristics in the definition may unintentionally include or exclude objects from the extension of the concept. A definition is considered too broad if the characteristics selected to describe the concept allow for objects that should not be part of the extension. A definition is considered too narrow if the characteristics selected exclude objects that should be part of the extension.

In adapting an existing definition to a specific subject field or context, care should be taken not to change the extension of the concept. A change to the extension leads to a new unit and a different concept. Similarly, changes to any of the essential characteristics in a definition result in a new concept.

A particular context rarely refers to all the objects making up the extension of a concept. Definitions in laws and regulations tend to be interpretive rather than defining. Definitions should be defining rather than interpretive. If a concept is restricted to a particular interpretation for a given text, it shall be explained in the body of the specification rather than by creating a new concept with a narrower extension. If specification information is associated with the concept, then this should be given in an appropriate specification clause rather than in a definition.

Designations for parts whose extension extends beyond the partitive relation under study are not to be defined narrowly in terms of the comprehensive concept.

An extensional definition must list all the subordinate concepts corresponding to objects in the extension. Open-ended formulations (such as, for example, the following items, etc.) are not acceptable. Incomplete lists may be given in a note to the definition

EXAMPLE 31 For the data element "patient temperature", the definition "core body temperature" is likely to be insufficient because it does not identify which kind of measurement technique is used: different measurement techniques (in the ear, in the mouth, in the rectum, under the arm) produce different and incompatible data.

26 It might be impossible to reduce circularity in certain concept definitions. For example, it is impossible to define the directional notions of "left" and "right" without introducing circularities within the definition, concept system, or related concept systems..


ISO/IEC CD 11179-1

A.6 Principle: Signifiers, Designations, Terms, AppellationsSignifiers are used in communication in language, data, and in other areas. A signifier is always based upon a perceivable object (e.g., a mark, a sound, a magnetic signature, a gesture, a burst of electromagnetic radiation). By convention (e.g., specification, standard, cultural, etc.), the signifier are used to designate concepts.

A.6.1 DesignationsTypes of designations

The designation acts as a synthesis of the definition. A designation is a representation (via signifier) of a concept by linguistic or non-linguistic means. For the purposes of this document, designations are categorized as

— terms designating general concepts;

— appellations designating individual concepts, and

— symbols designating both individual and general concepts.

It should be noted that not all symbols are designations.

A.6.2 TermsTerm-concept relations

A term is a designation consisting of one or more words representing a general concept in a special language. A simple term contains only one root while a term containing two or more roots is called a complex term.

A term has to be accepted and used by subject specialists. A new term created to designate a concept is a type of neologism and is called a neoterm. Although most neoterms designate new concepts, some designate established concepts.

Ideally, the objective of term-concept assignment in a given special language is to ensure that a given term is attributed to only one concept and a given concept is represented by only one term, a condition called monosemy. This condition reduces ambiguity while homonymy and synonymy can lead to ambiguity.

Monosemy

Monosemy is the relation between designations and concepts in which one designation represents only one concept. Designations in such a relation are called monosemes.

Homonymy

Homonymy involves the relation between designations and concepts in which designations in a given language have identical forms, either phonetic or written, but designate different and unrelated concepts.27

Terms that are phonetically identical but written differently are called homophones, while homographs have identical written forms but are pronounced differently. Full homonyms are both written and pronounced the same way.

A.7 Principle: Value and the Terminological Nature of DataA datum (and its plural data) can be now seen as a designation (a signifier that denotes a concept), but not just any concept. The distinguishing feature of this data-like concept is that it incorporates a defined notion of equality. While at first glance the it might seem that data has more than merely "equality", there are many kinds of data, e.g., datatypes,28 and not all data affords all kinds of computation: some kinds of data are arithmetic (quantities) and some are not (boolean values); some kinds of data are ordered (Low, Medium, High) and some kinds of data are unordered (human sexes Male and Female).

27 Homonymy, a phenomena of natural language, also occurs in data processing (e.g., an XML record "<tank>" for a military vehicle vs. "<tank>" for pet fish). Typically, namespace management techniques are used to disambiguate similar-spelled identifiers.

28 See ISO/IEC 11404 General Purpose Datatypes for further explanation of datatypes and characterizing operations. This standard is freely available athttp://standards.iso.org/ittf/PubliclyAvailableStandards/c039479_ISO_IEC_11404_2007%28E%29.zip


http://standards.iso.org/ittf/PubliclyAvailableStandards/c039479_ISO_IEC_11404_2007(E).zip

ISO/IEC CD 11179-1

Fundamentally, all data have in common the notion of equality, i.e., of a particular datatype, datum X and datum Y can be compared for equality.

A.8 Principle: Terminological Aspects of Data InteroperabilityData is described computationally, such as datatypes (data properties, value spaces, and characterizing operations) and the elements of value space are described conceptually via terminological methods (each element of the value space is a concept). For actual implementations, signifiers (e.g., numerals, code sets) designate the elements of the value space and, in some cases, representation systems (structured organizations of signifiers) are used to afford more efficient computations, such as binary and decimal numeric representation systems.

As described in Clause 4, data interoperability is defined by determining the essential and inessential descriptions of datums, such as essential characteristics (essential factors) of the conceptual derivation of the composite concept and the datatype description (datatype properties, value space, and characterizing operations). For example, is accuracy and precision important for data exchange? (Most likely; is measurement technique essential for understanding the data? (maybe Yes, maybe No); is last the timestamp of the last read access important? (probably not), and so on. Without identifying these key data descriptions, there is incomplete or no agreement upon the meaning of data being exchanged.

A.9 Principle: Good Data DefinitionsGood data definitions require more than just good computational and conceptual descriptions. The following aspects should be considered when describing data:

— To what extent can the data description be re-used? For example, most programming language and database systems provide a notion of datatypes and/or object-oriented classes so that descriptions can be re-used across multiple instances of data (or objects). As another example, most data description standards provide some referencing or inclusion feature so that portions of data description can be shared. The proper factoring of data descriptions can greatly afford use and re-use of data.

— Have the data descriptions defined all the conceptual features? Given the interplay between data and information, more information is revealed when data is contextualized by concept systems. These contextualizing concepts systems should reveal relationships and structures, as agreed upon by communities of practices.29

— Do the data descriptions conform to the relevant standards and specifications? While technical and business processes30 might mandate certain descriptive features and data processes, it is likely that the data will need to be used in unanticipated ways (The Use-Case of the Unanticipated Users). Supporting unanticipated use requires the inclusion of broader data descriptive techniques than those that might have been originally envisioned.

EXAMPLE 32 The data element "patient temperature" could be defined as "core body temperature, in degrees Celsius to at least one decimal place of precision and 0.2 C accuracy, measured in the ear via infrared thermometer".

29 It is possible to have general relationships and structures, but these might only afford human understanding. To afford computation and machine interoperability, standardized descriptive methods and relationships are required.

30 For example, engineering processes, quality management processes, privacy processes.


ISO/IEC CD 11179-1

Bibliography

[1] .


iso/iec fdis 11179-1 - jtc1 sc32€¦ · web view0.3 what is new in iso/iec 11179-1 (edition 3)...

Documents