To me the purpose of an OO application design is not to accurately model or reflect the real world behavior or capabilities of an object. There is nothing wrong with playing with that as an approach and it may help with some designs, but I don't see it as an arbiter of a good design. A good OO design is one where behavior and data are appropriately encapsulated, where the reasoning behind design decisions is consistent and easy to understand, and where (most fundamentally) the application will be easy to maintain with good encapsulation of what is most likely to vary.
A good OO design for a given use case is highly dependent on the technical environment and the parts of the technical system that are most likely to change. To try to design ideal objects, to me is YAGNI. I'd rather suitably apportion functionality between class files based on heuristics like the single responsibility principle, maximizing cohesion and minimizing coupling and encapsulating that which is currently most likely to change. As such, I would argue that the "best" design for a given OO app is highly dependent on technical requirements and what's most likely to change in those technical requirements and to try to write an OO program that isn't technology aware is like trying to design a car that runs like a horse.
I am not saying that there is not value in the "ontological approach" of "what is my object". I *am* suggesting that while that may be useful, it is definitely not the final arbiter of good design. The final arbiter of good design is how elegantly and maintainably you've implemented the technical requirements. Object oriented programming is a tool to make your applications more maintainable, nothing more, nothing less.
Just my 2c.