Situations exist on different levels, the most important of which I'll call "logical situations" and "physical situations". To take an example:

You, I, Jim and Jill are meeting in a conference room today. That certainly qualifies as a situation. Tomorrow, we'll be meeting again in the same conference room. Then, we'll be in the same Physical Situation, because it's the same set of people, things, information and capabilities in the same place.

However, we might not be in the same Logical Situation: while today, the subject of our meeting may be to discuss customer X, the subject of tomorrow's meeting may be to discuss the upcoming company picnic, which is something entirely unrelated. So assuming it is the same situation would be highly misleading and counter-productive.

Similarly, for our second meeting we might have chosen to meet in a different conference room (or over lunch) but still deal with the same customer situation, in which case the Physical Situation would be different, but the Logical Situation would be the same.

This table summarizes the possible combinations:

Why is this important? For Situational Software to act appropriately and be effective, it is necessary to distinguish between Logical and Physical Situations. For example, if a mobile device has the ability to determine its physical location, and the proximity of other resources (say, the mobile devices of the other people in the situation), it is tempting to assume that this ability alone would identify the situation: it does not, it only identifies the Physical Situation, but cannot make any assertions about the Logical Situation.

Note that a user most likely is more interested in Logical Situation support than Physical Situation support.