This document defines the Baseline-information Obligations Mapping ontology, a bridging vocabulary of stable, persistent identifiers for the minimum elements required in a Bill of Materials (BOM) and regulatory compliance standards.
This document is a draft version of the Baseline-information Obligations Mapping ontology v0.1.0, developed to support crosswalk mappings between information requirement specs and exchange formats.
The BOM Ontology bridges the gap between various regulatory obligations, information requirement specifications, and technical serialization formats (such as SPDX and CycloneDX).
It functions in four distinct layers:
bom:) acting as a pivot for all mappings.Rather than mapping $N \times M$ combinations of formats and specifications directly, all specifications are mapped via a "one-hop" alignment: Source Concept → Bridge Concept → Exchange Format Field.
The ontology defines type classes to categorize specifications and properties to model constraints and normative provisions:
| Term | Type | Description |
|---|---|---|
| bom:InfoRequirementSpec | owl:Class | A standard or guidance document specifying which baseline information MUST/SHOULD be present. |
| bom:RegulatorySpec | owl:Class | A legally binding instrument that mandates compliance-related obligations (e.g. EU AI Act). |
| bom:ExchangeFormatSpec | owl:Class | A technical specification defining a serialization format for compliance document content. |
| bom:valueConstraint | owl:ObjectProperty | Links a concept to a SKOS Collection of allowed values for the mapped field. |
| bom:provisionType | owl:ObjectProperty | The normative strength of a requirement element (SHALL, SHOULD, etc.) linking to the provision type vocabulary. |
Normative requirements are categorized into six provision types aligned with ISO/IEC Directives Part 2 §7 and RFC 2119:
| Concept | Keywords | Definition |
|---|---|---|
| bom:Requirement | SHALL, MUST, REQUIRED | Mandatory; absence makes the document non-conformant with the source specification. |
| bom:ConditionalRequirement | SHALL IF, MUST IF | Mandatory when specific conditions hold (e.g. if the data exists). |
| bom:Recommendation | SHOULD, RECOMMENDED | Highly recommended; valid reasons may exist to omit the element, but consequences must be understood. |
| bom:Permission | MAY, OPTIONAL | Completely optional; absence has no conformance implication. |
| bom:PossibilityAndCapability | CAN | Statement of technical possibility or capability rather than a requirement. |
| bom:ExternalConstraint | MUST (External) | Mandatory due to external legal requirements or regulations outside the requirement specification. |
The neutral bridge concepts are grouped by structural metadata category and domain profiles:
bom:MetadataDocument)| Concept | Preferred Label | Definition |
|---|---|---|
| bom:doc-author | Document author | The agent (person, organisation or tool) that produced the document. |
| bom:doc-identifier | Document identifier | A persistent URI that uniquely identifies this SBOM document instance. |
| bom:doc-integrity | Document integrity | A cryptographic signature, hash or other integrity mechanism allowing verification of the document. |
| bom:doc-lifecycle-stage | Document lifecycle stage | The lifecycle stage or context in which the SBOM was generated (e.g. build, analysed, deployed, runtime). |
| bom:doc-primary-component | Document primary component | The top-level component or system that the SBOM describes (the SBOM's root subject). |
| bom:doc-spec-version | Document spec version | The name and/or version of the SBOM data format specification used (e.g. 'SPDX 3.1', 'CycloneDX 1.7'). |
| bom:doc-timestamp | Document timestamp | The date and time at which the document was created. |
| bom:doc-tool-name | Document tool name | The name of the software tool used to generate the SBOM. |
| bom:doc-tool-version | Document tool version | The version of the software tool used to generate the SBOM. |
| bom:doc-version | Document version | A version identifier for this specific instance of the document. |
bom:MetadataComponent)| Concept | Preferred Label | Definition |
|---|---|---|
| bom:ai-application-domain | AI application domain | The domain(s) or application area(s) for which the AI system is intended (e.g. healthcare, finance, autonomous driving). |
| bom:ai-data-flow | AI data flow | A description of how data flows into, through and out of the AI system. |
| bom:ai-data-usage | AI data usage | A description of how data (including personal or sensitive data) is used by the AI system. |
| bom:ai-io-prop | AI input/output property | The types, modalities and constraints on data accepted as input and produced as output by the AI system or model. |
| bom:ai-model-card | AI model card | A structured document (model card) covering model details, intended uses, evaluation factors, risks and mitigations. |
| bom:ai-model-parameters | AI model parameters | The trained weights, biases, checkpoints, and optimizer state of the AI model. |
| bom:ai-model-prop | AI model property | AI-specific technical properties of a model: type, explainability, autonomy level, safety risk assessment and energy profile. |
| bom:ai-out-of-scope-usage | AI out-of-scope usage | Uses or scenarios for which the AI system or model is explicitly not intended and should be avoided. |
| bom:ai-perf-metric | Operational perf metric | Operational and functional perf indicators for the AI system (e.g. accuracy, F1 score, latency, throughput, energy consumption). |
| bom:ai-training-prop | AI training property | Characteristics of the model's training process: hyperparameters, data pre-processing steps, fine-tuning configuration and energy consumption. |
| bom:component-comment | Component comment | Free-text comments, notes or annotations concerning the component. |
| bom:component-copyright | Component copyright | The copyright notice or holder information for the component. |
| bom:component-criticality | Component criticality | The security or operational criticality level assigned to the component. |
| bom:component-description | Component description | A free-text description of the component's purpose, architecture or key characteristics. |
| bom:component-documentation | Component documentation | Technical reports, research papers, manuals, or configuration files describing the component. |
| bom:component-environmental-impact | Component environmental impact | Environmental impact metrics for the component, including energy consumption, resource use, and carbon footprint. |
| bom:component-eol-date | Component end-of-life date | The official end-of-life or end-of-support date for the component. |
| bom:component-external-ref | Component external reference | Links to supplementary resources for the component such as model cards, research papers, repositories, or registries. |
| bom:component-filename | Component filename | The actual filename of the component (without path) as it appears in the delivered artifact. |
| bom:component-hash | Component hash | A cryptographic hash of the component artifact (algorithm + digest) for integrity verification. |
| bom:component-identifier | Component identifier | A stable, unique identifier for the component -- typically a PURL (Package URL), SPDX ID, DOI or similar. |
| bom:component-license | Component license | The declared or concluded license under which the component is distributed (expressed as an SPDX license expression or similar). |
| bom:component-name | Component name | The human-readable name of a software, AI model or dataset component. |
| bom:component-origin | Component origin | The source, origin or manufacturing location of the component (e.g. open source, proprietary, third-party). |
| bom:component-patch-status | Component patch status | The patch, update or remediation status of the component. |
| bom:component-source-code | Component source code | Source code files or packages for training, inference, evaluation, or data pre-processing. |
| bom:component-supplier | Component supplier | The organisation or person that supplied or distributed the component. |
| bom:component-timestamp | Component timestamp | The date and time the component was built or officially released. |
| bom:component-usage-restriction | Component usage restriction | Legal, contractual or operational restrictions on the usage of the component. |
| bom:component-version | Component version | A version or release identifier for a specific snapshot of the component. |
| bom:dataset-data-card | Dataset data card | A structured document (data card) providing summary statistics and details about training datasets, features, instances, and intended uses. |
| bom:dataset-provenance | Dataset provenance | Information about how, when and where the dataset was collected, updated and pre-processed. |
| bom:dataset-sensitivity | Dataset sensitivity | The sensitivity classification of the dataset, including whether it contains personal or sensitive data and its confidentiality level. |
| bom:dataset-statistical-prop | Dataset statistical property | Statistical characteristics of the dataset including size, noise levels, known biases and class distributions. |
| bom:dataset-type | Dataset type | The type(s) or modality of data in the dataset (e.g. image, text, audio, tabular) and its size. |
| bom:infra-hardware | Infrastructure hardware | The hardware required to operate the AI system, including specialised accelerators (GPUs, TPUs, NPUs). |
| bom:infra-software | Infrastructure software | The software environment required to run the AI system: container images, OS, ML frameworks and runtime libraries. |
| bom:is-archive | Is archive | Whether the component is an archive that combines multiple sub-components (e.g. a zip, rpm, container image). |
| bom:is-executable | Is executable | Whether the component is an executable file (compiled binary, interpreted script, or shared library). |
| bom:is-structured | Is structured | Whether the component is a structured archive whose internal component metadata is still recoverable (e.g. zip, tar, container image) vs an unstructured archive such as a firmware image. |
| bom:security-compliance | Security compliance | The security standards, regulations or frameworks the AI system has been assessed against or conforms to (e.g. EU AI Act, ISO/IEC 42001, NIST AI RMF). |
| bom:security-controls | Security controls | The security controls implemented on the AI system (e.g. access controls, encryption, audit logging). |
| bom:security-metric | Security metric | Quantitative security evaluation metrics and decision thresholds (e.g. adversarial robustness scores, CVSS scores). |
| bom:security-policy | Security policy | References to the supplier's vulnerability-disclosure policy, security.txt or coordinated-disclosure process. |
| bom:security-vuln-ref | Vulnerability reference | References to known vulnerabilities (CVEs) and their assessment status (VEX) for the AI system and its components. |
bom:MetadataRelationship)| Concept | Preferred Label | Definition |
|---|---|---|
| bom:rel-contains | Contains relationship | A relationship indicating one component contains another. |
| bom:rel-depends-on | Depends on relationship | A relationship indicating one component depends on another. |
| bom:rel-trained-on | Trained on relationship | A relationship indicating a model was trained on a specific dataset. |
bom:CollectionSoftware)| Concept | Preferred Label | Definition |
|---|---|---|
| bom:component-filename | Component filename | The actual filename of the component (without path) as it appears in the delivered artifact. |
| bom:component-source-code | Component source code | Source code files or packages for training, inference, evaluation, or data pre-processing. |
| bom:is-archive | Is archive | Whether the component is an archive that combines multiple sub-components (e.g. a zip, rpm, container image). |
| bom:is-executable | Is executable | Whether the component is an executable file (compiled binary, interpreted script, or shared library). |
| bom:is-structured | Is structured | Whether the component is a structured archive whose internal component metadata is still recoverable (e.g. zip, tar, container image) vs an unstructured archive such as a firmware image. |
bom:CollectionAI)| Concept | Preferred Label | Definition |
|---|---|---|
| bom:ai-application-domain | AI application domain | The domain(s) or application area(s) for which the AI system is intended (e.g. healthcare, finance, autonomous driving). |
| bom:ai-data-flow | AI data flow | A description of how data flows into, through and out of the AI system. |
| bom:ai-data-usage | AI data usage | A description of how data (including personal or sensitive data) is used by the AI system. |
| bom:ai-io-prop | AI input/output property | The types, modalities and constraints on data accepted as input and produced as output by the AI system or model. |
| bom:ai-model-card | AI model card | A structured document (model card) covering model details, intended uses, evaluation factors, risks and mitigations. |
| bom:ai-model-parameters | AI model parameters | The trained weights, biases, checkpoints, and optimizer state of the AI model. |
| bom:ai-model-prop | AI model property | AI-specific technical properties of a model: type, explainability, autonomy level, safety risk assessment and energy profile. |
| bom:ai-out-of-scope-usage | AI out-of-scope usage | Uses or scenarios for which the AI system or model is explicitly not intended and should be avoided. |
| bom:ai-perf-metric | Operational perf metric | Operational and functional perf indicators for the AI system (e.g. accuracy, F1 score, latency, throughput, energy consumption). |
| bom:ai-training-prop | AI training property | Characteristics of the model's training process: hyperparameters, data pre-processing steps, fine-tuning configuration and energy consumption. |
bom:CollectionDataset)| Concept | Preferred Label | Definition |
|---|---|---|
| bom:dataset-data-card | Dataset data card | A structured document (data card) providing summary statistics and details about training datasets, features, instances, and intended uses. |
| bom:dataset-provenance | Dataset provenance | Information about how, when and where the dataset was collected, updated and pre-processed. |
| bom:dataset-sensitivity | Dataset sensitivity | The sensitivity classification of the dataset, including whether it contains personal or sensitive data and its confidentiality level. |
| bom:dataset-statistical-prop | Dataset statistical property | Statistical characteristics of the dataset including size, noise levels, known biases and class distributions. |
| bom:dataset-type | Dataset type | The type(s) or modality of data in the dataset (e.g. image, text, audio, tabular) and its size. |
bom:CollectionInfra)| Concept | Preferred Label | Definition |
|---|---|---|
| bom:infra-hardware | Infrastructure hardware | The hardware required to operate the AI system, including specialised accelerators (GPUs, TPUs, NPUs). |
| bom:infra-software | Infrastructure software | The software environment required to run the AI system: container images, OS, ML frameworks and runtime libraries. |
bom:CollectionSecurity)| Concept | Preferred Label | Definition |
|---|---|---|
| bom:component-criticality | Component criticality | The security or operational criticality level assigned to the component. |
| bom:component-patch-status | Component patch status | The patch, update or remediation status of the component. |
| bom:security-compliance | Security compliance | The security standards, regulations or frameworks the AI system has been assessed against or conforms to (e.g. EU AI Act, ISO/IEC 42001, NIST AI RMF). |
| bom:security-controls | Security controls | The security controls implemented on the AI system (e.g. access controls, encryption, audit logging). |
| bom:security-metric | Security metric | Quantitative security evaluation metrics and decision thresholds (e.g. adversarial robustness scores, CVSS scores). |
| bom:security-policy | Security policy | References to the supplier's vulnerability-disclosure policy, security.txt or coordinated-disclosure process. |
| bom:security-vuln-ref | Vulnerability reference | References to known vulnerabilities (CVEs) and their assessment status (VEX) for the AI system and its components. |