I like the simplicity model. Allows for plug-in style model. Oh you want to do hardware? Here you go. Oh you want to design a model for medical devices? Here’s a template, knock yourself out!
Get Outlook for iOS<https://aka.ms/o0ukef> ________________________________ From: [email protected] <[email protected]> on behalf of Alexios Zavras via lists.spdx.org <[email protected]> Sent: Thursday, June 10, 2021 3:52:15 AM To: Gary O'Neall <[email protected]> Cc: 'Sean Barnum' <[email protected]>; [email protected] <[email protected]> Subject: Re: [spdx-tech] Identity refactoring OK, going to other extreme towards simplification… Do we want to consider that our Core model will only have a simple “Identity” (a simple string, which might be an email or not) and everything else (Person, Organization, Tool, Agent, Address, etc.) are in an optional identity Area_of_Interest / Namespace? ?? -- zvr From: Gary O'Neall <[email protected]> Sent: Wednesday, 9 June, 2021 18:22 To: 'David Kemp' <[email protected]>; Zavras, Alexios <[email protected]> Cc: 'Sean Barnum' <[email protected]>; [email protected] Subject: RE: [spdx-tech] Identity refactoring I also agree on referencing other standards rather than (re)creating some of this challenging work. Just one additional consideration – when we adopt these other standards, we also adopt any complexity that comes along with it. For example, in SPDX 2.0 we incorporated W3C pointers<https://www.w3.org/WAI/ER/Pointers/WD-Pointers-20090202> for how we reference code snippets. There is a proposal to replace this well-established albeit complex vocabulary with a simple positive integer property in SPDX 3.0. With the #1 complaint on SPDX being the complexity, we should be careful we don’t complicate the model in order to support use cases that are rarely used in practice. To use an analogy from Physics, we don’t need a model that includes quantum effects, quarks and leptons if all we want to describe is the effect of air friction on a moving vehicle. I would propose for any changes to the model where there would be an increase in complexity, we ask the following questions: * What use cases require the change? * Are these use cases important for SBOM consumers or suppliers? * Are there practical examples of these use cases being implemented today or planned to be implemented in the near future? * Is there a simpler approach to the model that satisfies the same use cases? * Is the increase in complexity worth supporting these additional use cases? Or, to put it another way, would this change increase adoption by supporting more use cases or decrease adoption by increasing the complexity for implementation? Gary From: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> On Behalf Of David Kemp Sent: Wednesday, June 9, 2021 7:39 AM To: Alexios Zavras <[email protected]<mailto:[email protected]>> Cc: Sean Barnum <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Subject: Re: [spdx-tech] Identity refactoring +1. Our wheelhouse is to design a document data structure that integrates smoothly with systems that are based on an ontology, not to design the ontology itself. Dave On Wed, Jun 9, 2021 at 3:53 AM Alexios Zavras <[email protected]<mailto:[email protected]>> wrote: Thanks, Sean, for the very interesting discussion yesterday. I’d very much like to get it correctly. On the other hand, I’ve started to think that this is definitely not our core work and I’d hate for us to spend countless amount of hours trying to solve the complicated issues of identity/email/agent/etc. Therefore… instead of us defining classes for all (many) of this stuff, can we point to some other ontology and use their classes? We are planning to do so in a number of other cases, anyway – what is “URL”, what is “String”, etc. You did mention another comprehensive ontology that already deals with “Account”, “EmailAddress”, etc. Shouldn’t we simply point to that? -- zvr Intel Deutschland GmbH Registered Address: Am Campeon 10, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de<http://www.intel.de> Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#4070): https://lists.spdx.org/g/Spdx-tech/message/4070 Mute This Topic: https://lists.spdx.org/mt/83401493/21656 Group Owner: [email protected] Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
