Generalize *Version

[bact]

We have quite a number of "version" properties, some are introduced in 3.1 RC1. Wonder if a generic /Core/version property could be sufficient for few of these.

1. /SimpleLicensing/licenseListVersion (3.0)
2. /Core/specVersion (3.0)
3. /Software/packageVersion (3.0)
4. /Security/vexVersion (3.0)
5. /Core/processVersion (3.1)
6. /Hardware/itemVersion (3.1) - used in /Hardware/ProductSpecification
7. /Hardware/hardwareVersion (3.1) - used in /Hardware/Hardware
8. Security/version (proposed here Adding certificate, key, and signature to security profile  #1224 for certificate format version)

Except (1) which has range as /Core/SemVer /Core/Version, the rest are xsd:string.

(1) and (2) are part of the internal working of SPDX infrastructure (SPDX License List data, spec-parser, and anything that will consume SPDX data), so shouldn't touch them.

[bact]

Note: With #1234, the /Core/SemVer has been renamed to /Core/Version.

[bact]

Compare these two SPARQL queries:

(1)

PREFIX spdx: <https://spdx.org/rdf/3.1/terms/>
PREFIX spdx-c: spdx:Core/

SELECT ?elementName ?version
WHERE {
    ?element spdx-c:name ?elementName .    
    ?element spdx-c:version ?version .
}

(2)

PREFIX spdx: <https://spdx.org/rdf/3.1/terms/>
PREFIX spdx-c: spdx:Core/
PREFIX spdx-hw: spdx:Hardware/
PREFIX spdx-ls: spdx:SimpleLicensing/
PREFIX spdx-s: spdx:Security/
PREFIX spdx-sw: spdx:Software/

SELECT ?elementName ?version
WHERE {
    ?element spdx-c:name ?elementName .
    { ?element spdx-c:processVersion ?version . }
    UNION
    { ?element spdx-c:specVersion ?version . }
    UNION
    { ?element spdx-hw:hardwareVersion ?version . }
    UNION
    { ?element spdx-hw:itemVersion ?version . }
    UNION
    { ?element spdx-ls:licenseListVersion ?version . }
    UNION
    { ?element spdx-s:vexVersion ?version . }
    UNION
    { ?element spdx-sw:packageVersion ?version . }
}

Also note that if model expands, query (1) will still work for any element modeled with the spdx-c:version property. While query (2) need an update (which is fair and unavoidable, if the version in that context/domain is really different from the generic version and have to be modeled differently).

[bact]

From 15 Apr 2026 Implementers call:

• Each domain/element may have their own way of enumerate version numbers/strings
• Generalize opportunity can occur when different elements, including from different domains (for example, /SimpleLicensing/licenseListVersion and /Core/specVersion), happen to share the same versioning schema (like SemVer)
• A generic version string can provide flexibility, and classes can decide how to use it when the version property is associated with the classes.
• While sharing and consistency in general can be useful, we should balance this well and avoiding organizational process that will slow down the development within each individual profile.