confusing classification with sensitivity

[schmocker]

The term classification is often confused with sensitivity in data management, even though it's clear that classification is not limited to sensitivity only. I would like to point out and clarify this obvious fact here as I think naming things correctly is crucial for a common standard.

classification vs sensitivity

What is classification

according to https://en.wikipedia.org/wiki/Classification and https://en.wikipedia.org/wiki/Data_classification_(data_management), the term classification means "[...] the activity of assigning objects to some pre-existing classes or categories [...]".

What is sensitivity

according to https://en.wikipedia.org/wiki/Information_sensitivity, the term sensitivity means "[...] the control of access to information or knowledge that might result in loss of an advantage or level of security if disclosed to others [...]".

Confusion in data management

Often the term classification is used to refer to sensitivity only. But data can be classified in many other dimenisons, like for eg. structured vs semi-structured vs. unstructured.

Conclusion

The term classification should not be reserved for sensitivity only.

Solution for future versions of ODCS

Rename the field classification into sensitivity

[schmocker]

my suggested change in the JSON schema (updated):

...
"classification": {
  "type": "string",
  "description": "Can be anything, like confidential, restricted, and public to more advanced categorization. Some companies like PayPal, use data classification indicating the class of data in the element; expected values are 1, 2, 3, 4, or 5.",
  "examples": ["confidential", "restricted", "public"],
  "deprecated": true
},
"sensitivity": {
  "type": "string",
  "description": "Can be anything, like confidential, restricted, and public to more advanced categorization. Some companies like PayPal, use data classification indicating the sensitivity of data in the element; expected values are 1, 2, 3, 4, or 5.",
  "examples": ["confidential", "restricted", "public"]
},
...

[jgperrin]

This would be a breaking change. We can't change it that easily :(

[schmocker]

Thanks, you're right. So maybe instead we could add a new field for sensitivity and mark the existing field classification as deprecated. See deprecated keyword here https://json-schema.org/understanding-json-schema/reference/annotations.

[simonharrer]

I see your perspective, though I view it a bit differently.

This concept has been part of ODCS from the start, and it’s also included in the Data Contract Specification, which many people have worked with through the Data Contract CLI. Given that background, it may not be as confusing as it might seem. And when we consider the effort and cost of changing it, keeping it as is could be the more practical choice.

We might also look at it as the most important form of classification, namely confidentiality and sensitivity. In that sense, “classification” works well as a shortcut. In everyday practice, people are used to classifying information into categories like public, confidential, internal, or secret. Because this is the most familiar context for “classification,” the term has naturally taken on this meaning. Language often adapts in this way, shaped by common usage.

[jgperrin]

• You can create sensitivity as a custom field. We also recommend the use of tags for this.
• Don't forget that ODCS is mostly an exchange format... You can still have sensitivity in the UI if you want

[schmocker]

Thank you for considering it. @jgperrin thank you for these tips, I've seen that the framework is quit extendable 👍.I see your points @simonharrer, thanks for the arguments. Thus, in my current position, I feel that language and miss-interpretation of certain terms is one of the biggest barrier on the path of adopting a data driven culture - starting with little terms like this one - all the way to "what is a product?". But all good! Thanks to the extendability of this schema/framework (and to you guys) I think I can adopt to whatever terms I believe are best for our context. Thanks and cheers!