From a UML point of view, there are actually three things going on here, not just two. And object is of a class (instantiation/inheritance), via classes objects claim a given set of relationships (aggregation/relations), and some of those relationships are held so closely they are considered intrinsic to the objects of that class (composition/members). (These are true literally in a statically-typed world-view, but are conceptually maintained in any object framework, and almost true.)
Especially in computer science, but also in real life, all being involves containing, and all containing involves having. You not only are yourself, but you also have yourself as (maximal, in some way) part and lay claim to yourself via some kind of identity relation.
So, pulling back a bit, when it all comes down to it, there is only aggregation. Composition is just a matter of perspective. And inheritance is just a specific form of composition that conveys an intention to act in a given way.
In practice, the distinction generally comes down to how much detail one needs to provide to the object to get something done. If I want to do something that is part of my agenda as a being, I only need to identify myself, and the intention. "I build chairs." In general, I can be a number of different things, a human animal, a chair builder (because nowadays machines can do that, and in a special sense so do companies), a mind (remains may be human but only 'have had' a mind)...
But if that action is specific to a part of me, that part must be an element of my composition. "My left hand grasps the hammer." When the distinction between elements is clear, this is simple. And it is even fairly clear when they significantly overlap -- my left side and my front overlap, but they tend to play different roles in actions.
To the extent that my ability to build chairs is 'a hat' I wear, it could be an aspect of my instance, inherited by the definition of 'me', or I could focus primarily on 'me' as a human and a mind, making by ability to make chairs part of my composition.
This way of thinking makes for the most contention in object design, a 'state' or 'mode' or 'facet' or 'aspect' or 'perspective' [which all have specific meanings in the object-design context, or I would not list so many options] on an object is intermediate between its identity and its composition. Maybe I can't build chairs while surfing, then are the chair-building and surfing aspects of me disjoint? Do I want to have to say what aspect of myself is involved, in order to use those parts, if by doing so I make the complexity clearer? (And do I want to prevent myself from hammering while surfing, which will usually get me wet, perhaps with my own blood.)
Finally if that element is only temporary, so I need some point of reference to find it, and it may in fact not be there, so I might have to acquire or construct it, then it is simply aggregated to me by some relationship. "I have this chair, and I can give to you. But then if I need another chair, I will have to acquire one." Only a 'pointer' or other indicator of relationship to the object is then legitimately part of my composition.
It sometimes helps to maintain one's perspective to remember how much these latter two things are constructs, not natural occurrences, with variant models in different languages, both formal and natural, much less different problem domains, proving the basic ideas are not necessarily the same for everyone.