Business logic would be transformations to the data. Like for a spreadsheet, the data layer would handle the reading/writing of files as well as the storage of each cell’s content. The business logic layer would handle evaluating each of the formulas in the cells, and the presentation layer draws it on the screen.

I think the part where it gets confusing is that each of these layers are pretty tightly coupled. The end destination of the presentation layer might change, one might show it on a GUI, another might print it, and another might convert it to pdf or html, but each of those presentation layers needs to understand the data that it is presenting, so it’s tightly coupled to the data layer. Same with the businesses logic layer, though it’s tightly coupled on both the input and output sides. The design of the data layer constrains the possibilities of the other two, so it’s hard to draw a clear boundary between the layers because they all need to know how to walk the same data.

My mental flow chart for this is more of a data layer in the middle instead of business logic, where business logic is to the side with arrows going both ways between it and data layer, then the presentation layer also accessing the data layer directly, which I suppose is a different permutation of what you described.

Though another way to look at it does make sense. For a website, think of the database as the data layer, the server scripts as the business logic layer, and the client side scripts/html/css as the presentation layer. That one also follows the layered approach where the presentation layer is talking with the business logic layer.