... Alan Key, who coined the term "Object Oriented Programing" identified the following his definition of "object oriented":
"OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme LateBinding of all things."
Alan Key though Java and C++ were abominations. However he may feel, THAT is the state of Object Oriented Programming today. Objects are instances of classes, which typically also determine their type. :/
You're not wrong that Erlang and Scheme are just as much about objects and message-passing as they are about actors.
Kay may or may not agree with me, but I like to require a facet he mentioned in another discussion once: The uniform calling interface. This is the property of objects that you may send any message to any object. If you require this, then Java and C++ disqualify themselves neatly.
In real OOP, we don't have to use inheritance for objects of different types to be substitutable, so "object based" doesn't exist as a separate phenomenon. We use inheritance when two or more things are internally similar, such that they can share a chunk of implementation. If things are similar only externally (API level) but have totally different internals, then we don't use inheritance.
OOP is happening when we substitute objects of different types into the same code and they work, regardless of whether those objects are related to each other by inheritance.
"Object based" is when we cannot do that.
It's basically a new (or not so new any more) term for "abstract data type" which is used when the abstract data type language supports obj.function(arg) syntactic sugar.
If we take Wirth's Modula-2 or Pascal exactly as-is (two languages exemplifying abstract data typing support) and then add the "obj.function(arg)" sugar, they suddenly become "object based".