Add 'category' field to machine-learning-model component

[bardenstein]

Request: add a category field to the mlm component.

• Required: true
• Type: String
• Examples: "text-generation," "image-processing," "image-generation," etc.
• Justification: model types are part of the standard model card for HuggingFace, the largest repository of open-source models. The type field also helps the end user understand what category of model this is and its primary functionality.

[stevespringett]

We discussed this in the ML workstream, but I'm not sure if we settled on an approach.

There are three options:

1. A string field
2. A enum (also a string)
3. CycloneDX properties

Option 1 will likely end up being any string a model author decided to put in there. So for processing, you'll likely have mixed results.

Option 2 will require us to create a formal taxonomy that would be strict and would have to be all encompassing. Any new enum values would need to be added in future versions of the spec.

Option 3 is the most flexible and will work with the existing v1.5. But we will need to start defining the taxonomy. The benefit of this approach is that we can add to it over time. In terms of "strictness", it falls somewhere in between Option 1 and 2.

[bardenstein]

@stevespringett from the people I discussed, a string or ENUM seems to represent a vast majority of the data in the wild I see in model cards. To your point, I'd suggest we start with the string until we collect enough data to formalize some ENUM values.

[jkowalleck]

@bardenstein the CycloneDX CoreWorkingGroup proposes to start with a CycloneDX propery.
You could define and register theres here: https://cyclonedx.github.io/cyclonedx-property-taxonomy/

Examples of others colaborating on property taxnomy:

• the current rust standardisation - rust-related sub-namespaces under cdx cyclonedx-property-taxonomy#75

If the maturity of this property reaches a certain level, we could standardice on it.

[jkowalleck]

@stevespringett and @mrutkows proposed to call it "tags" on the component level, instead of "category"
this way we could have tags like

• xml-parser for a component of type library
• image-generator for a component of machine-learnign type