Restructure the categorization of OCSF Classes

[jp-harvey]

Note: OCSF entities in this proposal are referred to using proper nouns (Classes, Categories, Profiles, etc.)

Background Information

Categories were originally implemented in OCSF with two purposes:

1. allow data providers an entry point into existing OCSF Classes that may serve their needs, and
2. provide a grouping for related data to facilitate queries.

Thus, Categories were designed to be a "superset" of related data sources. However, as the schema has developed, two things have happened:

1. OCSF Classes were defined and intended to allow a variety of sources to be defined with the same schema, reducing some of the planned utility of Categories
2. OCSF Profiles were defined as an overlay onto OCSF Classes, giving Classes a broader application to an even a greater amount of sources.

These two progressions have diluted the role of Categories in providing a value as a "superset", as that is largely undertaken by Classes. In addition, the diversity of sources in a Category don't necessarily overlap in such a way that a "superset" makes sense.

Categories are a label for Classes that do not enforce any attributes in the schema itself, and this label is currently used primarily to define the maintainers for various Classes. The maintainers of the Classes may not be the best maintainers for Classes put into a category of best fit. For example, container maintainers (say that out loud fast 10x if you can) would not necessarily have any virtual machine expertise, nor would “Cloud” maintainers necessarily have expertise with virtual machines running on bare-metal hypervisors.

This poll is aiming to explore options for changing the existing Category structure in the pursuit of simplicity, flexibility, and the reduction of verbosity of OCSF.

For the purposes of this poll, we will refer below to

• “categories” as representing a vertical categorization
• “labels” as a flat categorization
• “tags” as categories that can be applied either vertically or horizontally.

The names themselves do not matter, only the concepts, and this poll is not suggesting that they be the final names.

Options

Keep the existing vertical Category structure

Leave the existing structure in place, it’s fine how it is. Categories can be revised if necessary.

Visual representation:

Category 1	Category 2	Category 3	Category 4
class1001	class2001	class3001	class4001
class1002	class2002	class3002	class4002
class1003	class2003	class3003	class4003
class1004	class2004	class3004	class4004

Flat labels

Flatten the categorization by creating a pool of labels, any number of which can be applied to any Class.

Visual representation:

class1: label1
class2: label2
class3: label1,label2
class4: label1,label5

Vertical categories + labels

Leave the current vertical Category structure in place, add / remove / change the Category names as needed, and implement a discrete set of “labels” that can be applied horizontally to any Class.

Visual representation:

Category 1	Category 2	Category 3	Category 4
class1: label1	class5: label6	class9: label4	class13: label8
class2: label2	class6: label3	class10: label13,label4,label3	class14: label1
class3: label1,label2	class7: label12,label5,label1	class11: label9,label11	class15: label6
class4: label11,label5	class8: label2	class12: label5	class16: label8,label12,label1

Tags that can be applied either horizontally or vertically

Adjust the vertical Category concept to a pool of tags. Each Class has a single “primary” tag, creating a vertical structure, and then any number of “secondary” tags, creating a horizontal structure. This is conceptually similar to a user being a member of a “Primary Group” in Linux or Windows AD, and then a member of any number of additional groups. Not all tags would have any Classes where that tag was designated as a primary tag meaning not all tags would be used vertically, and not all tags would necessarily be applied horizontally.

Visual representation:

Tag 4	Tag 5	Tag 11	Tag 14
class1: tag1	class5: tag4	class9: tag4	class13: tag8
class2: tag2	class6: tag3	class10: tag13,tag4,tag3	class14: tag1
class3: tag1,tag2	class7: tag12,tag11,tag1	class11: tag9	class15: tag6
class4: tag11,tag5	class8: tag2	class12: tag5	class16: tag8,tag12,tag1

Considerations

Any decision will cause cascading decisions and while the intent is not to capture all of them here an attempt will be made to highlight the main ones:

If we make changes, are the current categories even “right” for a different model? Should we be re-imagining everything if we move to a flat(ter) model?

It has been pointed out that the categories are potentially useful for things like partitioning of data. How much do we need to consider these implications for each option?

We currently allocate maintainers to categories, so if things are going to fall into multiple categories, how do we allocate maintainers?

If we move to a flatter model, how do we do tag management? How are changes to tags / labels / categories determined?

We already have the concept of Profiles which are applied horizontally across Classes. Is there enough crossover with horizontal labels or tags that we should / could restructure the implementation of Profiles to meet the same need (regardless of what implementation is chosen)?

[rroupski]

Note, the category uid is used to create a unique class uid in the OCSF schema. Thus the visual representation of the categories and classes is:

Category 1	Category 2	Category 3	Category 4
class1001	class2001	class3001	class4001
class1002	class2002	class3002	class4002
class1003	class2003	class3003	class4003
class1004	class2004	class3004	class4004

[jp-harvey]

Good point, thanks @rroupski, updated