Gary, If there is an opportunity to use references for compactness within serialized data (for example, using an 8 bit (256 color) palette out of a 24 or 48 bit color space in an image) the lookup table keys would need to be small (log-base-2 of the table size) to be effective. For that reason I think URIs would be ineffective and should be disallowed. That is somewhat equivalent to URIs being relative within the document namespace, but it's misleading to phrase it that way because 1) using a URI implies that it is referenceable from other namespaces, and 2) there is a tendency to want to make IRIs "readable" by including things like file names. That temptation is removed by requiring references to be lookup table indices.
That said, I'd like to see a use case for where compactness is possible. NamespaceMap is already an indexed lookup table from prefix to namespace. Dave On Sat, Mar 12, 2022 at 3:28 PM Gary O'Neall <[email protected]> wrote: > Hi Dave, > > > > The data type is a useful concept, but we may want to allow references > within the serialization unit solely for the purpose of compactness. > > > > That said – I need to think about the pros and cons a bit more and I’m > interested in other’s views on the topic. > > > > Regards, > > Gary > > > > *From:* David Kemp <[email protected]> > *Sent:* Saturday, March 12, 2022 8:49 AM > *To:* Gary O'Neall <[email protected]> > *Cc:* Sean Barnum <[email protected]>; SPDX-list <[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]> > 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] > > 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 (#4404): https://lists.spdx.org/g/Spdx-tech/message/4404 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]] -=-=-=-=-=-=-=-=-=-=-=-
