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 (#4399): https://lists.spdx.org/g/Spdx-tech/message/4399
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]]
-=-=-=-=-=-=-=-=-=-=-=-


Reply via email to