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