The only way to relate artifacts is via relationship nodes, the "containment" that is possible with the types that inherit from Collection is for grouping the metadata, it doesn't imply an artifact relationship. This was one of the things we did to remove confusion between packages and collections. Semantically it is similar to contains but for the SPDX elements themselves, not what the SPDX element describes.
Sent from Outlook<http://aka.ms/weboutlook> ________________________________ From: Dick Brooks <[email protected]> Sent: Saturday, August 20, 2022 11:12 AM To: William Bartholomew (CELA) <[email protected]>; 'SPDX-list' <[email protected]>; [email protected] <[email protected]> Subject: [EXTERNAL] RE: [spdx-tech] Canonicalization: Commutative and Symmetric Relationships Thanks for the insights. Is the default still “CONTAINS” when no relationship node is present? Thanks, Dick Brooks [cid:[email protected]] [cid:[email protected]] Active Member of the CISA Critical Manufacturing Sector, Sector Coordinating Council – A Public-Private Partnership Never trust software, always verify and report!<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Freliableenergyanalytics.com%2Fproducts&data=05%7C01%7Cwillbar%40microsoft.com%7Cf9272eb963f64c542d7e08da82d77bf0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637966159263500942%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=bYRh3Jecx0ZiVQFPPrCPSgtt%2FkMVi8b6GQnR8c1gw8s%3D&reserved=0> ™ http://www.reliableenergyanalytics.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.reliableenergyanalytics.com%2F&data=05%7C01%7Cwillbar%40microsoft.com%7Cf9272eb963f64c542d7e08da82d77bf0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637966159263656270%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=yzCNr6hmitnQL%2FeiSQTjKIsCuSHcfjLmesrropIZHFs%3D&reserved=0> Email: [email protected]<mailto:[email protected]> Tel: +1 978-696-1788 From: [email protected] <[email protected]> On Behalf Of William Bartholomew (CELA) via lists.spdx.org Sent: Saturday, August 20, 2022 1:52 PM To: SPDX-list <[email protected]>; [email protected] Subject: Re: [spdx-tech] Canonicalization: Commutative and Symmetric Relationships 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]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> on behalf of David Kemp via lists.spdx.org <[email protected]<mailto:[email protected]>> Sent: Saturday, August 20, 2022 9:57 AM To: SPDX-list <[email protected]<mailto:[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 (#4746): https://lists.spdx.org/g/Spdx-tech/message/4746 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]] -=-=-=-=-=-=-=-=-=-=-=-
