| Version 13 (modified by gordonrachar, 15 years ago) |
|---|
TracNav menu
Principles of Interoperability
Status of this document: Working Draft
This document is open for feedback, please post questions and comments in the forum at the bottom of this page. You will need a login to post in the forum.
Contents
- Abstract
- Encapsulation and Abstraction
- Interoperation and Integration
- Single Source of Truth
- Provenance
- Temporal
- Information Model
- Schema
Abstract
[Enter abstract]
Encapsulation and Abstraction
Encapsulation
Roughly speaking, encapsulation means Hiding. It means you hide everything you can about an object and only reveal what others need to see. The purpose of hiding unnecessary information is that it gives all members of the transaction freedom from each other.
Example: A computer subroutine that converts pressure from one system of units to another.
Typically, a program that calls the subroutine only passes the data value to be converted, and receives back the converted value. The calling program does not have to know the particular algorithm you use. This gives you the freedom to alter the algorithm. Perhaps you need to include a conversion factor that has more significant digits. If the calling program can't see the algorithm, you are free to change the algorithm any time you want. In fact, in this case, it is better for the calling program not to know the algorithm.
An object has many representations. For instance, when an object is stored in a database, the database is a representation of the object. If the same object is stored in a second database, the representation might be completely different, perhaps because of different scopes of work, or different assumptions about the object. If you want to be able to move information between the two databases and you use special knowledge of the two, you create bindings. Your implementation will be fragile--any change to either database runs the risk of breaking the information transfer. But if you move the information in a way that does not depend on any special knowledge of the representations, your implementation will be robust. We say that the two databases each encapsulate the object.
If you have anything less than full encapsulation, your cost of ownership will go up. This runs counter to typical thinking. Usually on an interoperability project, the computer programmers want to know as much as possible about the members of the information exchange.
Abstraction
Abstraction is the result of generalization of an object by reducing the information to only that which is relevent to a particular purpose.
Example: A pump in a refinery has many representations: (See Encapsulation, above.)
- A very detailed drawing from the manufactuerer showing the baseplate and nozzle dimension in great detail.
- A plastic model.
- A simple symbol on a P&ID.
All of these representations are abstractions of one another.
Example: Four Representations of a Car:
- Give me one of these!
- 2010
- Ford
- Mustang GT
- Color Red
- Give me a Ford car
- Give me a car
- Give me a vehicle with doors, windows, 4 wheels
- Give me a vehicle
Each of these representations is an abstraction of the previous one. Each one increases the abstraction. (Note that #5 includes covered wagons and airplanes.) As you increase the level of abstraction you include more and more and eventually will include everything within it.
How far do you go? Hmmm... There is an art and a science to that question.
Interoperation and Integration
...
Single Source of Truth
...
Provenance
...
Temporal
...
Information Model
...
Schema
...
[Enter text]
