Data Exchange and Data Sharing

The development architecture and methods included in ISO 10303 are designed to support the principle objective of the standard: the specification of standardised descriptions of product data that are suitable not only for neutral file exchange, but also provide a BASIS for implementing and sharing product databases.

It is generally accepted that there is a significant industrial requirement for what is called "data sharing" and that "data sharing" is different from or beyond "data exchange". In order to assess the nature of support for these in ISO 10303, it is necessary to first establish exactly what they mean and how they are different. The following simple real-world analogies can be used to illustrate the concepts of data exchange and data sharing

Data Exchange - An Example

An account statement detailing a customer’s banking activity is prepared monthly by a bank and sent to a customer via the US Postal Service. The customer receives the statement and uses the information to balance his chequebook and track his financial position. A "data exchange" has taken place (Figure 1).

Figure 1: Example - Data Exchange Scenario

Account information maintained by the bank has been transformed into a form the customer can understand (a statement), the information has been transported to the customer via an exchange mechanism (e.g. the Postal Service), and the customer has received and understood the information. Such an exchange has the following characteristics:

• Initiated by data producer - Typically, a data exchange occurs upon the initiation of the party who originally produces the information, in this case the bank.
• Transformation to neutral format - The bank may choose among many different internal representations to effectively manage its account information. In order to communicate that information with the customer, however, a transformation must take place to convert the information into a form the customer can readily understand. In this scenario, the information to be exchanged includes not only the data (numbers representing dollar values), but also the context of that data. In this case, the context is represented by the column titles and descriptive text, which accompany the numeric data on the statement. Without this contextual framework, the customer would have a difficult time understanding the information.
• Redundant copies of data - Once the exchange has taken place, there are now two copies of the account information: the account information represented internally at the bank and the statement now in the possession of the customer. Presumably, the customer will use the account statement to maintain his own account information independent of the bank.
• Discrete event in time - A data exchange occurs as a discrete event in time. Once the exchange has been accomplished, the information at the "sending" side (the bank) may change without notice to the "receiving" side (the customer). The information passed during the exchange is simply a snapshot of the data as it existed at the time of the exchange. If this new information is to be passed along to the customer, another data exchange must take place. Similarly, if the customer wishes to respond in some way to the account statement, the customer must initiate a new data exchange in which his response is sent to the bank.

Data Exchange and ISO 10303

In a modern computing environment, data exchange is commonly understood to be the exchange of neutral format data files between computer systems. A sending system translates data from its internal format and encodes it into an established neutral format. This file is then transferred to the receiving system where the data is translated into the internal format of the receiving system.

The architectural components that comprise a data exchange implementation include:

• a sending system translator (pre-processor) to generate neutral data file
• a transport mechanism for sending neutral files to the receiving system
• a receiving system translator (post-processor) to convert data files to an internal format

There are many well understood transport mechanisms available for distributing a data file, including electronic mail and File Transfer Protocol (FTP).

In the banking analogy, the bank statement, including both the data and the data context, represents the neutral data file. In traditional computer-based data exchange, the neutral data file usually contains only the data, not the context. The context of the data, or how the data values relate to meaningful concepts, is often defined implicitly by the data’s location in the format file. Both the sending and receiving systems depend on a priori knowledge of the file format and its relationship to the data context. If this were true in the banking analogy, the account statement would contain only numbers; the bank and the customer would need to agree beforehand which numbers correspond to which account categories (i.e. line 1 would contain the balance, line 2 would contain disbursals during the reporting period, etc.)

ISO 10303 supports data exchange through the STEP physical file format. Each STEP application protocol provides a model which serves as an explicit standardised data specification for an established application context. It is this model that provides a documented explanation of the context (scope) and meaning (relationships) of the data to be exchanged. It is used, along with an encoding algorithm, to produce STEP physical files that contain both the data and its associated context, thus enabling effective and flexible communication between computing systems.

Data Sharing - An Example

