I was trying to explain something in the CDA Book, and in so doing came up with an analogy that may help explain the use of viewpoints in SAIF and RM-ODP.
There have been many times in my engineering career where someone would give me requirements for an object in a system. After listening to the requirements, I would start breaking them down into the classes that the system would use. Time and time again I would run into situations where the class I had created could be simply extended to support some new behavior in order to meet other requirements. This is pretty normal in engineering.
Then I would go explain what I did, and the person who gave me the requirements would say "No, that has to be wrong, because Y is not the same as X".
"But," I would argue, "except for these extension points, they work exactly the same way."
And then we would sit down and look at it. And lo and behold, we would see that we were looking at the same thing from two different viewpoints. I was looking at it from an engineering viewpoint, trying to understand how it worked, and the other person was thinking about it from a business viewpoint, how it was used and managed. it would turn out that we were both right.
Let's take another example. To an auto-mechanic, a cam-shaft, a transmission, an a differential are all different things. But they are all made up of gears, and to a mechanical engineer, these could just be viewed as different kinds of gear-cases (I do realize I'm drastically simplifying this, but you should get the idea).
I used a shift in viewpoint to explain the acts in the HL7 CDA clinical statement model in the book, so that I could build from students knowledge of simpler things. A substanceAdministration is like a procedure, for example, save that it has these extra things. Given that they already understand the procedure class, I no longer have to explain all of the details of the substanceAdministration class again. I can expect the student to make the viewpoint shift to the clinical aspects of medication administration independently from the data transmission aspects.
I wound up not using this analogy in the book, but only because I couldn't make it fit with what I had already written. It's still an interesting analogy.