Expressing conformance constraints

[zvr]

Besides the purely "syntax" constraints (which property can appear in which class, for example, or even the cardinality of properties), it seems that there is need to express more "semantic" constraints.

This issue should be the place to discuss them, understand the requirements, and come up with a way to have them expresses in the model.

[zvr]

It should be pointed out that there is always the option of simply describing the restrictions in text!

The SPDXv2 specification has a number of such restrictions, simply expressed in the text.

We should try to have a balance between expressing all the restrictions formally so that they can be checked automatically and expressing them in understandable text.

[zvr]

From what I remember, there has already been mention of:

1. making optional properties mandatory
2. requiring Relationship element to exist, with a specific relationshipType and the from (or to) pointing to an element
3. same as (2) above, but the relationshipType being one of a set of valid values

[zvr]

1. making optional properties mandatory In general, changing cardinality of a property in a parent class. Example: /Software/File needs to specify that the property name of the ancestor class /Core/Element has to exist.

Solution: have an External properties restrictions restriction, providing fully qualified class name, property name, and characteristic to be changed (see example)

[goneall]

Note the related issue https://github.com/spdx/spdx-3-model/issues/463 requesting specific relationship restrictions.

Also note the specific syntax proposal: https://github.com/spdx/spdx-3-model/issues/462#issuecomment-1714744171

[goneall]

Based on prior tech call decisions, we will document the constraints in the profile markdown document for RC2.

It is still open on when / if we will translate the constraints into a SHACL/OWL file.

Moving this issue from RC2 to 3.0 release.

[jeff-schutt]

Here's a scenario that was uncovered during the security team meeting and may help clarify what's desired with the broader discussion/issue. This is a specific example of the third scenario described in https://github.com/spdx/spdx-3-model/issues/522#issuecomment-1773730473

Whereas they were present in prior diagrams, the most recent security model diagram has two classes without any properties listed. Both markdown files 1 model/Security/Classes/VexFixedVulnAssessmentRelationship.md 2 model/Security/Classes/VexUnderInvestigationVulnAssessmentRelationship.md ...document Constraints as restrictions in the text Description (as proposed above https://github.com/spdx/spdx-3-model/issues/522#issuecomment-1773729525) because the constraints can't currently be modeled or parsed.

The desire is to list the relationshipType property in each of the above markdown files and to constrain/restrict each of these markdown files to only one applicable value (fixedIn or underInvestigationFor) from the more expansive list of entries in model/Core/Vocabularies/RelationshipType.md.

[goneall]

On the SPDX Tech call - agreed to just use documentation in 3.0, we could add the validation in 3.1