© 2025 The Calendaring and Scheduling Consortium, Inc.
This document is not a CalConnect Standard. It is distributed for review and comment, and is subject to change without notice and may not be referred to as a 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.
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior written permission. Permission can be requested from the address below.
The Calendaring and Scheduling Consortium, Inc.
4390 Chaffin Lane
McKinleyville
California 95519
United States of America
www.calconnect.org
The Calendaring and Scheduling Consortium (“CalConnect”) is a global non-profit organization with the aim to facilitate interoperability of collaborative technologies and tools through open standards.
CalConnect works closely with international and regional partners, of which the full list is available on our website ().
The procedures used to develop this document and those intended for its further maintenance are described in the CalConnect Directives.
In particular the different approval criteria needed for the different types of CalConnect documents should be noted. This document was drafted in accordance with the editorial rules of the CalConnect Directives.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. CalConnect shall not be held responsible for identifying any or all such patent rights. Details of any patent rights identified during the development of the document will be provided in the Introduction.
Any trade name used in this document is information given for the convenience of users and does not constitute an endorsement.
This document was prepared by Technical Committee UnitsML.
UnitsDB is a comprehensive database of units of measurement, quantities, dimensions, and prefixes that serves as the authoritative reference for the UnitsML framework.
UnitsDB provides a structured and standardized way to represent and reference measurement units and related concepts across various scientific, engineering, and technical domains.
UnitsDB is designed to support multiple applications, including:
Providing an authoritative source of measurement units for scientific and technical documentation
Supporting unit conversion systems
Enabling semantic interoperability between different systems that work with measurement data
This specification defines the data models, structures, and normalization rules for UnitsDB. It is intended for developers implementing UnitsML, database administrators managing UnitsDB installations, and contributors who wish to extend or modify the database.
By following this specification, implementers and users of UnitsDB can ensure consistent and accurate representation of measurement units and related concepts across different applications and domains.
This document specifies the data models, structures, and normalization rules for
UnitsDB, the authoritative database of measurement units, quantities,
dimensions, and prefixes for the UnitsML framework. This document applies to UnitsDB version 1.0.0.
The specification defines:
The overall architecture of UnitsDB
The data models for unit systems, prefixes, quantities, dimensions, and units
The format and structure of YAML files that comprise the database
The normalization rules for data integrity and consistency
The relationships between different entities in the database
A test suite for validation of UnitsDB implementations
This document:
Does not specify implementation details for using UnitsDB in applications
Does not define algorithms for unit conversions or dimensional analysis (though the data provided supports these operations)
Does not provide a comprehensive list of all units, quantities, dimensions, and prefixes (these are provided in the actual database)
This specification is intended for:
Developers implementing UnitsML systems
Developers managing UnitsDB database instances
Contributors extending or modifying the UnitsDB database
Standards developers referencing UnitsDB
The specification enables interoperable representation of measurement units and related concepts across different applications, domains, and systems.
For the purposes of this document, the following terms and definitions apply.
reference quantity with which other quantities of the same kind are compared to express their value
Units are identified by conventionally assigned names and symbols.
The meter is a unit of length.
property of a phenomenon, body, or substance, where the property has a magnitude that can be expressed by a number and a reference
Length, mass, and time are quantities.
expression of the dependence of a quantity on the base quantities of a system of quantities as a product of powers of factors corresponding to the base quantities
In UnitsDB, dimensions are represented as combinations of seven base dimensions: length (L), mass (M), time (T), electric current (I), thermodynamic temperature (Θ), amount of substance (N), and luminous intensity (J).
name or symbol that, when attached to a unit, multiplies that unit by a specified factor
The kilo prefix multiplies a unit by 1000.
set of units used to express quantities in a consistent manner
International System of Units
SI is the modern form of the metric system and is the most widely used system of measurement.
unit of measurement of a base quantity in a given system of quantities
unit of measurement of a derived quantity in a given system of quantities
constraint that ensures the consistency, integrity, and standardization of data
formal description of the structure, attributes, and relationships of entities
The design and architecture of the UnitsDB adheres to the following principles.
Scientific accuracy and completeness
Interoperability
Declarative content
Ease of use and maintenance
Extensibility
UnitsDB adheres to the International System of Units (SI) and aims to facilitate accurate measurement across various domains towards international standards.
The database aims to accurately represent:
Base and derived units as defined by SI.
Information models used in the representation and realization of a digital units system.
Historical and non-SI units that are still in use.
UnitsDB supports interoperability through:
Simple realization of the database in human-readable formats
Globally unique identifiers
Support for presentational needs of units
Well-defined data models allowing straightforward serialization to various formats
UnitsDB maintains structural consistency through:
Well-defined data models for each entity type
Separation of concerns in information models
Explicit definitions of relationships between information models
UnitsDB applies data normalization principles to:
Eliminate redundancy in the database
Ensure data integrity across related entities
Simplify maintenance and updates
Support efficient querying and processing
Enable validation and consistency checking
UnitsDB supports interoperability through:
Use of industry-standard YAML for data representation
Clear separation of content from presentation
Consistent identifiers and cross-references
Support for multiple symbol representations (ASCII, Unicode, MathML, LaTeX, HTML)
Well-defined data models that can be mapped to various implementation formats
This interoperability enables UnitsDB to serve as a reference database for diverse applications and systems.
UnitsDB aims to provide users an easy to use information database while keeping it easy and simple to maintain.
Human-readable content facilitates inspection and understanding by humans and transparent review and validation of content
Automated validation and consistency checking
Allows incofmproation into software sytsemss
Efficient querying and filtering
Transformation to other formats and representations
UnitsDB is designed to be extensible to accommodate:
New units as they are defined, come into use or encoded historically
Additional quantities in emerging domains
New prefixes defined in the future
Domain-specific extensions and annotations
The UnitsDB architecture follows a modular design that organizes measurement-related concepts into distinct but interconnected data models. These data models are implemented as YAML files, with each file focusing on a specific aspect of the measurement system.
This section describes the overall architecture, the relationships between different entities, and how the lutaml-model language is used to define the data models.
UnitsDB is organized into five primary YAML files, each responsible for a different component of the measurement system.
Contains definitions of physical dimensions (length, mass, time, etc.)
Contains definitions of measurable quantities (length, velocity, force, etc.)
Contains definitions of measurement units (meter, second, newton, etc.)
Contains definitions of unit prefixes (kilo, milli, mega, etc.)
Contains definitions of unit systems (SI, non-SI) and their categories
Each file contains entries that follow a consistent model structure as defined using the lutaml-model language.
The UnitsDB architecture establishes explicit relationships between different entities to create a coherent measurement system:
The key relationships are described below.
Dimension ↔ Quantity: Each quantity has exactly one dimension, but multiple quantities can share the same dimension
Quantity ↔ Unit: Each quantity can be measured by multiple units, and each unit can measure multiple quantities (many-to-many relationship)
Unit ↔ Dimension: Each unit has exactly one dimension, which must match the dimension of the quantities it measures
Prefix ↔ Unit: Prefixes can be applied to units to create new prefixed units
UnitSystem ↔ Unit: Each unit belongs to a specific unit system
These relationships are implemented through cross-references between the different YAML files.
UnitsDB uses a consistent cross-reference mechanism to link entities across different files:
References to dimensions use the format #NISTdX (e.g., #NISTd1 for length).
References to quantities use the format #NISTqX (e.g., #NISTq1 for length).
References to units use the format #NISTuX (e.g., #NISTu1 for meter).
References to prefixes use the format #NISTpX_Y (e.g., #NISTp10_3 for kilo).
These cross-references create a web of relationships that maintain the integrity and coherence of the measurement system.
UnitsDB defines five primary classes.
Represents the mathematical concept of a physical dimension
Represents a measurable property with a specific dimension
Represents a reference for measuring quantities
Represents a multiplier for units
Represents a system of units (e.g., SI, non-SI)
Each class definition specifies the attributes that should be present in the corresponding YAML files.
UnitsDB does not use formal inheritance hierarchies, but it does establish conceptual hierarchies through relationships:
Base dimensions vs. derived dimensions: Derived dimensions are composed of combinations of base dimensions
Base quantities vs. derived quantities: Derived quantities reference dimensions that are combinations of base dimensions
Base units vs. derived units: Derived units are composed of combinations of base units
These hierarchies are reflected in the data structure rather than through formal inheritance mechanisms.
The UnitsDB architecture includes several extension points for future development:
Addition of new dimensions, quantities, units, prefixes, or unit systems
Enhancement of metadata for existing entities
Addition of conversion factors between units with the same dimension
Extension of symbol representations to support additional formats
Domain-specific annotations for specialized fields
These extension points allow UnitsDB to evolve while maintaining backward compatibility.
The lutaml-model class definitions are mapped to YAML structures in the database files.
For example, the Unit class defined in lutaml-model:
Maps to YAML entries like:
This mapping ensures that the YAML files conform to the defined data models while maintaining human readability.
When implementing UnitsDB for specific applications, several architectural considerations are important:
YAML parsing: Implementations should handle YAML 1.2 syntax correctly
Cross-reference resolution: Applications need to resolve references between entities
Validation: Implementations should validate entries against the defined models
Memory management: Depending on the application, different caching strategies may be appropriate
Query capabilities: Applications might need to support various ways to search and retrieve entities
These considerations influence how UnitsDB is integrated into larger systems and applications.
A unit system is a defined set of units.
UnitsDB differentiates unit systems in accordance to BIPM guidelines.
Units defined by the International System of Units (SI) as defined by the CGPM and described by the BIPM. SI units are the international standard for measurement. These are the 7 base units
Units that are not part of the SI system but are directly derived from SI units and therefore acceptable for use. Examples include traditionally used units like newton, pascal, joule, watt.
Units that are not part of the SI system, directly derived from SI units but are usually dimensionless or compound units and not accepted for international use. Examples include ppm, ppb, square meters.
Units that are not part of the SI system but are generally accepted for technical use. These units include imperial units like hour, minute, angstrom, watt hour.
Units that are not part of the SI system but are temporarily accepted for use in specific contexts. These units only include “are” and “hectare” for area.
Units that are not part of the SI system but are generally not accepted for technical use. These units include imperial units like foot, inch, mile, metric ton, and pound.
Prefixes are modifiers that act on units, they do not affect the units’ categorization in unit systems.
The UnitSystem model is defined in the LutaML data definition language.
The id field is a unique identifier for the unit system type. It indicates both the name of the system and the category of unit within that system. For example, SI_base refers to base units in the SI system.
The name field specifies the overarching unit system, either “SI” or “non-SI”.
The acceptable field is a boolean indicating whether units in this system are generally acceptable for use in scientific and technical documentation according to international standards.
The unit system data is stored in the unit_systems.yaml file with the following structure.
Unit systems in UnitsDB maintain relationships with other entities in the database, primarily units.
In the UnitsDB structure, each unit is associated with a unit system through the unit_system field in the Unit model. This link establishes the context for the unit and provides guidance on its appropriate usage.
For example, a unit like the meter would be associated with the SI_base unit system, indicating it is a base unit in the SI system and generally acceptable for use in scientific and technical documentation.
The unit_id field is a reference to the unit that is associated with the unit system. This field links the unit to its corresponding unit system, allowing for easy identification and categorization.
The unit_system_id field is a reference to the unit system that the unit belongs to. This field establishes the relationship between the unit and its unit system, providing context for its usage and interpretation.
The unit system relationship data is used in the units.yaml file with the following structure.
A prefix is a modifier that, when attached to a unit, multiplies that unit by a specified factor.
In UnitsDB, prefixes are used to create multiples and submultiples of units, allowing for the expression of quantities across a wide range of magnitudes.
The Prefix model is defined as follows.
The prefix data is stored in the prefixes.yaml file with the following structure:
The id field is a unique identifier for the prefix. The format follows a pattern of “NISTp” followed by the base and power of the prefix, separated by an underscore. For SI prefixes, the format is “NISTp10_X” where X is the power, which can be positive or negative. For binary prefixes, the format is “NISTp2_X”.
The name field contains the name of the prefix, such as “kilo”, “milli”, or “giga”.
The symbol field contains representations of the prefix symbol in different formats using the PrefixSymbols model.
The base field indicates the base of the exponentiation.
For SI prefixes, this is always 10.
For binary prefixes, it is 2.
The power field indicates the power to which the base is raised to obtain the multiplier for the prefix.
For example, a power of 3 with a base of 10 gives a multiplier of 103 = 1000.
The ascii field contains the ASCII text representation of the prefix symbol. This is the most basic representation and is suitable for plain text environments.
The html field contains the HTML representation of the prefix symbol. This may include HTML entities for special characters.
The mathml field contains the MathML representation of the prefix symbol and is a MathML string. This is for use within MathML-supported environments.
The latex field contains the LaTeX representation of the prefix symbol. This is for use within LaTeX documents or LaTeX-supported environments.
The unicode field contains the Unicode representation of the prefix symbol.
This is mainly for use within UnicodeMath or other Unicode-enabled environments. This allows for the representation of characters that may not be available in ASCII or HTML.
A quantity is a property of a phenomenon, body, or substance that can be quantified by measurement.
In UnitsDB, quantities provide the bridge between theoretical dimensions and practical units of measurement.
They represent physical properties like length, mass, time, speed, or energy, which can be measured using specific units.
There are two represented types of quantities in UnitsDB.
The fundamental quantities that cannot be derived from other quantities. The SI system defines seven base quantities: length, mass, time, electric current, thermodynamic temperature, amount of substance, and luminous intensity.
The dimension-independent quantities that are not associated with any physical dimension. These quantities are often used in mathematical or statistical contexts, such as probability, ratios, or pure numbers. While dimensionless quantities do not have a specific dimension, they can still be associated with a unit of measurement for semantic interoperability.
The ratio of two lengths is dimensionless, but it can be expressed as a quantity as a “ratio for lengths”.
The unit ‘parts-per-million’ (ppm) is a unit that measures a quantity that represents a ratio of one part of a substance to one million parts of the total mixture.
Quantities that are defined through algebraic relationships with other quantities, typically expressed as products of powers of base quantities. They can differ in units depending on their dependencies and can be used to express complex measures in a simplified form.
The Quantity model is defined as follows.
The quantity data is stored in the quantities.yaml file with the following structure:
The id field is a unique identifier for the quantity, typically in the format NISTqX where X is a number.
Each quantity has a unique ID that is used for cross-referencing throughout the UnitsDB system.
The dimension_url field contains a reference to the dimension associated with the quantity. This reference establishes the dimensional characteristics of the quantity and links it to the mathematical representation in the dimension model.
The quantity_type field indicates whether the quantity is a base quantity or a derived quantity, using the QuantityType enumeration.
The quantity_name field is a collection of strings that each represents a name for the quantity.
The first name in the array is the primary name, and any additional names are alternative names or synonyms.
“velocity” might have the synonym “speed”.
The unit_reference field is a collection of UnitReference objects that can be used to measure the quantity.
UnitsDB classifies quantities into different types based on their role in the system of physical quantities.
Base quantities are the fundamental physical quantities that cannot be derived from other quantities. They are defined independently and serve as the foundation for all other quantities.
The seven base quantities in the SI system form the foundation of all physical
measurements, and are currently defined in the UnitsDB. These quantity entries are protected entries in the UnitsDB.
The measurement of distance or dimension in one direction.
The measurement of the amount of matter in an object.
The measurement of duration or sequential events.
The flow of electric charge.
The measurement of thermal energy.
The number of entities (atoms, molecules, ions, etc.) in a system.
The measure of the power of light in a given direction.
A derived quantity is a physical quantity that is defined in terms of base quantities. Derived quantities are expressed as products of powers of base quantities, and they can be represented in terms of their dimensional relationships.
Derived quantities can be expressed in terms of base quantities using dimensional analysis.
For example, velocity is a derived quantity that can be expressed as length divided by time (L/T). Other examples of derived quantities include:
acceleration (NISTq13), which is expressed as length divided by time squared (L/T²)
force (NISTq14), which is expressed as mass times acceleration (M·L/T²)
pressure (NISTq15), which is expressed as force divided by area (M·L/T²·L²)
A quantity can be measured by multiple units, and this relationship is captured in the unit_reference field.
This many-to-many relationship allows:
Selection of appropriate units for a given quantity
Identification of all quantities that can be measured with a particular unit
Conversion between different units for the same quantity
For example, the quantity “length” (NISTq1) can be measured using units such as meter, foot, inch, mile, and yard.
The name field is a string that represents the name of the unit that can measure the quantity.
This field is optional
The url field is a string that contains a reference to the unit in the UnitsDB system.
A dimension is a physical quantity that can be measured.
According to the SI Brochure, a dimension is defined as “a physical quantity that can be expressed in terms of base quantities.” Dimensions are fundamental to the system of units and provide a framework for understanding and comparing different physical properties.
The SI standard defines the following dimensions and corresponding dimension symbols:
time (T)
length (L)
mass (M)
electric current (I)
absolute temperature (Θ)
amount of substance (N)
luminous intensity (J).
In UnitsDB, dimensions are represented as mathematical combinations of base dimensions, using the same approach as dimensional analysis in physics.
The Dimension model is defined as follows.
The dimension data is stored in the dimensions.yaml file with the following structure:
The id field is a unique identifier for the dimension, typically in the format NISTdX where X is a number. Each dimension has a unique ID that is used for cross-referencing throughout the UnitsDB system.
The dimensionless field is a boolean that indicates whether the dimension is dimensionless (true) or has a physical dimension (false or not present). Dimensionless quantities are pure numbers without units, such as ratios, angles, and counts.
Each dimension is composed of one or more base dimension components represented as a DimensionComponent object.
Each dimension can only have a maximum of one base dimension component of each type of the 7 base dimensions.
A dimension component represents a base quantity and its exponent (power) in the dimension.
The seven base quantities in SI are:
(NISTq1) length
(NISTq2) mass
(NISTq3) time
(NISTq4) electric current
(NISTq5) thermodynamic temperature
(NISTq6) amount of substance
(NISTq7) luminous intensity
The base_dimension field is an enumeration that specifies the base dimension represented by this component, with possible values listed in the BaseDimensionEnum model.
The power_numerator field is an integer that represents the exponent (power) of the base quantity in the dimension. This indicates how many times the base dimension is multiplied in the dimension formula.
A power of 2 indicates that the base dimension is squared.
For a dimension with a power of -1, it indicates the reciprocal of the base dimension.
The symbol field represents a general notation used for the dimension in various contexts.
For a dimension expressed with a power of 0, it indicates that the dimension is dimensionless.
The dim_symbols field is a collection of DimensionSymbol objects that represent the symbol representations of the dimension in different formats, in the DimensionSymbol model.
The BaseDimensionEnum model defines the enumeration of base dimensions according to the SI system. Each base dimension is represented by a unique identifier and has a corresponding definition.
The length base dimension represents the physical quantity of length.
The mass base dimension represents the physical quantity of mass.
The time base dimension represents the physical quantity of time.
The electric_current base dimension represents the physical quantity of electric current.
The thermodynamic_temperature base dimension represents the physical quantity of thermodynamic temperature.
The amount_of_substance base dimension represents the physical quantity of the amount of substance.
The luminous_intensity base dimension represents the physical quantity of luminous intensity.
The plane_angle base dimension represents the physical quantity of a plane angle. This is a special case that is not a base dimension in the SI system but is often treated as such in dimensional analysis.
The dimension representation symbols model defines the various symbol representations for a dimension. These symbols are used in different contexts, such as mathematical expressions, HTML rendering, and LaTeX typesetting.
This model is only used for base dimensions defined in the BaseDimensionEnum model. Only base dimensions have officially assigned dimension symbols by the SI System.
The id field is a unique identifier for the symbol representation.
The ascii field contains the ASCII text representation of the symbol. This is the most basic representation and is suitable for plain text environments.
The html field contains the HTML representation of the symbol. This may include HTML entities for special characters.
The mathml field contains the MathML representation of the symbol. This is an XML-based markup language for representing mathematical notations.
The latex field contains the LaTeX representation of the symbol.
The unicode field contains the Unicode representation of the symbol.
The dimension representation symbols data is stored in the dimensions.yaml file with the following structure:
A unit is a reference quantity adopted by convention with which other quantities of the same kind can be compared to express their value.
In UnitsDB, units are organized according to their system (SI, non-SI), dimensionality, and relationships to other units.
The Unit model is defined as follows.
The unit data is stored in the units.yaml file with the following structure.
The unit symbols model describes the various representations of a unit in different formats, such as ASCII, HTML, MathML, LaTeX, and Unicode. Each representation is associated with a unique identifier.
The id field is a unique identifier for the symbol representation. This field is used to reference the symbol in various contexts, such as documentation and software applications.
The ascii field contains the ASCII text representation of the symbol. This field is used in plain text environments where special characters may not be available.
The html field contains the HTML representation of the symbol. This may include HTML entities for special characters, allowing for proper rendering in web browsers and other HTML-compatible environments.
The mathml field contains the MathML representation of the symbol. This field is used in mathematical contexts where precise formatting is required. MathML is an XML-based markup language for describing mathematical notation.
The latex field contains the LaTeX representation of the symbol. This field is used in typesetting environments where LaTeX is applied.
The unicode field contains the Unicode representation of the symbol. This field is used in environments that support Unicode encoding, such as within UnicodeMath.
The dimension reference model describes the relationship between the unit and a dimension. Each unit is associated with a dimension, which defines the physical quantity that the unit measures.
The dimension_url field is a reference to the dimension that the unit is associated with. This field links the unit to its corresponding dimension, allowing for easy identification and categorization.
The unit system reference model describes the relationship between the unit and a unit system. Each unit is associated with a unit system, which defines the context in which the unit is used.
The type field is a string that represents the type of the unit system. This field indicates the classification of the unit system, such as SI base, SI derived, or non-SI.
The name field is a string that represents the name of the unit system. This field provides a human-readable label for the unit system, allowing for easy identification and categorization.
The SI root unit derivation reference model describes the relationship between the unit and the SI root units. Each unit may be associated with one or more SI root units, which define the base units from which the unit is derived.
This only applies for the units that are SI_derived_special.
The id field is a string that represents a unique identifier for the SI base unit.
The prefix field is a string that represents the prefix for the SI base unit, if applicable.
The power field is an integer that indicates the power of the SI base unit in the derived unit. Defaults to 1.
The root unit reference model describes the relationship between the unit and the root units. Each unit may be associated with one or more root units, which define the base units from which the unit is derived.
If the unit is a root unit, where the root field is set to true, then the root unit reference model points to the unit itself.
The unit field is a string that represents the short name of the root unit.
The power_numerator field is an integer that represents the power of the numerator. This field indicates the exponent of the root unit in the numerator of the derived unit.
The prefix field is a string that represents the prefix for the unit, if applicable. This field indicates any prefix that modifies the root unit, such as “k” for kilogram or “m” for milli.
This indicates that the micron is derived from the meter with a prefix of “u” (micro). Hence the micron, a unit of length, is represented as the unit “meter” with a prefix “u” (effectively, “micrometer”) in the SI system.
This indicates that the kilogram-force second squared per meter is derived from these root units:
kilogram-force (with a prefix of “k”, effectively “gram_force” with a prefix “k”)
second (with a power of 2)
meter (with a power of -1)
The unicode representation would therefore be kgf·s²m⁻¹.
The quantity reference model describes the relationship between the unit and the quantity. Each unit may be associated with one or more quantities, which define the physical quantities that the unit measures.
Data file normalization in UnitsDB refers to the process of organizing and structuring the YAML files that make up the database to ensure consistency, non-redundancy, and integrity. These rules help maintain the quality and reliability of the data while facilitating its use in various applications.
All model instances within UnitsDB (dimensions, quantities, units, prefixes, etc.) must have unique identifiers. These identifiers follow a consistent pattern:
Dimensions: NISTdX (e.g., NISTd1)
Quantities: NISTqX (e.g., NISTq1)
Units: NISTuX (e.g., NISTu1)
Prefixes: NISTpX_Y (e.g., NISTp10_3)
Where X and Y are numeric values.
References between entities must use consistent paths:
References to dimensions use the format #NISTdX
References to quantities use the format #NISTqX
References to units use the format #NISTuX
These references create a web of relationships that maintain the integrity of the database.
The data is organized in a hierarchical manner that reflects the logical relationship between entities:
Dimensions provide the mathematical foundation for quantities
Quantities are physical properties that can be measured
Units are references for measuring quantities
Prefixes modify units to create new scales
Each dimension entry must have a unique identifier.
Dimensionless entries must be explicitly marked with dimensionless: true.
Base quantity components must specify their powerNumerator and symbol.
When dim_symbols are provided, they must include representations in all standard formats (ascii, html, mathml, latex, unicode).
Each quantity entry must have a unique identifier.
Each quantity must reference a valid dimension via dimension_url.
Quantity types must be either base or derived.
Quantity names must be provided as an array, with the primary name first.
Unit references must include both a name and a URL to the unit.
Each unit entry must have a unique identifier.
Each unit must reference a valid dimension via dimension_url.
The root field must be explicitly set to either true or false.
If prefixed is true, there must be a prefix specified in the root_units section.
Unit names must be provided as an array, with the primary name first.
Unit symbols must include representations in all standard formats.
The unit_system field must specify both a valid type and name.
For derived units, the root_units section must properly enumerate all component units with their powers.
Quantity references must include both a name and a URL to the quantity.
Each prefix entry must have a unique identifier.
The base field must be either 10 (for SI prefixes) or 2 (for binary prefixes).
The power field must be an integer.
Prefix symbols must include representations in all standard formats.
Each unit system entry must have a unique identifier.
The name field must be either “SI” or “non-SI”.
The acceptable field must be explicitly set to either true or false.
Each quantity must reference a valid dimension.
Multiple quantities can reference the same dimension.
Each unit must be associated with at least one quantity.
Multiple units can measure the same quantity.
The dimension of a unit must match the dimension of the quantities it measures.
Prefixed units must reference valid prefixes.
The same prefix can be applied to multiple units.
For the base unit of mass (kilogram), prefixes are applied to “gram” rather than “kilogram”.
The data integrity model defines checks and validations that should be performed to ensure the overall consistency and correctness of the UnitsDB database.
To ensure the integrity of the UnitsDB data, the following checks should be performed:
All reference links must point to valid entities.
Circular references must be avoided.
No duplicate identifiers should exist within each entity type.
Derived dimensions must have consistent exponents in their base quantity components.
Units must have dimensions that match their referenced quantities.
All required fields must be present for each entity type.
The change management model defines rules and procedures for updating the UnitsDB data files while maintaining backward compatibility and data integrity.
When updating the UnitsDB data files, the following rules should be applied:
Existing identifier values should not be changed to avoid breaking existing references.
New entities should be assigned new, unique identifiers.
When an entity needs to be deprecated, it should be marked as such rather than removed.
Major structural changes to the data format should be accompanied by a version increment and appropriate documentation.
This section defines models that are shared across multiple components of the UnitsDB specification. These common models provide consistent structures and behaviors that are reused throughout the database.
The Symbol representation model is used across various entities in UnitsDB to provide consistent representation of symbols in different formats.
Symbol representations are used in:
Unit symbols
Dimension symbols
Prefix symbols
Each representation includes multiple formats to support different output contexts:
Plain text (ASCII)
Web display (HTML)
Mathematical typesetting (MathML, LaTeX)
Unicode-enabled environments
Symbol representation for the meter unit:
The Cross-reference model establishes a consistent mechanism for linking entities across different files in UnitsDB.
Cross-references follow a consistent pattern:
References to dimensions use the format #NISTdX (e.g., #NISTd1 for length)
References to quantities use the format #NISTqX (e.g., #NISTq1 for length)
References to units use the format #NISTuX (e.g., #NISTu1 for meter)
References to prefixes use the format #NISTpX_Y (e.g., #NISTp10_3 for kilo)
Cross-reference to the length dimension from a quantity:
This appendix provides a test suite for UnitsDB, comprising examples from the YAML files that demonstrate the correct implementation of the data models and normalization rules.
These test cases verify the correct implementation of the Dimension model:
These test cases verify the correct implementation of the Quantity model:
These test cases verify the correct implementation of the Unit model:
These test cases verify the correct implementation of the Prefix model:
These test cases verify the correct implementation of the UnitSystem model:
The following tests verify the integrity of cross-references across the UnitsDB files:
This test verifies that each dimension is referenced by at least one quantity:
This test verifies that each quantity references valid units:
This test verifies that each unit references valid quantities:
The following techniques can be used to validate UnitsDB data files:
YAML schema validation can be performed to ensure that each file adheres to the expected structure. This includes checking:
Required fields are present
Field types are correct
Enumerated values are valid
Reference integrity validation ensures that all cross-references between entities are valid:
Verify dimension references from quantities
Verify unit references from quantities
Verify quantity references from units
Verify dimension references from units
Dimensional consistency validation ensures that the dimensional relationships are mathematically consistent:
Verify that units have the same dimension as their referenced quantities
Verify that derived dimensions have correct combinations of base dimensions
Verify that derived units have correct combinations of root units
Validation of normalization rules ensures that the data adheres to the specific formatting and structural requirements:
Verify naming conventions for identifiers
Verify the structure of root_units for derived units
Verify the correct use of prefixes
Verify unit system categorization
These test cases and validation techniques provide a comprehensive framework for ensuring the integrity and correctness of the UnitsDB database.
The following documents are referred to in the text in such a way that some or all of their content constitutes requirements 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.