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.2.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 Sec.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 collections:
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 digital signature attributable to the document author, or another integrity mechanism, giving assurance that the claimed signatory signed the document and that it was not modified after signing. |
| 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 or its data was most recently updated. |
| bom:doc-tool-name | Document tool name | The name of the software tool used by the document author to generate or amend the SBOM. |
| bom:doc-tool-version | Document tool version | The version of the software tool identified by the document tool name. |
| bom:doc-version | Document version | A version identifier designated by the document author to specify a change in the document from a previously identified version, or to indicate that it is the first version. |
bom:MetadataComponent)| Concept | Preferred Label | Definition |
|---|---|---|
| bom:component-code-repository | Component code repository | A URL to the source code repository for the component. |
| 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-description | Component description | A free-text description of the component's purpose, architecture or key characteristics. |
| bom:component-distribution | Component distribution channel | The method(s) through which the component is made available (e.g. API access, open-source repository, enterprise software suite, device firmware), including how it can be accessed and the level of access granted (e.g. weights-level or black-box access). |
| 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-hash | Component hash | A cryptographic hash of the executable component artifact (algorithm + digest) for integrity verification. |
| bom:component-identifier | Component identifier | One or more stable, unique identifiers for the component used to identify it or serve as a look-up key for relevant databases -- typically a PURL (Package URL), CPE, SWID, SWHID, OmniBOR gitoid, DOI, UUID or SPDX ID. |
| bom:component-instruction-for-use | Component instruction for use | A URL to the instructions for use of the component. |
| bom:component-landing-page | Component landing page | A URL to a web page with more information about the component. |
| 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 assigned by the component producer to 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-producer | Component producer | The entity that creates, defines and identifies the component (its originator or manufacturer), as distinct from a distributor and from the author of the document describing it. |
| 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, such as licence conditions or an acceptable-use policy. |
| bom:component-version | Component version | An identifier used by the component producer to specify a change in the component from a previously identified version, or to indicate that it is the first version. |
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-derived-from | Derived from relationship | A relationship indicating that a component (software, AI model or dataset) is largely derived from, forked from, fine-tuned from, distilled from or otherwise descended from another component. |
| 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 sector, field or application area in which the AI system or model is deployed or designed to operate (e.g. healthcare, finance, cybersecurity, autonomous driving; real-time vs batch application). |
| bom:ai-capability | AI capability | What the AI model or system is able to do: the tasks it performs and the application areas it was designed for. |
| bom:ai-compute | AI computational resources | The computational resources consumed to train or run the model: the measured, estimated or benchmarked amount of computation (e.g. floating point operations), the training duration (wall-clock and hardware time) and the methodology used to measure or estimate them. |
| bom:ai-context-length | AI context length | The maximum input (and, where distinct, output) length the model can process in one interaction, typically in tokens. |
| 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-hyperparameter | AI hyperparameter | The hyper-parameters of the model and of its training configuration (e.g. number of layers, hidden size, learning rate, batch size, optimiser). |
| bom:ai-input-modality | AI input modality | The modality or modalities and data types the AI system or model accepts as input (e.g. text, image, audio, video, structured data), including size limits where applicable. |
| bom:ai-input-preprocessing | AI input preprocessing | The pre-processing applied to input data before inference (e.g. the tokenizer used by a language model, image normalisation, feature extraction, prompt templates). |
| bom:ai-intended-use | AI intended use | The use(s) for which the AI system or model is intended by its provider, including the specific context and conditions of use, as stated in the instructions for use, promotional or sales material and technical documentation. |
| 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-learning-type | AI learning type | The learning paradigm used to train the model: supervised, unsupervised, self-supervised, semi-supervised, reinforcement learning, or a combination. |
| bom:ai-limitation | AI limitation | The known limitations, weaknesses, failure modes or conditions under which the AI model or system should not be relied upon. |
| bom:ai-model-architecture | AI model architecture | The architecture of the model: structural family (encoder-decoder, encoder-only, decoder-only), network type (transformer, CNN, RNN, LSTM, decision tree, mixture of experts) and named architecture (ResNet, VGG, GPT, Llama). |
| 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, architecture, size, hyper-parameters, explainability, autonomy level, safety risk assessment and energy profile. |
| bom:ai-model-size | AI model size | The total number of trainable parameters of the model (or the range within which it falls), optionally together with the storage size of the model artifact. |
| bom:ai-model-type | AI model type | The broad class of the model: parametric (neural network) vs non-parametric (clustering, k-nearest neighbours, decision tree), generative vs discriminative. |
| bom:ai-openness-category | AI openness category | Which parts of the AI model are made openly available and under open terms: weights (open weight), architecture and code (open architecture / open source), training data (open data) and training process or recipe (open training); or a composite openness class such as the Model Openness Framework classes I to III. |
| bom:ai-out-of-scope-usage | AI out-of-scope usage | Uses, contexts or scenarios for which the AI system or model is explicitly not intended, or which the provider restricts or prohibits, and which should be avoided. |
| bom:ai-output-modality | AI output modality | The modality or modalities and data types the AI system or model produces as output (e.g. text, image, audio, video, structured data), including size limits where applicable. |
| 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-post-training-technique | AI post-training technique | The post-training or continual-learning techniques applied after pre-training: fine-tuning stages, instruction tuning, RLHF, RLAIF, reinforcement-learning optimisation methods (DPO, PPO, GRPO), distillation, continual learning. |
| bom:ai-training-prop | AI training property | Characteristics of the model's training process: learning paradigm, post-training techniques, data pre-processing steps, fine-tuning configuration and energy consumption. |
bom:CollectionDataset)| Concept | Preferred Label | Definition |
|---|---|---|
| bom:dataset-availability | Dataset availability | Whether and how the dataset can be obtained by others: publicly available for direct download, available through queries, behind a registration or click-through agreement, reassembled by scraping script, or private to the producer. |
| bom:dataset-collection-method | Dataset collection method | How the data was gathered or acquired (e.g. web crawling, commercial agreements, user contributions, sensors, surveys, licensed purchase). |
| bom:dataset-confidentiality-level | Dataset confidentiality level | The confidentiality classification of the data points in the dataset, i.e. how widely the content may be shared (e.g. Traffic Light Protocol clear, green, amber, amber+strict, red). |
| bom:dataset-copyright-status | Dataset copyright status | Whether the dataset contains third-party copyright-protected content, and the rights or opt-out status attached to it. |
| 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-domain | Dataset domain | The subject domain or field of knowledge of the data contained in the dataset (e.g. financial data, medical records, legal text, satellite imagery). |
| bom:dataset-format | Dataset format | The data structure, encoding or serialisation format in which the dataset is stored or distributed (e.g. JSON, XML, CSV, Parquet, TFRecord, image container formats). |
| bom:dataset-lifecycle-role | Dataset lifecycle role | The role the dataset plays in the AI model lifecycle or training pipeline: pre-training, fine-tuning, post-training alignment, validation, testing, model or system evaluation, benchmarking, context extension, retrieval or grounding. |
| bom:dataset-modality | Dataset modality | The modality or modalities of the data in the dataset (e.g. text, image, audio, video, 3D, tabular, time series, graph). |
| bom:dataset-personal-information | Dataset personal information | Whether the dataset contains personal data or personally identifiable information, and any anonymisation or pseudonymisation applied. |
| bom:dataset-preprocessing | Dataset preprocessing | The pre-processing, post-processing, curation, filtering, cleaning, de-duplication and labelling or annotation steps applied to the data after collection. |
| bom:dataset-provenance | Dataset provenance | Information about how, when and where the dataset was collected, updated and pre-processed. |
| bom:dataset-sensitive-category | Dataset sensitive data category | The categories of sensitive, regulated or protected data present in the dataset other than personal data as such (e.g. financial records, medical records, biometric data, national-security related data, export-controlled data). |
| 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-source | Dataset source | The origin of the dataset: the sources, organisations or individuals that contributed, created or curated the data. |
| bom:dataset-statistical-prop | Dataset statistical property | Statistical characteristics of the dataset including size, noise levels, known biases and class distributions. |
| bom:dataset-synthetic-method | Dataset synthetic data method | For synthetic or partly synthetic datasets, the method, model or tool used to generate the data (e.g. generated by a named model, simulation, augmentation). |
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. |
Per-standard files state how binding each concept is with a provision type and, for composite elements, how its sub-elements combine with an aggregation value:
bom:provision-types)| Concept | Preferred Label | Keywords | Definition |
|---|---|---|---|
| bom:Requirement | Requirement | MUST, REQUIRED, SHALL | The element SHALL be present in every conformant document. Absence makes the document non-conformant with the source standard. Corresponds to ISO/IEC Directives Part 2 'requirement' (verbal form: shall) and RFC 2119 MUST / SHALL / REQUIRED. |
| bom:ConditionalRequirement | Conditional requirement | MUST IF, SHALL IF | The element SHALL be present when a stated condition holds (e.g. the information exists and the SBOM format can represent the data field). An extension of the ISO/IEC 'requirement' provision type scoped to a specific condition. RFC 2119 has no dedicated keyword; expressed as MUST with an explicit condition. |
| bom:Recommendation | Recommendation | RECOMMENDED, SHOULD | The element SHOULD be present. There may be valid reasons to omit it in particular circumstances, but the full implications must be understood and weighed. Corresponds to ISO/IEC Directives Part 2 'recommendation' (verbal form: should) and RFC 2119 SHOULD / RECOMMENDED. |
| bom:Permission | Permission | MAY, OPTIONAL | The element MAY be present. Absence has no conformance implication. Corresponds to ISO/IEC Directives Part 2 'permission' (verbal form: may) and RFC 2119 MAY / OPTIONAL. |
| bom:PossibilityAndCapability | Possibility and capability | CAN | Expresses that an SBOM element or feature can be represented (a statement of technical capability or possibility), not a normative obligation. Corresponds to ISO/IEC Directives Part 2 'possibility and capability' (verbal form: can). Has no RFC 2119 equivalent. |
| bom:ExternalConstraint | External constraint | MUST | The element must be present due to an obligation imposed by an external law, regulation, or normative document outside the scope of the SBOM information requirement specification itself. Corresponds to ISO/IEC Directives Part 2 'external constraint' (verbal form: must, distinct from shall). Has no RFC 2119 equivalent (RFC 2119 treats MUST and SHALL as synonyms; ISO does not). |
bom:aggregation-types)| Concept | Preferred Label | Keywords | Definition |
|---|---|---|---|
| bom:AnyOf | Any of | The composite element is satisfied when at least one of its skos:narrower sub-elements is present. Used where the source standard lists the sub-elements as examples of what the element may contain. | |
| bom:AllOf | All of | The composite element is satisfied only when every one of its skos:narrower sub-elements is present. Used where the source standard enumerates the sub-elements as mandatory parts. |