Thanks for this.

First, I'm unclear on what THIS_PACKAGE ... is? So any further comments are based on a giant black-hole of my understanding.

It sounds like SBOMs aggregate/reference a multitude of $things, which may be addressed by various names.

Perhaps if we take @JimFuller-RedHat's thought of calling those $things Components, we can avoid other thing-or-name-of-thing issues.

Given that a pURL is a "package URL", it feels like "package" may indeed be "things you can assign a pURL to".

Likewise, CPEs are names of $things, but tend to name "products" for want of a better word.

Like pURLs, CPEs can be roughly ambiguous, in that they are based around pattern-matching. While every product identifiable by a CPE should have a canonical CPE, an arbitrary CPE (with possible wildcards) may not canonically point to a single product.

So, thinking, in human prose (not DB DDL)...

• An SBOM references 0-or-more components
• A component may be a reference to a package or a product (or a third thing we've not yet discovered).

That being said, I think you're 100% right in that our current package-related tables are indeed pURL-centric.

I also agree that those tables could/should be better named, such as base_purl versioned_purl and qualified_purl.

Likewise, we have a cpe table that may or may not be in play at the moment (ignorance on my part).

Jumping up from human prose to APIs, connecting through the DB DDL...

A human wants to find packages and products, and just so happens to need to use a pURL or CPE to communicate their desires.

If we stick the the idea that a "package" is "anything addressible using a pURL", then /api/v1/package/... still continues to make sense to me. Sometimes we want to speak about log4j. Sometimes we want to speak about log4j@1.2.3. But a human is still talking about "the package generally known as Apache Log4j".

Likewise, a human may want to understand things about a product (RHEL, RHEL8.2, RHEL8.2 on Sparc), and may end up using a CPE to do so. Ergo, still /api/v1/product/... endpoints.

So if we separate the human-facing prose-centric desires from the DB DDL implementation details, I think my proposal is...

• SBOM "packages" should be DDLd as "components" name-wise
• Our "package" tables which are pURL-centric should be renamed to be pURL-centric.
• Our "package" API makes sense, where human-provided keys are pURL-centric.
• Our "product" API makes sense, where human-provided keys are CPE-centric.
• Both of the above APIs could/should have our UUID-based escape hatch for simpler URLs and determinism.

Another analogy would be the use-case of "I'd like to call Jim on the telephone". You certainly dial his phone number (the key used to indicate your desires), but you're not talking to the phone number. You're talking to Jim on the other end of the connection.

• "I liked to call Jim" -> "I'd like information about log4j, version 1.2.3"
• <dials +1-404-xxx-xxxx> -> /api/v1/package/{purlish}
• Chats with Jim -> learns about log4j version 1.2.3

wrt THIS_PACKAGE...

Perhaps this is ... another set of tables?

Just like a product can be associated with a cpe, maybe we need another package table that can reference to a qualified_purl table?

Or possible 1+ pURLs/CPEs, depending?

Keep the distinction between $things and $one_of_possibly_many_names_for_a_thing.

Part of our ambiguity in pURLs, and our table layout is to support "pointing to more than a single bag of bits".

An advisory says log4j@[2.0,3.0) is affected, let's say. So we point to the versionless purl table, joined to a version-range table. And then we want to know which concrete fully-qualified pURLs fall inside that assertion.

Ultimately, to answer the questions you posited above.

I'd wish there would be a mindmap mode for discussion. Branching off individual topics :)

So I'll start slow and try to separate this:

The idea of THIS_PACKAGE was to have (without having a proper name) a counterpart to an "SBOM package" but on a global/universal level. An SBOM package is a resource/thing owned by an SBOM. A global package (this_package) is a package which exists outside of any SBOM. There is a reference from an SBOM package to that THIS_PACKAGE. Probably more than one SBOM package points to that global THIS_PACKAGE.

Then again, that might just be a virtual thing, as the same can be achieved by doing the lookups we do today.

I think I mostly agree with your initial comment on this @bobmcwhirter ... I am not sure if "component" is a better pick for a name, because it feels like a term that is equally ambiguous and overloaded. Aside from that, SPDX uses "package", CDX uses component. But mostly mean the same thing.

What might make sense, is to come up with a mapping glossary: Trustify / SPDX, Trustify / CDX, Trustify / Klingon.

And as you said, the endpoints still deal with "packages", that's why I think it makes sense keeping that prefix. But part of this interaction is based on PURLs. So it might make sense to have that by-purl indicator. And we can extend this with by-cpe or by-digest to make clear when we do operations by other identifiers. I think this pattern works.

And it might be, that those endpoints go to the same service functions internally, just with different enums or ID types. But I think having a /api/v1/package/by-purl/{purl} is much clearer than having something like /api/v1/package/{anything}. Because it makes it clear on the API what to expect.

I am not sure how to name things internally. I think what would help a lot is to add code comments, to explain what the idea of a function or structure is. Renaming all struct and functions might be overkill.

Renaming the database tables is the right thing to do IMO.