A baseline is essentially a time-line and from that perspective it's the closest equivalent to a commit as known from systems like Subversion, CVS, Bazaar, git and Mercurial. And then again - it's far from the same.
ClearCase doesn't track changes at repository level like the systems mentioned above. In ClearCase each individual file and directory has it's own individual version tree. The compelxity you get from that approach is ...simply overwhelming! In many situations it's not even especially useful and could just be disregarded as a different architectural approach to solving the same problem - which in turn could trigger a general discussion about modern VCS architecture - but we'll take that discussion elsewhere.
The point is that in everyday work it's often more useful to trace a repository state as opposed to an individual element state and the UCM baseline does exactly that.
A baseline is tied to both a stream and a UCM component - which in turn can be a rootless component and as a consequence the baseline is then really a composite baseline.
So the baselines are stable reference points and they are also used at the foundation of streams. What that means is that all streams have an off-set that is identified by a baseline. When you rebase a stream, what you do is actually that you change the streams foundation(!)
So what is inside a baseline, what's the stuff that it's made of? The answer is "activities" (and in this case more interestingly, the activities' change sets).
A baseline has a promotion level, by default UCM used the five predefined levels: