Is there a paradigm for working with data semantically instead of file-based?

Question

I am looking for a name/paradigm/research area etc. that describes the notion of working with data not in the traditional file-based sense, but instead based on semantics. I can best explain what I am looking for with an example:

Text editors typically work file-based. I write some text, save it in a file and if I later want to edit the text, I open this exact file. If I write a book, I might have many files for each chapter that I have to deal with individually, even though semantically they form a unit 'book' and the fact that my book is stored in separate files is not relevant when I am writing the book. It is an implementation detail.

Contrast this with for example a game engine such as Unity. If I edit a level for a game, the game engine might create multiple files to store the data for the level in, but I as a user don't have to know these details. I am working with the semantic unit 'level' and let the computer figure out the details at the storage level.

Does this concept (let users work with semantic units instead of files) have a name?

Edit: Maybe my initial question did not convey what I am looking for. I know that what I am describing is a form of abstraction (as some answers/comments have pointed out). But I am asking whether this form of abstraction has a well-defined name in the literature and whether there is research related to developing software that supports this abstraction.

As an example for a similar situation, take cloud computing. It is an abstraction over computer system resources, yet the development of systems that work with this abstraction is an active research area that is called 'cloud computing'.

• Robert Harvey: You're describing a distinction without a difference. A file is merely a storage unit, like any other. It's also a semantic unit, like any other. In your example, a file describes a "document" or "chapter." Text editors can store text in files, but they can also store text in databases. Even within the text file, there are semantic units called "words," "paragraphs" and "formatting." So once again, no difference. The only material difference I can think of is that text editors often work with documents "in-memory," but that is not a necessary feature.
• thessalchips: To me there is a distinction in terms of usability. Let's say I am looking for a specific paragraph in my book. When using raw files, I have to open each file and search for the paragraph in the file. A smart text editor would instead load the whole book and let me search all chapters at once. Or I have to use something like grep, whose main purpose seems to be exactly what I am talking about: Treat a series of files as a single semantic unit and perform an operation (search) on it.
• Robert Harvey: Yes, and that smart text editor and grep are still working with files.
• thessalchips: Maybe the smart text editor can open a single file, multiple files, query a database or call some REST API and makes it look all the same to the user. This was uncommon for applications 20 years ago, but is very common for applications today, especially web apps. This seems like a paradigm shift to me which should have a name. 'Distributed systems' seems close but doesn't quite capture it...
• Robert Harvey: What you're describing there is indirection. More specifically, the use of interfaces to promote generalization. For example, most development platforms have the concept of a "file handle" and "read" methods that allow you to read data from that file. But it doesn't have to be a file; it can be any data source beneath that file handle, including a REST interface. The only requirement is that the data source conforms to the expectations of the interface, namely, that it can read data in sequence (and perhaps seek to a location in the "file"), and detect "End of File."

Answer 1

The example given sounds like a textbook example on the basics of Abstraction in Computer Science. Wikipedia refers to it as Data Abstraction:

Data abstraction enforces a clear separation between the abstract properties of a data type and the concrete details of its implementation. The abstract properties are those that are visible to client code that makes use of the data type—the interface to the data type—while the concrete implementation is kept entirely private, and indeed can change, for example to incorporate efficiency improvements over time.

A more concrete example might be an ORM (Object-Relational Mapping) pattern in object-oriented programming. While generally used for relational databases (hence the name), it basically provides a clear abstraction between the data being stored, and the implementation responsible for storing it.

Because abstraction is such a key concept in (modern) programming paradigms, such as object-oriented programming, you will find many different patterns implementing their own forms of abstraction, and the example given can be implemented in nearly all of them.

• thessalchips: Thanks for your answer. Unfortunately 'abstraction' is too general to be an acceptable answer. I tried to specify my initial question more accurately to make this clear.
• Martin Maat: @thessalchips If abstraction is too general for you, go with object orientation. It does not get closer to what you are describing than that I am afraid. It entails encapsulation and data hiding, to spill a few more terms.
• Duroth: I'm honestly not sure how much more specific a term will be applicable here. Indeed, perhaps Object Orientation (as in Object-Oriented Programming) might work. But that's about as specific as you can get before talking implementations rather than concepts. Mapping semantic units (objects) to their persistently stored representations is done through a Data Access Layer (en.wikipedia.org/wiki/Data_access_layer), which in itself is often part of an ORM implementation and similar patterns.

Answer 2

There is no technical reason someone could not author a "Book Editor" which stores chapters in separate files (perhaps in separate databases).

Just do not see much utility in such a specialised editor. Generally speaking the more flexible an editor is the more users it gets, the more specialised the less users. A generalized editor like vim can edit pretty much edit any file based data, a "Book Editor" as proposed would only be able to edit files created by itself.