Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
CAN/CSA-ISO/IEC 11179-5-16 (ISO/IEC 11179-5:2015): Metadata Naming and Identification Principles
A Technical Guide to the Scope, Requirements, and Implementation of Standardized Metadata Registry Naming
Scope and Purpose of CAN/CSA-ISO/IEC 11179-5-16
The management of metadata is a cornerstone of modern data governance and interoperability. CAN/CSA-ISO/IEC 11179-5-16 (which is the identical Canadian adoption of ISO/IEC 11179-5:2015) is part of the broader ISO/IEC 11179 series on Metadata Registries (MDR). This specific part addresses the fundamental principles of naming and identification of metadata items. It provides a structured framework for creating unambiguous, human-readable names and machine-identifiable identifiers that foster semantic consistency across systems.
Unlike other parts of the 11179 series—such as Part 3 (Conceptual Model) or Part 6 (Registration)—Part 5 focuses exclusively on the syntactic and semantic rules governing how data elements and their associated attributes are formally designated. The standard applies to:
- Data Element Naming: Establishing conventions for naming data elements, value domains, conceptual domains, and data element concepts.
- Identifier Construction: Defining rules for creating globally unique or locally unique identifiers that remain persistent and resolvable over time.
- Contextual Naming: Recognizing that names often exist in different environments (e.g., a legal business name versus a system database column name).
Tip: CAN/CSA-ISO/IEC 11179-5-16 is essential for organizations building an Enterprise Data Dictionary or formal Metadata Registry (MDR). It ensures data is not only defined but also findable and identifiable across diverse data silos, making it a critical standard for data fabric and data mesh architectures.
Technical Requirements and Core Concepts
The standard breaks down naming and identification into distinct phases. The core technical architecture revolves around two main pillars: the Naming Convention and the Identification Scheme.
Naming Convention Principles
A naming convention as defined by the standard is a set of formal rules for constructing names from defined semantic components. Names must be:
- Context-Specific: A single data element may have multiple names depending on its context (e.g., business name, system name, display name).
- Compositional: Names should be constructed from an ordered set of components, typically following an Object Class → Property → Representation pattern.
- Unique within a Context: Within a given naming scope, no two items may share the same human-readable name.
Critical Compliance Point: Ambiguous naming is a primary source of data integration failure. The standard explicitly requires prevention of homographs (same spelling, different meaning) and synonyms within a single naming scope. Ignoring this directly impacts auditability.
| Component | Role in Name | Example |
|---|---|---|
| Object Class | The logical data group or entity | Customer, Employee, Product, Invoice |
| Property | The characteristic or attribute | Date of Birth, First Name, Price |
| Representation | The data type or value form | Numeric, Date, Text, Code |
| Qualifier | A term that narrows the meaning | Start, End, Current, Original |
Identification Principles
While names serve human communication, identifiers are required for machine processing and long-term interoperability. The standard defines strict rules for Registration Authorities regarding the creation of persistent, stable identifiers. An identifier is defined as a linguistically independent sequence of characters.
| Attribute | Requirement | Compliance Note |
|---|---|---|
| Uniqueness | An identifier must be unique within its naming scope and registry. | No duplicates permitted. |
| Persistence | Identifiers must never be reassigned to different metadata items. | Decommissioned items retain their identifiers. |
| Structure | Can be opaque (surrogate) or meaningful (hierarchical). | Structure must be formally documented. |
| Versioning | Strongly recommended for tracking evolving definitions. | Hypotheses defined in Clause 6.4 of the standard. |
Implementation Warning: While opaque identifiers (like UUIDs) are technically simpler to manage, the standard emphasizes that the administered item must be sufficiently documented to resolve the identifier. An identifier without resolvable metadata is non-compliant with the intent of the standard.
Implementation Highlights
Implementing CAN/CSA-ISO/IEC 11179-5-16 requires embedding its principles into the organization’s data governance workflows. A phased approach is recommended:
1. Governance Framework
Establish a data governance body responsible for maintaining the Naming Convention Specification document. This document must conform to the structure provided in Clause 5 of the standard, covering rules for concatenation, separators, character sets, and context-specific naming.
2. Tooling and the Metamodel
The standard explicitly builds upon the metamodel defined in ISO/IEC 11179-3. A conformant Metadata Registry (MDR) tool should enforce the naming conventions and identifier rules. Automated validation pipelines can check proposed data element names against the established convention before registration.
3. Context Management
Implement a system for handling multiple named contexts. For example, the legal name of an entity (“International Business Machines Corporation”) might differ from the system name (IBM_CORP) or the display name (IBM). The standard provides the formal framework to map these contexts, ensuring traceability without ambiguity.
Success Strategy: Begin by adopting the Object Class / Property / Representation pattern for your highest-impact data domains (e.g., Customer, Product, Finance). This immediately improves consistency and aligns your governance program with standard MDR tooling and industry best practices.
Compliance and Auditing Notes
Compliance with CAN/CSA-ISO/IEC 11179-5-16 in a Canadian context means adhering to the identical text of ISO/IEC 11179-5:2015. Conformance is evaluated against the specific requirements in Clauses 5 (Naming) and 6 (Identification). Organizations claiming conformance must clearly specify which subset of requirements (naming, identification, or both) is satisfied.
Key Audit Checkpoints:
- Identifier Stability: The most common audit finding is the reuse of deprecated identifiers. The standard mandates that an identifier, once assigned, must persist. Reusing an identifier for a new or modified concept is a direct violation.
- Propositional Naming: Names must be full, clear, and composed according to the convention. Abbreviated names (e.g.,
CustDOBinstead ofCustomer Date of Birth) are allowed only if they follow a documented abbreviation convention within the registry context. - Context Documentation: Every name must have an associated context. The context itself must be registered and maintained as a metadata item.
Audit Risk: Organizations transitioning from an unstructured data catalog to a formal MDR often fail the uniqueness requirement. A common misconception is that identifiers can be regenerated during data migration. The standard forbids this—a stable identifier lineage is non-negotiable for successful certification.
FAQs
Q: What is the primary difference between ISO/IEC 11179-5 and ISO/IEC 11179-6?
A: Part 5 (CAN/CSA-ISO/IEC 11179-5-16) specifies the principles for naming and identification of metadata items. Part 6 defines the registration procedures for administering those items. Naming conventions from Part 5 must be finalized before an item can be effectively registered using Part 6.
A: Part 5 (CAN/CSA-ISO/IEC 11179-5-16) specifies the principles for naming and identification of metadata items. Part 6 defines the registration procedures for administering those items. Naming conventions from Part 5 must be finalized before an item can be effectively registered using Part 6.
Q: Does this standard mandate a specific typographical syntax, such as CamelCase or underscores?
A: No. The standard defines the principles for structuring names (compositionality, context, uniqueness) but does not prescribe a specific typographical syntax. An organization may choose CamelCase, PascalCase, or underscores, provided the chosen rule is documented and consistently applied within the naming context.
A: No. The standard defines the principles for structuring names (compositionality, context, uniqueness) but does not prescribe a specific typographical syntax. An organization may choose CamelCase, PascalCase, or underscores, provided the chosen rule is documented and consistently applied within the naming context.
Q: How does this standard support modern data architectures like Data Mesh or Data Fabric?
A: It provides the critical linguistic and governance layer. In decentralized architectures, multiple domains must produce interoperable data products. CAN/CSA-ISO/IEC 11179-5-16 ensures that the names and identifiers for data elements are constructed according to a shared, rigorous standard, preventing semantic drift at scale.
A: It provides the critical linguistic and governance layer. In decentralized architectures, multiple domains must produce interoperable data products. CAN/CSA-ISO/IEC 11179-5-16 ensures that the names and identifiers for data elements are constructed according to a shared, rigorous standard, preventing semantic drift at scale.
Q: Are there any known conflicts with privacy regulations like GDPR or PIPEDA?
A: No direct conflict exists. In fact, the standard supports privacy compliance by requiring strict identification of data elements. A compliant MDR makes it easier to locate and manage personal information across systems, supporting data mapping and subject access requests required by regulations.
A: No direct conflict exists. In fact, the standard supports privacy compliance by requiring strict identification of data elements. A compliant MDR makes it easier to locate and manage personal information across systems, supporting data mapping and subject access requests required by regulations.