Changes between Version 2 and Version 3 of ISO15926HowTo_Principles_SingleSourceTruth

Show
Ignore:
Timestamp:
12/06/09 23:11:27 (12 years ago)
Author:
gordonrachar (IP: 198.53.220.181)
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • ISO15926HowTo_Principles_SingleSourceTruth

    v2 v3  
    11[[TracNav(TracNav/ISO15926HowTo)]] 
    22 
    3 = Principles of Interoperability = 
     3= Single Source of Truth = 
    44 
    55Status of this document: Working Draft 
     
    1717---- 
    1818 
    19 == Encapsulation and Abstraction == 
    20  
    21 '''Encapsulation''' 
    22  
    23 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. 
    24  
    25   Example:  A computer subroutine that converts pressure from one system of units to another. 
    26  
    27   Typically, a program that calls the subroutine only passes the data value to be converted, and receives back only 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. 
    28  
    29 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. 
    30  
    31 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. 
    32  
    33 '''Abstraction''' 
    34  
    35 Abstraction is the result of generalization of an object by reducing the information to only that which is relevent to a particular purpose. 
    36  
    37   Example:  A pump in a refinery has many representations:  (See ''Encapsulation'', above.) 
    38  
    39   * A very detailed drawing from the manufactuerer showing the baseplate and nozzle dimensions in great detail. 
    40   * A plastic model. 
    41   * A simple symbol on a P&ID. 
    42  
    43 All of these representations are abstractions of one another. 
    44  
    45   Example:  Five Representations of a Car: 
    46  
    47   1.  Give me one of these!  [[Image(2010MustangGT.JPG, 100px)]] 
    48       * 2010 
    49       * Ford 
    50       * Mustang GT 
    51       * Color Red 
    52   2.  Give me a Ford car 
    53   3.  Give me a car 
    54   4.  Give me a vehicle with doors, windows, 4 wheels 
    55   5.  Give me a vehicle 
    56  
    57 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 will eventually include everything within it. 
    58  
    59 '''Reference Data''' 
    60  
    61 It appropriate at this point to bring in another idea, Reference Data.  When you have to relate abstractions between two representations, you really need a third.  (You can say that one of the representations is the abstract one, but usually leads to compromises you shouldn’t make.)  You need a third that truly abstracts the two representations.  If you increase the number of representations, it forces you to generalize that abstraction to cover all possible representations. 
    62 Having a neutral representation of information is whole point of Reference Data. 
    63  
    64 Reference data is not constrained by any storage method. 
    65  
    66 By mapping several representations into abstract content, you achieve integration of information.  If two or more representations map to one abstract content, those two representations are said to be related to each other.  And having that abstraction enables you to achieve the encapsulation you want. 
    67  
    68 How far do you go?  Hmmm...  There is an art to finding the Goldilocks point.  Not too much.  Not too little.  Just right. 
    69  
    70 Look at all the different storages you have of the information.  You need a point of encapsulation.  And that point of encapsulation is just some boundary that you put on that information on that system.  Where you implement that point of encapsulation could be at any point.  Could be right in the database.  Could be on some programming API or a webservice, or a file. 
    71  
    72 There are many ways to implement that point of encapsulation.  Once you represent a specific representation into an abstracted one there’s the (??? Fine line third party???).  What’s in there is just the information itself, but nothing about how it is stored, or location, what’s its schema is. 
    73  
    74 Here is the mental picture:  There are an infinite variety of representations, and there is a representation at every storage point of information, and every storage point needs to expose an abstracted representation that is understood by everybody else, and that abstracted representation is the point of encapsulation. 
    75  
    76 The point of the abstraction is the encapsulation.  Where ever you finally transform your representation into that 3rd party abstracted representation, that is the point of encapsulation. 
    77  
    78 What’s left is purely the information you want to make public.  Private information, schema, column names, table names, storage location path, all should remain private.  You want freedom.  You don't want nobody depending on that level of detail. 
    79  
    80 Interestingly, we have a convergence of interests.  We generally want to keep proprietary information secret.  But this principle of encapsulation says that no one wants the proprietary information anyway, because if we use that proprietary knowledge in the data exchange, we are forever shackled by someone else’s proprietary thoughts. 
    81  
    82 Most people violate this principle because its so much easier to violate it.  It’s easier to connect systems together without encapsulation.  The greatest offenders are the people in IT, because they are project-oriented.  “What’s the easiest right now.” 
    83  
    84 Benefit:  Total control of what you publish 
    85 Benefit:  No one really even wants your proprietary information 
    86  
    87 '''Abstraction''' 
    88  
    89 You need abstraction to encapsulate.  If you violate encapsulation, your costs go up.  You violate interoperability.  Most people don’t understand this.  Most computer science geeks especially don’t understand this. 
    90  
    91 The big leap forward with ISO 15926 is that is provided out of the box. 
    92  
    93  
    94 == Interoperation and Integration == 
    95  
    96 Interoperation and Integration are often (incorrectly) used as synonyms of each other.  Of course they often come as a pair:  to get interoperability, you need integration; If you want integration you need interoperability.  But they are not the same thing. 
    97  
    98 '''Interoperability''' 
    99 Interoperability is the ability to connect and transport information between points of encapsulation. 
    100 Integration 
    101 Integration is the ability to create a relationship between two different bits of information. 
    102 Integration is saying that “that information” is related to “that information”. 
    103 DOES NOT MEAN YOU MERGE DATA.  Merging is taking two representations and combine them into one representation.  It is often done this way (and often incorrectly), but it is not required, or even necessarily desirable 
    104 It is richer if you say: 
    105 •       Stuff over here – is related to – stuff over there 
    106  - and, by the way, the relationship is of a certain type 
    107  
    108  
    10919== Single Source of Truth == 
    11020 
    111  
    11221... 
    113  
    114 == Provenance == 
    115  
    116 ... 
    117  
    118  
    119 == Temporal == 
    120  
    121 ... 
    122  
    123  
    124  
    125 == Information Model == 
    126  
    127  
    128 ... 
    129  
    130  
    131 == Schema == 
    132  
    13322... 
    13423 
Home
About PCA
Reference Data Services (RDS)
RDS Operations Support
Meetings and Conferences
ISO 15926
Special Interest Groups
Technical Advisory Board
Norwegian Continental Shelf Std
Projects
Search