I want to separate my thoughts on this from decisions that were already made
for 3.0, not saying we can't reopen them but the bar for that should be high.
The decisions that have already been made are:
1. We will identify each relationship type as either directional or
non-directional (DESCRIBES is directional, RELATED_TO is not).
2. For directional relationships from: X to: Y and from: Y to: X are not
equal, for non-directional relationships from: X to: Y and from: Y to: X are
equal.
3. We will remove the inverse relationship types for directional
relationships since the same can be achieved by inverting the to: and from:.
4. To decide which of the inverse relationships to keep we'll use two
criteria:
* The one where the to: direction makes more sense to be plural (since
as you point out the from: is singular).
* The most common direction (if these are in conflict, we'll need to
evaluate).
I think this helps with canonicalization because it clarifies the rules around
directionality and equality. The other thing to remember is that relationships
are elements, as a result they have unique identities, so from a
canonicalization perspective two relationships, even if they express the same
relations, will canonicalize differently because of the SPDXID of the
relationship element itself.
William
________________________________
From: [email protected] <[email protected]> on behalf of David
Kemp via lists.spdx.org <[email protected]>
Sent: Saturday, August 20, 2022 9:57 AM
To: SPDX-list <[email protected]>
Subject: [EXTERNAL] [spdx-tech] Canonicalization: Commutative and Symmetric
Relationships
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 (#4744): https://lists.spdx.org/g/Spdx-tech/message/4744
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]]
-=-=-=-=-=-=-=-=-=-=-=-
