Relationship to connect source code to a specification

[pellecchialuigi]

Current relationships set allow us to describe the link from the source code to the software specification using the relationship hasSpecification.
Actually I don't see a relationship type that allow us to describe the inverse relationship.

So I would like to see a hasImplementation and a corresponding IMPLEMENTATION_FOR in connected tools such as https://github.com/spdx/tools-python/blob/main/src/spdx_tools/spdx3/model/relationship.py

That because some workflow and tools can have focus on Software Specification and need a relationship definition parent (software specification) -> child (source code) that actually I don't see.

[goneall]

@pellecchialuigi - can you revers the from and to in the relationship?

[pellecchialuigi]

Unfortunately not in my case.
The tool I'm developing, is focusing on a reference document. Once defined a reference document, users can create work items and assign relationships from the work item to it (to the reference document).
That is general purpose and users can define any kind of reference documents, as example a software specification, source code, manual and whatever.

Imagine a user is using for a software component, as reference document, a software specification document.
User can be interested on creating work items such as Source Code work item that IMPLEMENTS the specification.
The relationships in this is added as part of the information of the work items and make more sense to have a relationship that specify the bottom to top dependency in my case.

I mean, tools can have constraints in the way are developed, that make not user friendly to use the reverse relationship.
So supporting the reverse relationships in the SPDX model can help to support such scenarios.
wdyt?

[zvr]

I am sorry, but I do not understand.

You are discussing adding a hasImplementation relationship, which will be the inverse of hasSpecification ? What is the gain of that?

If they are inverse, anytime you would like to add a Relationship from:Spec to:Software type:hasImplementation, you might as well create a Relationship from:Software to:Spec type:hasSpecification.

As a general rule we tried hard to avoid inverse relationships in SPDXv3, to simplify the data and the queries.

[pellecchialuigi]

Hi,
first of all thanks for your feedback.
In the python tool I see a loot of bi-directional relationships. Such as CONTAINED_BY, CONTAINS.
So here we have a single relationship handled on two directions.
For the Source Code the situation is a bit different.
The only relationships that can be used to connect the source code to something else are:
DOCUMENTATION_OF = auto()
GENERATED_FROM = auto()
OTHER = auto()
REQUIREMENT_DESCRIPTION_FOR = auto()
SPECIFICATION_FOR = auto()
TEST_CASE_OF = auto()
TEST_OF = auto()

But anyway we break the chain if we use other dependencies as PATCH_FOR
Requirement (REQUIREMENT_DESCRIPTION_FOR) -> Source Code <- (PATCH_FOR) patch file

We are not creating a one directional flow and tools need to be able to identify those things.

[zvr]

There is no CONTAINED_BY RelationshipType in https://spdx.github.io/spdx-spec/v3.0.1/model/Core/Vocabularies/RelationshipType/ only contains; perhaps you are referring to SPDXv2 ?

The problem with introducing inverse relationship types (and the main reason why we don't have them in SPDXv3) is that, if they are present, then each query has to be doubled, to account for the reverse relationship as well.

For example, if we had Contains and Contained_By, and we wanted to find everything contained in X, instead of:

find all Elements where there exists a Relationship from:X to:Element type:Contains

one would have to do:

find all Elements where there exists a Relationship from:X to:Element type:Contains and all Elements where there exists a Relationship from:Element to:X type:ContainedBy

Doubling every query is something we want to avoid.