[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [EXT] Artifact, or Element, or Package



Greetings all –

 

I haven’t been involved in the earlier modeling discussions, so I don’t have all of the previous context.  Please excuse any errors in my interpretation of the current model proposal.

 

Also note that the opinions below are my own and do not represent all of the SPDX community.

 

Having a 1:1 relationship between properties like the creator, some type of signature or verification and the SBOM itself is indeed important.  In the SPDX model, this 1:1 relationship is between the SpdxDocument and those essential properties of the SpdxDocument class.  The same relationship could be accomplished by introducing another object/class between the Document and the elements described by the Document.  The SPDX community just decided to take the approach of representing these relationships as properties of the SpdxDocument.  Having a many to one relationship at some point in the model between the document and elements represented in the document would be important to supporting many of the SBOM use cases IMHO.

 

I do like the term Artifact as well.  I think this is a more descriptive term and less confusing than the SpexElement term we have used in SPDX.

 

In the SPDX model, we use SpdxElement as a superclass for a File, Package (a collection of code that can be downloaded or accessed as a unit), and Snippet (a Snippet is a byte range within a file).  The 1 to many mapping to the superclass allows for a document to describe any combination of files, packages and Snippets.

 

I probably have a bias to the SPDX model, but I still think having a 1 to many relationship between the Document and the Artifacts (using the new proposed terminology) would be a better approach than having a Document with a 1:1 relationship to an Artifact which has a many to one relationship to files, packages (and perhaps in the future) snippets.

 

BTW - Changing SPDX to use Artifact rather than SpdxElement will not cause any compatibility issues since SpdxElement is not a concrete class.  SpdxElement seldom (if ever) shows up in an SPDX document. 

 

Gary

 

From: Philippe-Emmanuel Douziech <p.douziech@castsoftware.com>
Sent: Tuesday, October 22, 2019 10:51 AM
To: Ido Green <idog@jfrog.com>; Dan Lorenc <dlorenc@google.com>
Cc: Kay Williams <kayw@microsoft.com>; Martin, Robert A. <ramartin@mitre.org>; sbom@omg.org
Subject: RE: [EXT] Artifact, or Element, or Package

 

Hello everyone

 

As you can guess from my first model, I'm also in favor of Artifact.

About the multiplicity of files, the model is quite clear with a [1..*] cardinality between the Artifact class and the File class.

To help, we could make sure that every illustrations of the different usage scenarii are multi-file situations.

 

For your information, I posted updated versions of the documents (docx, pdf, xmi) and illustrations in the SBOM google drive; they contain:

* Artifact terminology 

* optional association between the Document class and the LicenseInfo

 

Philippe 

 


From: Ido Green [idog@jfrog.com]
Sent: Tuesday, October 22, 2019 6:21 PM
To: Dan Lorenc
Cc: Kay Williams; Martin, Robert A.;
sbom@omg.org
Subject: Re: [EXT] Artifact, or Element, or Package

+1 for artifact 

But I wonder how can we make it clear that it could contain multiple files.

 

On Tue, Oct 22, 2019 at 09:10 Dan Lorenc <dlorenc@google.com> wrote:

I like artifact as well. I acknowledge that it has the implication of only a single entity, but I think it's still our best option. We should make it clear that a "logical artifact" can refer to multiple files.

 

Dan Lorenc

 

On Mon, Oct 21, 2019 at 6:31 PM Martin, Robert A. <ramartin@mitre.org> wrote:

In OMG artifact is the favored term for this.  

 

I support artifact.

 

Bob

 

Get Outlook for iOS


From: Kay Williams <kayw@microsoft.com>
Sent: Monday, October 21, 2019 6:59:43 PM
To:
sbom@omg.org <sbom@omg.org>
Subject: [EXT] Artifact, or Element, or Package

 

Hi all,

 

Here is another nomenclature question for our group.  I was talking with Kate Stewart (Linux Foundation, SPDX) this afternoon. We were discussing what to call the ‘target’ or ‘object’ of an SBOM.  In other words, what is the ‘thing’ an SBOM describes. We think the ‘thing’ is broad, where it may span the following:

 

·      File diff

·      File

·      Commit, File Archive, Package, Container (all of which span multiple files)

·      File System, Cloud Service (all of which span multiple packages, containers, etc.)

 

Kate mentioned that in SPDX today the ‘thing’ is an ‘element’. (Not a ‘package’ – Philippe-Emmanuel, we may have been mapping to the wrong SPDX element).

 

I propose that for the SBOM we call the ‘thing’ an ‘artifact’. This has the following implications:

 

  1. SPDX 3.0 would need to rename the ‘element’ field to ‘artifact’.
  2. Philippe-Emmanuel would need to update the SBOM model to center around the term ‘artifact’.

 

Does this work? Thoughts?

 

Kay

 

 

 

 

 

 

 

 

 

 

 

 

 

From: Kay Williams <kayw@microsoft.com>
Sent: Tuesday, October 22, 2019 2:19 PM
To: Philippe-Emmanuel Douziech <p.douziech@castsoftware.com>; Ido Green <idog@jfrog.com>; Dan Lorenc <dlorenc@google.com>
Cc: Martin, Robert A. <ramartin@mitre.org>; sbom@omg.org
Subject: RE: [EXT] Artifact, or Element, or Package

 

Hi. I have been working through some examples in our User Scenarios document and have a question related to the multiplicity of files.

 

Specifically, I wonder if it might be better to have a 1:1 relationship between an SBOM and a single artifact file. I say this because the file is the level of granularity at which we want to attach intellectual property (license) data.

 

Let’s say we have three files, a, b and c. Files a and b are GPL licensed., File c is BSD.

 

Which of the following do we do?

 

  1. Files a, b, and c each have an associated SBOM, in addition there is a wrapper SBOM that has ‘contains’ relationships with SBOM_A, SBOM_B, and SBOM_C.
  2. Files a and b have an associated SBOM. File c has an associated SBOM.  In addition there is a wrapper SBOM with ‘contains’ relationships to SBOM_A&B, SBOM_C.
  3. Modify our model so that licenseinfo can be carried on the file element, and all files can be described in a single SBOM
  4. Something else.

 

Am I understanding our current model correctly?

 

Thanks,

Kay

 

From: Philippe-Emmanuel Douziech <p.douziech@castsoftware.com>
Sent: Tuesday, October 22, 2019 10:51 AM
To: Ido Green <idog@jfrog.com>; Dan Lorenc <dlorenc@google.com>
Cc: Kay Williams <kayw@microsoft.com>; Martin, Robert A. <ramartin@mitre.org>; sbom@omg.org
Subject: RE: [EXT] Artifact, or Element, or Package

 

Hello everyone

 

As you can guess from my first model, I'm also in favor of Artifact.

About the multiplicity of files, the model is quite clear with a [1..*] cardinality between the Artifact class and the File class.

To help, we could make sure that every illustrations of the different usage scenarii are multi-file situations.

 

For your information, I posted updated versions of the documents (docx, pdf, xmi) and illustrations in the SBOM google drive; they contain:

* Artifact terminology 

* optional association between the Document class and the LicenseInfo

 

Philippe 

 


From: Ido Green [idog@jfrog.com]
Sent: Tuesday, October 22, 2019 6:21 PM
To: Dan Lorenc
Cc: Kay Williams; Martin, Robert A.;
sbom@omg.org
Subject: Re: [EXT] Artifact, or Element, or Package

+1 for artifact 

But I wonder how can we make it clear that it could contain multiple files.

 

On Tue, Oct 22, 2019 at 09:10 Dan Lorenc <dlorenc@google.com> wrote:

I like artifact as well. I acknowledge that it has the implication of only a single entity, but I think it's still our best option. We should make it clear that a "logical artifact" can refer to multiple files.

 

Dan Lorenc

 

On Mon, Oct 21, 2019 at 6:31 PM Martin, Robert A. <ramartin@mitre.org> wrote:

In OMG artifact is the favored term for this.  

 

I support artifact.

 

Bob

 


From: Kay Williams <kayw@microsoft.com>
Sent: Monday, October 21, 2019 6:59:43 PM
To:
sbom@omg.org <sbom@omg.org>
Subject: [EXT] Artifact, or Element, or Package

 

Hi all,

 

Here is another nomenclature question for our group.  I was talking with Kate Stewart (Linux Foundation, SPDX) this afternoon. We were discussing what to call the ‘target’ or ‘object’ of an SBOM.  In other words, what is the ‘thing’ an SBOM describes. We think the ‘thing’ is broad, where it may span the following:

 

·        File diff

·        File

·        Commit, File Archive, Package, Container (all of which span multiple files)

·        File System, Cloud Service (all of which span multiple packages, containers, etc.)

 

Kate mentioned that in SPDX today the ‘thing’ is an ‘element’. (Not a ‘package’ – Philippe-Emmanuel, we may have been mapping to the wrong SPDX element).

 

I propose that for the SBOM we call the ‘thing’ an ‘artifact’. This has the following implications:

 

  1. SPDX 3.0 would need to rename the ‘element’ field to ‘artifact’.
  2. Philippe-Emmanuel would need to update the SBOM model to center around the term ‘artifact’.

 

Does this work? Thoughts?

 

Kay