Thanks Sean. Consider it done.
I’m quickly realizing that I lack the level of RDF/OWL knowledge needed to contribute to the V 3.0 effort. I’m an old Entity-Relationship (ERD) and XML guy so I tend to think in elements, attributes, types and tree/relational structures. I’ve notified Kate that I plan to focus on the V 2.3 efforts because I understand the current V 2 taxonomy and ontology for my specific use case “software risk assessments” and this is where I think I can contribute. I would be swinging outside of my strike zone with V 3.0. Fair winds and following seas on the V 3.0 initiative. Thanks, Dick Brooks <https://reliableenergyanalytics.com/products> Never trust software, always verify and report! ™ <http://www.reliableenergyanalytics.com/> http://www.reliableenergyanalytics.com Email: <mailto:[email protected]> [email protected] Tel: +1 978-696-1788 From: Sean Barnum <[email protected]> Sent: Tuesday, March 15, 2022 11:22 AM To: [email protected]; 'David Kemp' <[email protected]>; 'Gary O'Neall' <[email protected]> Cc: 'SPDX-list' <[email protected]> Subject: Re: [EXT] Re: [spdx-tech] Follow-up on non-Element classes >From one snark to another, you are forgiven. 😉 Now can you forgive my snarkiness? 😊 sean Sean Barnum C – 703-473-8262 <mailto:[email protected]> [email protected] We are here to change the world! <https://www.facebook.com/MITREcorp> <https://www.linkedin.com/company/mitre> <https://twitter.com/MITREcorp> <https://www.youtube.com/user/mitrecorp> <https://plus.google.com/+MitreOrgFFRDCs/posts> <http://www.mitre.org/> From: [email protected] <mailto:[email protected]> <[email protected] <mailto:[email protected]> > on behalf of Dick Brooks <[email protected] <mailto:[email protected]> > Date: Saturday, March 12, 2022 at 1:44 PM To: 'David Kemp' <[email protected] <mailto:[email protected]> >, 'Gary O'Neall' <[email protected] <mailto:[email protected]> > Cc: Sean Barnum <[email protected] <mailto:[email protected]> >, 'SPDX-list' <[email protected] <mailto:[email protected]> > Subject: [EXT] Re: [spdx-tech] Follow-up on non-Element classes I agree with Dave’s point about datatypes not being instantiated in a serialized artifact. Datatypes are used to describe and constrain usage of an item, but the datatypes themselves do not need to be included in a serialized artifact. What’s seen in the artifact is the “shadow effect” of these datatypes being applied to an item. I also want to apologize to everyone – I made a snarky comment during the meeting about the concept under discussion “being obvious” – my apologies. This is what happens when you spend way too much time modeling in XML, it becomes the solution to all data modeling and ontology problems. Please accept my apology for the snarky comment. Thanks, Dick Brooks <https://reliableenergyanalytics.com/products> Never trust software, always verify and report! ™ <http://www.reliableenergyanalytics.com/> http://www.reliableenergyanalytics.com Email: <mailto:[email protected]> [email protected] Tel: +1 978-696-1788 From: [email protected] <mailto:[email protected]> <[email protected] <mailto:[email protected]> > On Behalf Of David Kemp Sent: Saturday, March 12, 2022 11:49 AM To: Gary O'Neall <[email protected] <mailto:[email protected]> > Cc: Sean Barnum <[email protected] <mailto:[email protected]> >; SPDX-list <[email protected] <mailto:[email protected]> > Subject: Re: [spdx-tech] Follow-up on non-Element classes I agree with Gary and Sean that "references to these classes should be considered local to the serialization unit". I would go farther and say there are no references to these "classes", local or otherwise. In UML terms they are not classes at all, they are data types: https://www.omg.org/spec/UML/2.5.1/PDF Section 10.2: "DataTypes model Types whose instances are distinguished only by their value." Data types are simple classifiers, as opposed to classes (Section 11.4) which are structured classifiers. A data type has no ID or primary key by which it can be referenced. A multi-component datatype behaves like a primitive type (string) that can be split into components (e.g., comma-separated values). "34.9821, 72.4913, red" is just a string when serialized but can be logically modeled as a {latitude, longitude, color} structure, where none of the individual components is a unique ID. The only way to "reference" a primitive or structured data type is by supplying the entire value as the key. Regardless of serialization, at the logical model level data type instances cannot be referenced. I have no opinion on Gary's three approaches for serializing data types using RDF (https://www.w3.org/TR/rdf11-concepts/#section-Datatypes) as long as the value-only semantics is preserved across all serializations. Dave On Fri, Mar 11, 2022 at 9:44 PM Gary O'Neall <[email protected] <mailto:[email protected]> > wrote: Hi Sean and SPDX Tech Team, Following up on our call today, I think we uncovered an important issue on how to handle classes like ExternalReference, VerificationMethod and the recently discussed CreationInfo (which I would term “non-Element classes”) when viewed across different serialization units or documents. I would like to make some progress on this issue and I can participate asynchronously through email. I’ll be fully back online and re-joining the tech calls on the April 12th call. I agree with Sean’s assertion on the call that references to these classes should be considered local to the serialization unit of the SBOM (a.k.a. Document). For JSON, YAML, XML and Tag/Value this is pretty straight forward since (I believe) the only way to reference SPDX objects outside the document is using the ExternalMap which is restricted to Element classes. For RDF, it gets a bit complicated since a Subject or Object can be a URI or Anonymous/Blank. A URI can reference things external to the serialization unit. I can think of 3 ways to handle this: 1. Disallow use of URI’s types for references to these non-Element classes 2. Allow for URI’s in addition to blank nodes but restrict the URI’s to being within the serialization unit / Document namespace 3. Allow for any type of URI, but document that from an SPDX specification perspective they are only valid within the scope of the serialization unit My current preference is #2 above. There may be other options. Let me know what you think. Best regards, Gary ------------------------------------------------- Gary O'Neall Principal Consultant Source Auditor Inc. Mobile: 408.805.0586 Email: [email protected] <mailto:[email protected]> CONFIDENTIALITY NOTE: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material. Any review, re-transmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and destroy any copies of this information. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#4412): https://lists.spdx.org/g/Spdx-tech/message/4412 Mute This Topic: https://lists.spdx.org/mt/89725940/21656 Group Owner: [email protected] Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
