Move additionalInformation to Element

[bact]

There can be cases that there are (well-defined) set of information available in a domain but there is no equilavent slot in SPDX model to record it.

Using comment and other string-based properites could be a workaround but it is not very machine readable.

Hardware profile (new in 3.1) tries to solve that with additionalInformation (DictionalEntry) and additionalInformationSpecificaiton (Specification) properties.

• additionalInformation can be used to record the available information as is, if there is no other suitable SPDX slot.
• additionalInformationSpecification, if provided, can help on how to read the additionalInformation

Currently, /Core/Action and /Hardware/Hardware have these properties, but there is a need to have similar property in /AI/AIPackage too (see bact/pitloom#62 (comment)) as features in AI system/model grow very fast and we can't have everything specified in the model.

With that, move those additionalInformation and additionalInformationSpecificaiton to Core and share them among classes.

(Note there were two additionalInformation, one in Core and one in Hardware. Remove one in Hardware)

No backward compatibility issue as all of the properties are introduce in 3.1

see also: https://schema.org/additionalProperty

[bact]

@bennetkl @rgopikrishnan91 This will allow us flexibility to record things that we like to see in the AI model but may not available yet in 3.0/3.1.

[bennetkl]

Couple of things that I would be concerned with including a new additional info to core for 3.0.1. Firstly no new fields until ISO/IEC certification would be my recommendation. The ISO group will likely have a 'few' changes that they want incorporated into 3.0.1 and if there are 'new' fields, it could delay the certification. Secondly, Element is the base class of the entire SPDX graph. Adding additionalInformation (a DictionaryEntry — i.e., an arbitrary key-value bag) and additionalInformationSpecification to Element creates a universal escape hatch. ie. Every SPDX object can now carry arbitrary, unstandardized metadata. This directly undermines the purpose of having a structured ontology: interoperability comes from agreed property definitions. It was also mentioned using comment and other string-based properties could be a workaround but it is not very machine readable." But isn't but additionalInformation as a DictionaryEntry is a key-value map. If the keys are not standardized, it is not machine-readable. It is merely structured non-interoperability. A comment field with a JSON string inside it is equally "machine readable" to anyone who knows the schema; a DictionaryEntry with unknown keys is equally unreadable to anyone who doesn't. My recommendation don't make this change until after ISO certification and then maybe talk with Kate and others, not sure that fields that will be introduced in 3.1 don't really need to go into 3.0.2 IMHO.

[bact]

This is for 3.1.

The field is already in 3.1-RC1.
The proposal here is to move it from Hardware to Core.

[bact]

Discussed in 20 May 2026 AI WG call.

• The group agreed that it will be useful to have a generic additional properties to record information that there is no standard fields yet in the model.
• The use case of Hardware is information that is domain-specific, need to record but would be too much to have them all in SPDX 3 model (and it will be challenging to have them all because each domain may have different usages of the same term).
• Additionally, with SPDX spec development cycle of 2+ years, the AI development will go faster and it will be useful to have somewhere to "park" the information.
• A concern is made though, that this property may be "misused" or overloaded if we are not careful enough.
  • A sentence or a paragraph should be added to the additionalInformation description to encourage implementers to find a standard property that suit the information first, because using this one.
• Also a comment that maybe we don't want to have this at the Element level, but instead specifically attaches the property to a certain number of classes (Action, AIPackage, DatasetPackage, Hardware, for example; those that may need domain-specific additional information).

[kestewart]

Need to be clear when to use this vs Comment vs Extension.
Detailed review needed.

[bact]

Discussed again in 5 Aug 2026 AI WG call.

• additionalInformation is somewhere between description property and a full extension (using Extension profile)
• description property is easy to use (and universal for all Element) but limited to string, with no structure
• Extension allows full detailed structure, but requires construction of full classes/properties
  • May also requires support of Extension from an SPDX processor (not part of standard SPDX model)
• additionalInformation is a simple key-value pair (DictionaryEntry, key is string, value is also string). Provided more structure than a string, yet still simple to use.
  • With additionalInformationSpecification, information on how to interpret the keys and the values can also be provided.
• One of AIPackage use case is to store information available from the AI model metadata like ones in https://onnx.ai/onnx/repo-docs/MetadataProps.html - they can fit naturally in key-value pairs.

--

My additional interpretation/explanation:

• description is "a detailed description of the Element. It may also be extracted from the Element itself."
  • intrinsic characteristics (what the Element is or does)
• comment is "an optional field for creators of the Element to provide comments to the readers/reviewers of the document."
  • extrinsic meta-information (what the document creator wants to tell the reader/reviewer about the SPDX record)
  • The spec can use this comment field for a specific purpose. (For example, Build suggests "ExternalIdentifier of type "urlScheme" may be used to identify build logs. In this case, the comment of the ExternalIdentifier should be "LogReference".")
• additionalInformation is likely be about intrinsic characteristics (similar to description)