Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions metanorma.yml
Original file line number Diff line number Diff line change
Expand Up @@ -3,6 +3,7 @@ metanorma:
source:
files:
- sources/asciiunits/document.adoc
- sources/unitsdb/document.adoc
# - sources/unitsml-guide/document.adoc
# - sources/unitsml-incorporation/document.adoc
# - sources/unitsml-ubl-ndr-subset/document.adoc
Expand Down
4 changes: 0 additions & 4 deletions sources/unitsdb-spec/sections/02-normrefs.adoc

This file was deleted.

File renamed without changes.
Original file line number Diff line number Diff line change
Expand Up @@ -4,6 +4,8 @@ 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.

NOTE: This document applies to UnitsDB version 1.0.0.

The specification defines:

* The overall architecture of UnitsDB
Expand All @@ -15,15 +17,16 @@ The specification defines:

This document:

* Does not specify the software implementation details for using UnitsDB in applications
* 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
* Database administrators managing UnitsDB installations
* 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.
The specification enables interoperable representation of measurement units and
related concepts across different applications, domains, and systems.
4 changes: 4 additions & 0 deletions sources/unitsdb/sections/02-normrefs.adoc
Original file line number Diff line number Diff line change
@@ -0,0 +1,4 @@
[bibliography]
== Normative references

* [[SI_Brochure,BIPM SI Brochure]], SI Brochure: The International System of Units (SI), 9th edition, 2019, BIPM
Original file line number Diff line number Diff line change
@@ -1,5 +1,6 @@
== Architecture


=== General

The UnitsDB architecture follows a modular design that organizes
Expand All @@ -13,26 +14,27 @@ models.

=== File organization

UnitsDB is organized into five primary YAML files, each responsible for a different component of the measurement system:

UnitsDB is organized into five primary YAML files, each responsible for a
different component of the measurement system.

*`dimensions.yaml`::
`dimensions.yaml`::
Contains definitions of physical dimensions (length, mass, time, etc.)

*`quantities.yaml`::
`quantities.yaml`::
Contains definitions of measurable quantities (length, velocity, force, etc.)

*`units.yaml`::
`units.yaml`::
Contains definitions of measurement units (meter, second, newton, etc.)

*`prefixes.yaml`::
`prefixes.yaml`::
Contains definitions of unit prefixes (kilo, milli, mega, etc.)

*`unit_systems.yaml`::
`unit_systems.yaml`::
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.


=== Entity relationships

The UnitsDB architecture establishes explicit relationships between different entities to create a coherent measurement system:
Expand All @@ -56,12 +58,16 @@ The UnitsDB architecture establishes explicit relationships between different en
+----------------------------------------------------------------+
----

The key relationships are:
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.
Expand All @@ -70,42 +76,40 @@ These relationships are implemented through cross-references between the differe

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)
* 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.
These cross-references create a web of relationships that maintain the integrity
and coherence of the measurement system.

=== Lutaml-model language
=== Information models

UnitsDB uses the lutaml-model language to define the structure of each data model. The lutaml-model language provides a human-readable way to define class-like structures with attributes and relationships.
UnitsDB defines five primary classes.

The general pattern for a lutaml-model class definition is:
`Dimension`::
Represents the mathematical concept of a physical dimension

[source,lutaml]
----
class ClassName {
attribute attributeName, AttributeType {
definition "Description of the attribute"
}
// Additional attributes...
}
----
`Quantity`::
Represents a measurable property with a specific dimension

`Unit`::
Represents a reference for measuring quantities

UnitsDB defines five primary classes using lutaml-model:
`Prefix`::
Represents a multiplier for units

* `Dimension`: Represents the mathematical concept of a physical dimension
* `Quantity`: Represents a measurable property with a specific dimension
* `Unit`: Represents a reference for measuring quantities
* `Prefix`: Represents a multiplier for units
* `UnitSystem`: Represents a system of units (e.g., SI, non-SI)
`UnitSystem`::
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.
Each class definition specifies the attributes that should be present in the
corresponding YAML files.

=== Inheritance hierarchies

UnitsDB does not use formal inheritance hierarchies, but it does establish conceptual hierarchies through relationships:
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
Expand All @@ -127,7 +131,10 @@ These extension points allow UnitsDB to evolve while maintaining backward compat

=== Model mapping to YAML

