| Version 5 (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
- 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.
Simple 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 an 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 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.
Interoperation and Integration
...
Single Source of Truth
...
Provenance
...
== Temporal ===
...
Information Model
...
Schema
...
[Enter text]
