Dick, That is correct. To follow the RDF example, call it a fruit drawer in a refrigerator, with elements a: Apple, b: Banana, c: Cherry and d: Drawer.
D is the SpdxDocument Element of type Container in both v2 and v3 graphs. There is also a file that is the serialization of a graph using various syntaxes. In v2, the JSON serialized data is defined by a JSON schema, and the schema follows the v2 graph where you cannot serialize elements without including a container element. The serialized file conforms to a schema data type we now call TransferUnit. A schema is not a graph and a data type is not a graph node (meaning data types are not constrained to be Elements). V3 should be more flexible than v2. Elements with the same purpose still exist in v3, but the schema should define TransferUnit as a list, not a container. I believe the RDF type "collection" is a statement about a list. The list can include a container element or not as appropriate for the use case. Valid transfer units could carry the following elements: [a] [a, d] [b] [b, d] [a, b] [a, b, d] [a, b, c] [a, b, c, d] In SPDX v2, the only valid transfer units are those that include SpdxDocument element d. In SPDX v3, any combination of elements should be valid. It should be possible to serialize Element a. or Elements a and b, with or without Element d. Regards, David On Thu, Jul 28, 2022 at 7:20 AM Dick Brooks < [email protected]> wrote: > David, > > I have a different perspective. Using your draw analogy. IMO we are > creating a document that lists the items in the draw using element > constructs. > > Dick Brooks > > Sent from my iPhone > > On Jul 27, 2022, at 10:43 PM, David Kemp <[email protected]> wrote: > > > Gary, > > That sounds strange, but I have no experience with RDF serializers. > Consider a physical junk drawer resource, it contains a paper clip, a > button, an a pad of sticky notes. There is no way to make an RDF statement > that describes a list of [paper clip, button, and sticky notes] (3 nodes) > without also being forced to create a fourth node for the drawer? > > RDF makes a distinction between containers > <https://www.w3.org/TR/rdf-schema/#ch_containervocab> and collections > <https://www.w3.org/TR/rdf-schema/#ch_collectionvocab>. Based on one > example <https://www.w3.org/TR/turtle/#sec-examples> (#20 > <https://www.w3.org/TR/turtle/examples/example2.ttl>), the latter appears > that it *might *be an anonymous list of items, i.e. items a and b have > IRIs, but the collection of a and b doesn't have an IRI. Then again, I > might be totally confused. If a collection is not required to be a node, > then that is what I'm proposing for SpdxDocument. And if collection is not > a node, the Collection class should not have an open arrow to (be a > subclass of) Element, whereas if it were called Container it would. > > Regards, > David > > > On Wed, Jul 27, 2022 at 8:30 PM Gary O'Neall <[email protected]> > wrote: > >> Hi David, >> >> >> >> Agree with v3 having a more expressive graph – a definite improvement. I >> do recall in early days of SPDX development having an issue where RDF >> serializers would drop nodes if they were not referenced which helped lead >> us to having an SPDX Document as a root level node in the graph. We >> included this node in the logical as well as the serialization model for >> RDF. I have a feeling we may (re)discover the same issue in v3 RDF >> serialization where we will need a root collection to reference all the >> elements we intend to serialize. We could decide to make this root element >> something not included in the logical model or we could require custom RDF >> serialization libraries as alternatives. My current thinking is we have an >> SPDXDocument in the model for the serializations to “contain” all the >> elements we wish to serialize (in RDF, it just needs to be referenced). To >> make this more flexible, we could expand the types of elements which the >> SPDXDocument could “contain” (e.g. Relationships). >> >> >> >> Regards, >> >> Gary >> > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#4718): https://lists.spdx.org/g/Spdx-tech/message/4718 Mute This Topic: https://lists.spdx.org/mt/92634687/21656 Group Owner: [email protected] Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
