Dick, I used to take Zantac, which contained ranitidine, which turned out to have problems. Now there's something *called* Zantac that doesn't have ranitidine. Perhaps if enough people developed peanut allergies, Mars would release something called "Snickers" but had cashews (a tree nut) instead of peanuts (a legume) and wouldn't trigger peanut allergies.
My point is that if there is a Zantac v1 and a Zantac v2, or a Snickers v1 and Snickers v2, it's important for the consumer to know which is which. Using a relationship is bad if it attempts to change the content of a package. Properties inherently cannot change, so Element IDs must be version-specific. But if you use relationships to represent the ingredients of "Snickers" without specifying the version, the consumer can't tell whether what's on the shelf is safe or not. Dave On Wed, Jan 19, 2022 at 8:01 AM Dick Brooks < [email protected]> wrote: > Dave, > > > > As Kate will tell you, I’m not a SBOM big picture guy, I > focus on the use of SBOM in a very narrow niche, software supply chain risk > assessments following NIST SP 800-161 Appendix F (EO 14028 implementation > guidelines), called C-SCRM. > > > > In a C-SCRM risk assessment, the relationship of components > isn’t as important as the software contents “SBOM ingredients list” that’s > used to search for vulnerabilities. > > > > To use an analogy, a snickers bar contains peanuts, which > someone with a peanut allergy needs to know, regardless of how it’s > constructed. The maker of snickers bars absolutely must know the > relationship of peanuts and all of the other ingredients, in the same way > that a software needs to know how the component pieces fit together. > > > > The discussion of relationships is germane to software vendor product > construction, but I don’t see this information being needed for a C-SCRM > risk assessment because the question being asked is “does a component have > vulnerabilities”, regardless of where it was implanted in the construction > of a software package. There are other factors that a software consumer may > want to know, i.e. provenance and pedigree of a component. > > > > Just my .02 > > > > Thanks, > > > > Dick Brooks > > *Never trust software, always verify and report! > <https://reliableenergyanalytics.com/products>* ™ > > http://www.reliableenergyanalytics.com > > Email: [email protected] > > Tel: +1 978-696-1788 > > > > *From:* [email protected] <[email protected]> *On Behalf Of > *David Kemp > *Sent:* Wednesday, January 19, 2022 7:17 AM > *To:* SPDX-list <[email protected]> > *Subject:* [spdx-tech] Relationships, properties, and syntactic sugar > > > > Gary observed that when using RDF serialization, reasoning about > relationships is significantly more difficult than reasoning about > properties. But that is not a serialization problem, it is just a symptom > of a model problem that applies to all serializations. > > The most basic question a logical model must answer is: "Does an Element > have a well-defined value?", or "Given an Element, what is its value?" If > an Element does not have a fixed value, then it is not hashable, and we > agreed long ago that Elements are immutable. > > The logical model must make it possible to answer the question "Does > Package X CONTAIN File Y" regardless of serialization. If Microsoft > creates Package Element X and defines it to contain File Elements 1, 2, 3, > and Acme creates a Relationship Element saying Microsoft's Package Element > X CONTAINS File Element 4, it is not a valid question to ask "Does Package > X CONTAIN File 4?" The question doesn't make sense and cannot be reasoned > about. The only valid questions are "Does Microsoft's *description* of > Package X at 15:34 on Tuesday contain File 4", and "Does Acme's > *description* of Package X at 19:23 on Wednesday contain File 4". The > answer to the first is a definite No, and to the second a definite Yes. > > Microsoft can create various Elements describing Package X at various > times with different contained files. One Package Element can list Files > 1, 2 and be marked "incomplete", but that is a different Element from one > that lists Files 1, 2, and 3 whether marked "incomplete" or not. So using > properties as syntactic sugar for relationships is valid ONLY when the > relationship and its "from" Package Element were minted together, i.e. have > the identical creation info. Relationships created 1 second after the > Package are not syntactic sugar for properties of that Package, they could > only be sugar for properties of a different Package Element created 1 > second after the first. > > > > The Package Element IRI must conceptually depend on the package's > major/minor/patch number, commit ID etc., if the files contained in the > package are different. > > So I would say it's a best practice to NOT duplicate properties with > relationships, because allowing them requires desugaring relationships into > properties based on identical creation info. If the practice isn't > forbidden you'll always have to deal with explaining "Acme's description of > Microsoft's package X as it existed at this point in the build chain". > > Dave > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#4311): https://lists.spdx.org/g/Spdx-tech/message/4311 Mute This Topic: https://lists.spdx.org/mt/88532578/21656 Group Owner: [email protected] Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