Unlike data exchange, the definition of data sharing is not as easy to agree on. This is true because there are many different implementation objectives for data sharing and too many different ways that data sharing implementations can be created. At an abstract level, data sharing means data stored in one system can be shared by other systems. Conceptually, a sharable data instance needs only to be stored once in a single place and used for many purposes by many systems. The term "share" means to use, own, or receive jointly; it is also defined as a portion of a whole, which is given or assigned. If we use these definitions, data sharing is not the act of transferring a snapshot of the data, but the joint use and ownership of the data.

Consider one example (as illustrated in Figure 2) of data sharing in the context of the banking analogy presented above.

Figure 2: Example - Data Sharing

Rather than mailing an account statement every month, the bank may implement a touch-tone telephone system to pass along information to its customers. A customer may call the bank and use the push-buttons on the telephone to enter his or her account number and navigate menus to access and update his or her account information. In this case, data sharing has the following characteristics:

• Initiated by data receiver - Typically, data sharing occurs upon the initiation of the party who desires/receives the information, in this case the customer who initiates the telephone call.
• Data on demand - Because the telephone system provides the customer with the latest account information at the time of the phone call, the customer need only call at the time when the data is actually needed. In addition, the customer chooses the content of the information he or she wishes to receive by selectively navigating through the touch tone menu system.
• Context embedded in protocol - The context of the information received by the customer is partly defined by the specific steps, or protocol, the customer uses in interacting with the phone system. For example, in response to the phone system’s prompts, the customer may press "1" to receive checking account information and then press "2" to receive current balance or "3" to receive most recent check number that has been cashed. The actual context of the final numeric data received by the customer is defined by the series of steps taken to receive the data.

Although the telephone banking system example helps to illustrate some of the characteristics of data sharing, there are additional characteristics that fall out of the scope of the example above:

• Single Data Instance - In most data sharing systems, only one instance, or copy, of the data is maintained. Other interested parties may access the information as needs require, but only one copy is considered to be the updated, legitimate repository of the data.
• Read and Update - Data sharing often encompasses more than just a retrieval of information. Facilities often exist which permit updating of the single data repository by multiple parties. In this perspective, data sharing is a "two-way" street which allows both information access as well as information updating.

Data Sharing and ISO 10303

The successful development of a data sharing implementation requires that many different aspects of information technology be considered. Among those, controlled data access is a key element. Data access is the interface mechanism whereby a computer program can read or update the selected data in a data store. In the data sharing scenario, some portion of the database is intended to support joint usage and ownership. To successfully share data, the data access mechanism must allow multiple application systems to read, store, and manipulate the shared data.

Traditionally, data sharing systems are implemented as client-server systems or more recently as server-server (federated) systems. Therefore, multiple co-operating applications may have one or more data stores that are controlled by server functions. There may be data stored in these distributed data stores that are designated to be shared among many application systems. As in the banking analogy above, the communication protocols and implementation technologies required for data sharing implementations are more complicated than those of data exchange, and multiple data stores add to the complexity.

The information context for the shared data is embedded in each application’s knowledge (the application logic), their physical schemas, and the steps required to access/update the shared data in the distributed data stores. Effective data sharing requires a mapping of these different data stores where shared data reside under a single data specification that is understood by the co-operating applications.

ISO 10303 forms the basis for data sharing implementations via the AIM, conformance classes, and data instantiation rules and constraints that are specified in the mapping table. Collectively, these serve as the single data specification for the application systems that need to share data.

Because ISO 10303 is being developed as a communication standard, it is not intended to serve as an efficient and complete data structure for storage implementation. However, it can provide the necessary navigation paths for data access.

The design of a data sharing implementation must consider the system architecture and computing environments (e.g., hardware, software, and development tools) of all application systems that need to share data. The system design must address the unique interactions between the control structure and the component systems. The design strategy varies depending on the component systems, the computing environment, and performance considerations. These design strategies are not specified as and probably should not be a formal standard part of ISO 10303.