specification [FEATURE]: Add additional component types for Manufacturing/Formulation/ML artifacts

During the v1.5 proposal process for formulation schema (or Manufacturing BOM, MBOM), the emphasis was on creating the new schema needed; however, the WG was presented additional considerations to better support formulation component types. Specifically, this list was presented as an initial concept list of new type values (cut/pasted) here:

Note: “component” should support new “type” enum. values. 

Proposed minimum adds:  

"configuration", 
// includes K8s resource definitions (and downstream definitions from Knative, Tekton, etc.)
"tool", 
// A hardware or software tool that was used in a task
// Note: Supports early examples where “tools” were special task objects
"task", // to designate workflow task “components” type
// Note: Could use “container” type for Tekton
"repository” (external, resource storage)
// define source/target for input/output to tasks e.g., GitHub
Others (TBD):
“storage” (more generic storage term)
“workspace” (in-workflow, ephemeral storage)

Describe the feature

Please note that many "components" of an MBOM may be ephemeral or logical in nature, but are backed by or represent physical entities (i.e., hardware, such as storage) or instances of data (such as configurations) that are created/instantiated during the formulation process perhaps by the underlying platform or execution environment.

This issue is intended to propose a set of new type values for discussion that will allow better clarity when creating and analyzing an MBOM what types of components were being used/where and for what purpose.

Possible solutions

Need to discuss with WG/core maintainers.

Alternatives

The proposal is specific to component types which is designed to be accommodating of such new types as new types of BOMs are formalized/published.

Additional context

None

Jan 08 '25 14:01 mrutkows

Please note that this exercise SHOULD also include MLBOM component types (for example for building ML models) such as tensor data, tokenizers, chat/prompt templates, etc.

Jan 08 '25 14:01 mrutkows

Additional notes... "tools" are a key concept and are purposeful and ephemeral as they are being brought into specific tasks to perform a function for that task and then are typically not available in other tasks (i.e., removed). This is similar to the concept of a "configuration" file or dataset. Do we need to differentiate ephemeral components in some way?

Jan 08 '25 14:01 mrutkows

These component-types are basically formulation specific, right? They should not be used in other aspects of software-transparency (like SBOM).

If so, I would implement the JSON/XML/... in a way, that the $.formulation.components[] extends the global-defined component and add the additional options for compoennt-types enum.

Jan 08 '25 14:01 jkowalleck