No. The Open/Closed principle applies to object-oriented software constructs such as classes, not data.
When evaluating programming patterns and principles, it's important to understand why the principle was created in the first place, how it applies to programming, and what exactly it applies to. Without that understanding, it's very easy to learn about a principle for the first time, think it applies to everything, and apply it indiscriminately or even in a way that causes harm.
For example, the phrase "premature optimization is the root of all evil" is misused all of the time to mean things like "don't optimize until later," or worse, applied to things for which it has no relevance, such as sensible software design. What the phrase really means is "measure first, then optimize only those parts of your code which your measurements say will produce tangible benefits." It doesn't say anything about not following sensible design principles from the start. In addition, that's not actually the entire phrase, so some meaning is lost if that's all you quote.
That said, let's examine the Open/Closed principle.
In object-oriented programming, the open/closed principle states "software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification 1
Object-oriented programming, as the principle implies, primarily involves code, not data. Some readers will argue that "code is data," or that "some data has object-oriented features such as inheritance," which are both true. But the principle that we're talking about here is intended to be used within the context of object-oriented programming in the traditional sense, not as a principle to be applied to data.
The Open/Closed principle is the O in SOLID, the five principles that, when applied together in an object-oriented software design, intend to make it more likely that a programmer will create a system that is easy to maintain and extend over time.2
A class should have only a single responsibility (i.e. only one potential change in the software's
specification should be able to affect the specification of the class)
"Software entities should be open for extension, but closed for modification."
"Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program." See also Design By Contract.
“Many client-specific interfaces are better than one general-purpose interface.”
“Depend upon Abstractions, not on concretions.”
Notice the wording of these principles. They all refer to "software entities:" classes, modules, functions, interfaces and so on, all staples of the Object-Oriented paradigm. These are not data, in the traditional sense, though they may contain data. Data follows a different set of rules, and a different vocabulary: immutability, atomicity, durability, etc.
Read Robert C. Martin's Clean Code and you will get a very good perspective on the proper context in which these terms are used.
1Meyer, Bertrand (1988). Object-Oriented Software Construction. Prentice Hall. ISBN 0-13-629049-3.
2“SOLID Object-Oriented Design”, Sandi Metz (Duke University), Talk given at the 2009 Gotham Ruby Conference in May, 2009.