The canonicalization team discussed several approaches to handling
relationships that we thought should be brought to a larger group for
thought.
*Background*: SPDX 2.3 defines a large number of relationship types that
will be brought forward to version 3, including:
DESCRIBES
DESCRIBED_BY
CONTAINS
CONTAINED_BY
DEPENDS_ON
DEPENDENCY_OF
DEPENDENCY_MANIFEST_OF
BUILD_DEPENDENCY_OF
...
EXAMPLE_OF
GENERATES
GENERATED_FROM
...
PATCH_FOR
PATCH_APPLIED
COPY_OF
FILE_ADDED
FILE_DELETED
FILE_MODIFIED
...
- The version 3 Relationship element is asymmetric - *from* 1 Element
*to* 1..* Elements.
- The description relationship is symmetric - A DESCRIBES B is
semantically identical to B DESCRIBED_BY A.
- The copy relationship is commutative - A COPY_OF B is semantically
identical to B COPY_OF A.
*Problem*: Canonicalization should have a single way of representing any
combination of relationships between elements. Although it would be ideal
to discard one relationship type from each symmetric pair, the fact that
the relationship element is asymmetric makes that impossible: A DESCRIBES
[B,C,D] cannot be replaced by {B,C,D] DESCRIBED_BY A.
*Options:*
1. Status quo: ignore the problem, keep all the existing types, don't
worry about semantics
2. Make all relationships 1 to 1: This allows one of each symmetric pair
to be discarded, but causes the number of relationship elements to explode
when the "n" in 1..n is large.
3. Make the relationship element symmetric by allowing both 1..n and
n..1: DESCRIBED_BY can be discarded while supporting both A DESCRIBES
[B,C,D] and [B,C,D] DESCRIBES A use cases.
#3 is the desired outcome, but there are several model options to achieve
it:
3a. Define the Relationship element to have properties from [1..*] and 1
[1..*] but include explanatory text prohibiting many-to-many relationships:
either from or to must have one element
3b. Define a "direction" flag in the Relationship element with values
"inbound" and "outbound", and redefine the element properties to be
direction agnostic: x is 1..1, y is 1..*, outbound is from x to y and
inbound is from y to x. This works, but is a bit convoluted to explain.
3c. Define two Relationship elements: Relationship_out and
Relationship_in. Relationship out would have the current from 1 to 1..*
properties, and Relationship_in would have properties from 1..* to 1.
We did not identify additional mechanisms to allow symmetric relationship
type pairs to be pruned to a single type, but others may be possible. We
are unanimous that pruning pairs is the goal.
I am opposed to option 3a - the model itself should define that
many-to-many relationships are not allowed. Allowing them in the model but
prohibiting them in separate text is lazy, error-prone, and puts
enforcement of the text on the backs of implementers rather than tools.
I prefer option 3c - it does mean the model needs one more box, but it
avoids some convoluted logic within 3b's single Relationship box.
Thoughts and suggestions?
Regards,
David
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#4743): https://lists.spdx.org/g/Spdx-tech/message/4743
Mute This Topic: https://lists.spdx.org/mt/93147542/21656
Group Owner: [email protected]
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
