"I had Taco Bell for lunch today". I keep hearing that usage from co-workers, students, random people in passing. At some level it makes complete sense – I get it that the person speaking ate at food obtained at a Taco Bell "restaurant" (why anyone would do that is beyond the scope of this posting). However, compare and contrast that with, "I had salad for lunch today." The second describes the food (pretty generically), the first describes the place where the food came from.
Now imagine you don't know that Taco Bell is a food chain, and maybe you are not doing analysis in your primary language). What assumption would you make about the statement, "I had Taco Bell for lunch today?" I think the first reaction would be that "Taco Bell" would be classified as a kind of food, not a kind of place. And Because that is a first impression, it would set a context that could be hard to shake.
As an aside, while working in France a couple of years back, the nearby Pizza Joint was called "Speedy Rabbit". When a project team member suggested we have "Speedy rabbit" for a working dinner – and that I, being the project manager and therefore an impediment to progress should go and fetch it. Since in that part of France, rabbit is often served, and often really tasty, I had visions of having to chase this thing down in my underpowered rental car. Turns out it was a pizza joint and that it was a simple pickup. Not a rabbit in sight. Oh well.
As architects/analysts we often find words or phrases that are used in surprising ways (idiomatically one might say if one were being charitable). The insiders to the group get it, understand the meaning, know when the statement refers to Taco Bell the company HQ, the Taco Bell on the corner, the specific lunch (without knowing the actual details of the meal). So we have to be careful when we are faced with words like "office" or "transaction". We need to know the context that the speaker is coming from and to be able to decouple our understanding of the word from the understanding that the speaker means.
How often have you heard statements like "we have 7 transactions in our banking system"? My first reaction is, "wow those must be huge transactions" or this bank is going under soon. And then I realize that of course it is transaction types or kinds of transactions, not the instances. Once again context rules. If you ask the question, "How many transactions did you do today?" You may well get an answer of 100 million. If you ask the question, "How many transactions can be executed?" You might get the answer 7.
So, how do we know when we are getting a "type" answer? How do we know when we are getting an "instances" answer? How do we make sure handle the precision that we need, without pushing all the annoying explicit packet context onto the people we are striving to understand. We have to learn the context, apply the context properly, and hide the distinctions unless it becomes absolutely necessary. One way of doing this nicely is to have stash of instance models handy. So when talking about concepts we should talk about them extensionally when we mean to describe the instances, and intensionally when talking about the type.