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]]
-=-=-=-=-=-=-=-=-=-=-=-


Reply via email to