Oops, I was right the first time, they are two different information models, as your graph illustrates nicely. In the first file the elements are an ordered set - they are in a list and have a position in that list, so "give me the first element" can be answered. In the second file the elements are a normal (unordered) set - there is no "first" element, just a collection of elements each with a unique ID.
On Tue, Feb 15, 2022 at 3:05 PM David Kemp via lists.spdx.org <dk190a= [email protected]> wrote: > The list-serialized file that you graphed was: > { > "namespace": "http://sbom.acme.com/AX7CqA-I/";, > "specVersion": "3.0", > "created": {"by": ["i1"], "when": "2021-11-8T14:15:16+00:00"}, > "profiles": ["Core", "Software"], > "dataLicense": "CC0-1.0", > "elements": [ > { > "id": "foo-metadata-rev1", > "type": {"package": {}}, > "name": "foo" > }, > { > "id": "foo-contents-rev1", > "type": {"relationship": {"type": "CONTAINS", "from": > "foo-metadata-rev1", "to": ["hello-file", "world-file"]}} > }, > { > "id": "annotation-rev1", > "type": {"annotation": {"type": "REVIEW", "subject": > "foo-metadata-rev1", "statement": "Annotation example"}} > }, > { > "id": "hello-file", > "type": {"file": {}}, > "name": "hello" > }, > { > "id": "world-file", > "type": {"file": {}}, > "name": "world" > }, > { > "id": "i1", > "type": {"identity": {"type": {"organization": {}}, "email": " > [email protected]"}}, > "name": "Acme Package Manager" > } > ] > } > > The map-serialized version is: > { > "namespace": "http://sbom.acme.com/AX7CqA-I/";, > "specVersion": "3.0", > "created": {"by": ["i1"], "when": "2021-11-8T14:15:16+00:00"}, > "profiles": ["Core", "Software"], > "dataLicense": "CC0-1.0", > "elements": { > "foo-metadata-rev1": { > "type": {"package": {}}, > "name": "foo" > }, > "foo-contents-rev1": { > "type": {"relationship": {"type": "CONTAINS", "from": > "foo-metadata-rev1", "to": ["hello-file", "world-file"]}} > }, > "annotation-rev1": { > "type": {"annotation": {"type": "REVIEW", "subject": > "foo-metadata-rev1", "statement": "Annotation example"}} > }, > "hello-file": { > "type": {"file": {}}, > "name": "hello" > }, > "world-file": { > "type": {"file": {}}, > "name": "world" > }, > "i1": { > "type": {"identity": {"type": {"organization": {}}, "email": " > [email protected]"}}, > "name": "Acme Package Manager" > } > } > } > > I was mistaken when I said different information models. The two files > are instances of the same information model (every Element value has an id > and a type), just using two different rules for how the id is serialized as > JSON data. > > Hope this helps, > David > > On Mon, Feb 14, 2022 at 8:56 AM Nisha Kumar <[email protected]> wrote: > >> David, >> >> >> >> Thanks for your explanation. It makes it much clearer to me how this >> would look for the purposes of storing the SBOMs in a container registry. >> >> >> >> There are also two ways of serializing those elements: >> 1. as a list as shown, where each numbered (0..4) element has an id, type >> and name >> 2. as a map, where each element is named by its id replacing the number, >> with type and name properties below it. >> >> >> >> Do you have an example of these two variations for the same SBOM? It >> would make things clearer for me. >> >> >> >> Thanks again, >> >> -Nisha >> >> >> >> >> >> *From: *David Kemp <[email protected]> >> *Date: *Wednesday, February 9, 2022 at 2:46 PM >> *To: *Nisha Kumar <[email protected]> >> *Cc: *SPDX-list <[email protected]> >> *Subject: *Re: [spdx-tech] SPDX v3 serialization >> >> Nisha, >> >> That's a great way of illustrating serialization without looking at the >> text/syntax. Thanks! I think when the group gets into discussing >> serialization alternatives, using graphs like this makes it easy to >> visualize different ways that data represents the identical logical model. >> For example, the left subgraph under SBOM doesn't exist in the logical >> model at all, it exists only to make units of transfer more readable and >> efficient. The only things that exist in the logical model are the >> numbered nodes under elements in the right subgraph. >> >> There are also two ways of serializing those elements: >> 1. as a list as shown, where each numbered (0..4) element has an id, type >> and name >> 2. as a map, where each element is named by its id replacing the number, >> with type and name properties below it. >> >> I arbitrarily used the list approach for the information model, which is >> why the json data and your graph appear that way. But a different >> information model for the identical logical model would use the map >> approach - it's a matter of taste which way the TC prefers the data to look >> like. There will be myriad other places where taste choices can be made >> between equivalent alternatives. (I already chose to make Hash a map from >> algorithm to value instead of separate algorithm and value properties. >> Either way works, the map is much cleaner.) >> >> So I think rather than pulling a bunch of graphs into my repo, it makes >> more sense for you to just graph specific unit-of-transfer files when >> issues like that come up in a serialization discussion. I think just >> blindly graphing all the JSON examples would be a waste, when the current >> examples are all from the same information model, created for the purpose >> of discussing relationships. When two information models are being >> compared, a single example graph for each would be very helpful for >> visualizing differences and making decisions. >> >> Thanks, >> David >> >> >> >> On Tue, Feb 8, 2022 at 9:42 AM Nisha Kumar <[email protected]> wrote: >> >> Hi Dave, >> >> I have a script that generates graphs from JSON. Would you like me to >> submit PRs to your repo with equivalent diagrams? I’ve attached an example >> for “package-property-rev1.json” >> >> >> >> -Nisha >> >> >> >> *From: *[email protected] <[email protected]> on behalf of >> David Kemp via lists.spdx.org >> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.spdx.org%2F&data=04%7C01%7Cnishak%40vmware.com%7Cdbd116e60c6740e904fe08d9ec1dfe24%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637800435846031497%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=t5xZp34Y4eVVoEkTPasjPzzkMWDx9R8kg%2BFwCTd%2FdWQ%3D&reserved=0> >> <[email protected]> >> *Date: *Saturday, February 5, 2022 at 7:02 PM >> *To: *SPDX-list <[email protected]> >> *Subject: *[spdx-tech] SPDX v3 serialization >> >> Now that we have examined William's example elements to discuss graph >> updates, they seem like good concrete examples that can be reused for other >> purposes. I've converted them into full serialized units of transfer to >> discuss how syntax defined by an information model can be represented in >> the logical diagram. The examples, information model, and logical diagram >> are available at >> https://github.com/davaya/spdxv3-template-tool/tree/main/Data3 >> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdavaya%2Fspdxv3-template-tool%2Ftree%2Fmain%2FData3&data=04%7C01%7Cnishak%40vmware.com%7Cdbd116e60c6740e904fe08d9ec1dfe24%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637800435846031497%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=j12XizqkDNqf4knWp4blP5wkOA4cyrZ1%2FTZHeAB2r%2FY%3D&reserved=0> >> for whenever the weekly discussion turns to serialization. >> >> Dave >> >> > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#4382): https://lists.spdx.org/g/Spdx-tech/message/4382 Mute This Topic: https://lists.spdx.org/mt/88942711/21656 Group Owner: [email protected] Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