The lutaml-model class definitions are mapped to YAML structures in the database files. For example, the `Unit` class defined in lutaml-model:
The lutaml-model class definitions are mapped to YAML structures in the database
files.

For example, the `Unit` class defined in lutaml-model:

[source,lutaml]
----
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -2,32 +2,14 @@

=== General

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.
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.

=== Normalization principles model

==== General

The normalization principles model defines the fundamental rules that govern how data is organized and referenced throughout the UnitsDB database.

==== Key normalization principles

[source,lutaml]
----
class NormalizationPrinciple {
attribute principle_type, String {
definition "Type of normalization principle"
}
attribute description, String {
definition "Description of the principle"
}
attribute examples, Array {
definition "Examples demonstrating the principle"
}
}
----

===== Unique identifiers
==== Unique identifiers

All model instances within UnitsDB (dimensions, quantities, units, prefixes, etc.) must have unique identifiers. These identifiers follow a consistent pattern:

Expand All @@ -38,7 +20,7 @@ All model instances within UnitsDB (dimensions, quantities, units, prefixes, etc

Where `X` and `Y` are numeric values.

===== References
==== References

References between entities must use consistent paths:

Expand All @@ -48,7 +30,7 @@ References between entities must use consistent paths:

These references create a web of relationships that maintain the integrity of the database.

===== Hierarchical organization
==== Hierarchical organization

The data is organized in a hierarchical manner that reflects the logical relationship between entities:

Expand All @@ -59,27 +41,6 @@ The data is organized in a hierarchical manner that reflects the logical relatio

=== File normalization model

==== General

The file normalization model defines specific rules for each YAML file in the UnitsDB database to ensure internal consistency and proper structure.

[source,lutaml]
----
class FileNormalization {
attribute file_name, String {
definition "Name of the YAML file"
}
attribute entity_type, String {
definition "Type of entity contained in the file"
}
attribute rules, Array {
definition "Normalization rules specific to this file"
}
}
----

==== File-specific normalization rules

===== dimensions.yaml

* Each dimension entry must have a unique identifier.
Expand Down Expand Up @@ -122,30 +83,6 @@ class FileNormalization {

=== Cross-file normalization model

==== General

The cross-file normalization model defines rules that govern relationships between entities across different files in the UnitsDB database.

[source,lutaml]
----
class CrossFileNormalization {
attribute relationship_type, String {
definition "Type of relationship between entities"
}
attribute source_entity, String {
definition "Source entity type"
}
attribute target_entity, String {
definition "Target entity type"
}
attribute rules, Array {
definition "Normalization rules for this relationship"
}
}
----

==== Cross-file normalization rules

===== Dimension-quantity relationships

* Each quantity must reference a valid dimension.
Expand Down Expand Up @@ -225,84 +162,3 @@ When updating the UnitsDB data files, the following rules should be applied:
* 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.

=== Normalized data examples

==== General

These examples demonstrate how properly normalized data should appear across the different UnitsDB files.

==== Example of normalized data

Here is an example of how normalized data should appear across the different files:

.dimensions.yaml (excerpt)
[source,yaml]
----
NISTd1:
length:
powerNumerator: 1
symbol: L
dim_symbols:
- id: dim_L
ascii: L
html: "𝖫"
mathml: "<mi mathvariant='sans-serif'>L</mi>"
latex: "\\ensuremath{\\mathsf{L}}"
unicode: "\U0001D5AB"
----

.quantities.yaml (excerpt)
[source,yaml]
----
NISTq1:
dimension_url: "#NISTd1"
quantity_type: base
quantity_name:
- length
unit_reference:
- name: meter
url: "#NISTu1"
----

.units.yaml (excerpt)
[source,yaml]
----
NISTu1:
dimension_url: "#NISTd1"
short: meter
root: true
unit_system:
type: SI_base
name: SI
unit_name:
- meter
unit_symbols:
- id: m
ascii: m
html: m
mathml: "<mi mathvariant='normal'>m</mi>"
latex: "\\ensuremath{\\mathrm{m}}"
unicode: m
root_units:
- unit: meter
power_numerator: 1
quantity_reference:
- name: length
url: "#NISTq1"
----

.prefixes.yaml (excerpt)
[source,yaml]
----
NISTp10_3:
name: kilo
symbol:
ascii: k
html: k
latex: k
unicode: k
base: 10
power: 3
----

This example demonstrates the proper normalization of data across the files, with consistent identifiers, references, and structured data.
Loading