I wholeheartedly agree with David Heinemeier Hansson's opinion, on the fact that DBMS should only keep application data, and not business logic:

I consider stored procedures and constraints vile and reckless destroyers of coherence. No, Mr. Database, you can not have my business logic. Your procedural ambitions will bear no fruit and you'll have to pry that logic from my dead, cold object-oriented hands.

In other words, I want a single layer of cleverness: My domain model. Object-orientation is all about encapsulating clever. Letting it sieve half ways through to the database is a terrible violation of those fine intentions. And I want no part of it.

That said, there is still a lot of impedance between object-oriented and relational models, and the current generation of O/R mapping tools only partially fills the gap. On the other side, as Chris Date maintains, even SQL itself fails at implementing the relational model itself in a satisfactory way.

However, as for managing the meaning, I agree with the knowledge representation/knowledge management perspective, that an ontological layer should take care of providing a domain model, and give the correct semantics to the data, thus enabling automated interpretation and reasoning, without (paraphrasing DHH) "letting it sieve half ways through the application".
This is a noticeably more difficult goal, since both tools and methods for ontological modelling are still far from being mainstream.