A White Paper by: The Semantic Interoperability Working Group of The Open Group
Author Name [Style: WP Author]
Affiliation, Credentials or Qualifications [Style: WP Author]
<Month Year> [Style: WP Author]
Please note that all editors should refer to The Open Group Technical Publications Style Guide (I801A) for guidance on writing style.
Copyright © <Year>, The Open Group
The Open Group hereby authorizes you to use this document for any purpose, PROVIDED THAT any copy of this document, or any part thereof, which you make shall retain all copyright and other proprietary notices contained herein.
This document may contain other proprietary notices and copyright information.
Nothing contained herein shall be construed as conferring by implication, estoppel, or otherwise any license or right under any patent or trademark of The Open Group or any third party. Except as expressly provided above, nothing contained herein shall be construed as conferring any license or right under any copyright of The Open Group.
Note that any product, process, or technology in this document may be the subject of other intellectual property rights reserved by The Open Group, and may not be licensed hereunder.
This document is provided "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT. Some jurisdictions do not allow the exclusion of implied warranties, so the above exclusion may not apply to you.
Any publication of The Open Group may include technical inaccuracies or typographical errors. Changes may be periodically made to these publications; these changes will be incorporated in new editions of these publications. The Open Group may make improvements and/or changes in the products and/or the programs described in these publications at any time without notice.
Should any viewer of this document respond with information including feedback data, such as questions, comments, suggestions, or the like regarding the content of this document, such information shall be deemed to be non-confidential and The Open Group shall have no obligation of any kind with respect to such information and shall be free to reproduce, use, disclose, and distribute the information to others without limitation. Further, The Open Group shall be free to use any ideas, concepts, know-how, or techniques contained in such information for any purpose whatsoever including but not limited to developing, manufacturing, and marketing products incorporating such information.
If you did not obtain this copy through The Open Group, it may not be the latest version. For your convenience, the latest version of this publication may be downloaded at www.opengroup.org/library.
FOR ARCHITECTURE FORUM ONLY: This White Paper is an informational document. Readers should note that this document has not been approved through The Open Group Standards Process and does not represent the formal consensus of The Open Group Architecture Forum.
ArchiMate, DirecNet, Making Standards Work, Open O logo, Open O and Check Certification logo, Platform 3.0, The Open Group, TOGAF, UNIX, UNIXWARE, and the Open Brand X logo are registered trademarks and Boundaryless Information Flow, Build with Integrity Buy with Confidence, Commercial Aviation Reference Architecture, Dependability Through Assuredness, Digital Practitioner Body of Knowledge, DPBoK, EMMM, FACE, the FACE logo, FHIM Profile Builder, the FHIM logo, FPB, Future Airborne Capability Environment, IT4IT, the IT4IT logo, O-AA, O-DEF, O-HERA, O-PAS, Open Agile Architecture, Open FAIR, Open Footprint, Open Process Automation, Open Subsurface Data Universe, Open Trusted Technology Provider, OSDU, Sensor Integration Simplified, SOSA, and the SOSA logo are trademarks of The Open Group. All other brands, company, and product names are used for identification purposes only and may be trademarks that are the sole property of their respective owners.
Document Title
Document No.: TBA
Published by The Open Group, <Month Year>.
Any comments relating to the material contained in this document may be submitted to:
The Open Group, Apex Plaza, Forbury Road, Reading, Berkshire, RG1 1AX, United Kingdom
or by email to:
What is Semantic Interoperability? 6
Semantic Interoperability Considerations 7
Why is semantic interoperability important? 7
What situations drive the need to achieve data integration with semantic interoperability? 7
What are the challenges to complete interoperability? 7
What is the suggested approach? 8
What is the recommended approach? 12
How does the Open Data Element Framework (O-DEF) enable semantic interoperability? 14
Appendix – Comparison OIF-EIF 25
Boundaryless Information Flow™
achieved through global interoperability
in a secure, reliable, and timely manner
This white paper highlights the role that semantic interoperability plays in support of data integration.
A Venn Diagram within this white paper illustrates the relationships between interoperability, semantic interoperability, and data integration as fundamental elements of the Open Group vision: Boundaryless Information Flow. The elements of interoperability are also described within a European Interoperability Framework (EIF), adopted by the European Commission, that is used as a reference within this white paper.
The following are key definitions for understanding the content of this white paper.
Data integration is the practice of consolidating data from disparate sources into an aggregate (virtual) data-set with the ultimate goal of providing users with consistent access and delivery of data across the spectrum of subjects and structure types, and to meet the information needs of all applications and business processes.
Having an aggregate data-set from different sources creates two kinds of challenges:
• Combining similar data from different owners into a federated data-set – horizontal data integration
• Combining related data from different sources into a common data model – vertical data integration
Data that needs to be shared across any border of responsibility and ownership is an example of horizontal data integration. For example, vehicle license plate data needs to be federated across political borders in Europe, Asia, and Africa since vehicles from any of these continents can show up in traffic data.
Where a given term has different meanings in different data sources, you cannot easily build a common data model across these sources. In fact, an organization only knows their own definition of any data element concept and may not be aware to what degree this is different from what another organization is understanding. Therefore, there is no trigger for updating the data model. The following figure highlights the fact that any organization only has control over the data within their domain span of governance.
Figure 1: Different Governance Domains Require An Approach For Interoperability Of Their Shareable Data
For example, COVID-19 vaccination data cannot easily answer questions about the protection level against the disease since there are so many variables about the effectiveness of any given vaccination dose. This is caused by partial information being scattered over many different organizations:
• several different vaccine manufacturers/developers
• many hospitals in each country
• health authorities: international regulatory bodies as well as public health management authorities in each country
• general practitioners
• organizations involved in support of pandemic management.
The preceding Figure 1 illustrates the situation that each involved organization cannot see through the red wall separating it from any other organization.
Semantic interoperability allows systems to exchange and federate data with common meaning or universally understandable meaning. See https://medium.com/fluree/semantic-interoperability-exchanging-data-with-meaning-6b950e9f6441
Semantic interoperability is an important enabler for machine-to-machine interoperability. Person to machine and machine to person information exchange are not within the scope of this paper.
The following should be considered when attempting to achieve semantic interoperability between systems.
Data integration now eats up over a third of the average IT department budget, when that overhead should really be spent on innovation. Why? People who built or implemented the systems did not use the same meaning for the terms or used different languages and/or different data models. Again, see https://medium.com/fluree/semantic-interoperability-exchanging-data-with-meaning-6b950e9f6441
By achieving semantic interoperability, the organization can:
Reduce operating costs,
Reduce wrong decisions,
Reduce spillage,
Reduce lost opportunities,
Reduce misunderstandings or conflicts
o Need to share information between two or more systems
o Business growth and addition of new applications
o Merger with another enterprise
o Moving data from multiple applications to a single application, such as an ERP application
o Need to reduce operating costs within a large enterprise
o Need to share data within an industry or government
o Need to share business or public data across federated entities in different countries
o Preserving privacy
o Semantic mismatches
o Legal mismatches
o Procedural mismatches
o Format mismatches
o Media mismatches
o Proprietary lockout – selective APIs
The complexity of the situation drives the approach toward an architecture-based interoperability framework.
The European Commission fostered the development of a framework in the 2011-2012 time-frame and came up with The European Interoperability Framework. This initial approach separated the interoperability challenge into four layers, called: “Common Network”, “Syntactical Interoperability”, “Semantic Interoperability” and “Organizational Interoperability”. Using this approach, a number of projects were run by the European Commission and as a result, further understanding of the interoperability challenges was obtained by an active participant who was also an active member within the Open Group. Based on the findings, the “Open Interoperability Framework was developed in 2012 as a Proposed TOGAF Change - see Figure 2.
Figure 2: The Open Interoperability Framework
The Open Interoperability Framework (OEF) provides a structured approach to address the various challenges that must be overcome to enable interoperability and therefore enable data integration. During the time period that this paper was being authored, the European Commission developed an updated European Interoperability Framework (EIF). A detailed comparison between the OIF and the EIF is provided as an appendix to this white paper.
The Open Interoperability Framework includes three context domains: the systems domain, the organization domain, and the legal domain.
The systems domain inherited the layered approach from the original EIF. The organization domain facilitates different approaches for different types of organizational relations. The legal domain facilitates the implementation of legal compliance in the broadest sense and most complex environments, starting from interpreting applicable legislation to enforcing compliant security policies.
In the systems domain, the following four layers are defined:
1. Media interoperability is about being able to exchange data, either by means of networking or by means of exchanging a physical medium that can be read and written.
2. Technical interoperability is about being able to transcend all kind of technical differences that have no specific relation to the nature of the data at hand. This includes but is not limited to syntactical differences (as identified in the original EIF), conversion between metric and non-metric units, between currencies, between time zones, between data-formats, etc.
3. Semantic interoperability is about being able to mutually understand the meaning of any data that are to be handled as part of the business, the core topic of this paper. This is further explained in subsequent sections.
4. Procedural interoperability is about being able to achieve mutual benefit by using compatible business processes that originate the exchange of information. This includes but is not limited to deadlock prevention, resource conflicts, priority handling, time-out management, error handling, etc.
The Semantic Interoperability layer handles all context specific transpositions that are necessary to properly understand the information that is meant with any data exchange between interoperating systems. The need for information exchange is mostly identified during the elaboration of the Business Architecture (TOGAF phase B).
Figure 3 gives an overview of the subjects that must be understood and addressed in order to achieve semantic interoperability.
Figure 3: The “Crop Wheel” Highlights the Various Parts Necessary for Achieving Semantic Interoperability
To handle semantics, specifications must be defined for:
• The meaning of any vocabularies and their content to be used in the exchange of data (characters and/or symbols relevant to a given language)
• The meaning of any data values and data value types that can occur in certain types of data exchanges
• The meaning of any relations between data elements implied or expressed as part of data exchanges
• The meaning of any classifications of data implied or expressed as part of data exchanges
• The identification of any business rules that may be needed to bridge mismatches between dissimilar data
• The establishment of a context and/or domains that modify or qualify any meaning inherent in data
• The parsing of any unstructured or semi-structured data that may be exchanged in executing interoperability objectives
• Security attributes of any data implied or involved in interoperability
The Open Group mission to achieve Boundaryless Information Flow ® is illustrated by the following Venn diagram (Figure 4) which describes the relationships between the core concepts described in this paper; data integration, interoperability, and semantic interoperability.
Figure 4: Venn Diagram Relates The Open Group’s Mission to Data Integration, Interoperability, and Semantic Interoperability
It is assumed that the enterprise to be considered has developed an overall data model that includes data that are sourced from other parties. Similarly, each of these other parties are assumed to also have developed their overall data model that includes data they do not own.
For the sake of understanding what is happening, we consider that each of these overall data models are composed of a part that is unique to the enterprise that owns the data model and a part that is common to any pair of enterprises that encompasses the data to be integrated.
In the above Venn diagram “unique data model” within Data Integration is that portion of the data model in use in an enterprise that is unique to that enterprise. It can be assumed that other enterprises are unaware of the existence of unique parts of the data model of other organizations. They may even be unaware of the uniqueness of parts of their own data model.
From the perspective of Interoperability, the “unique data model” part of the data model is considered to be part of the context that each interoperating organization uses or assumes.
From the perspective of Data Integration, the Legal and Organizational interoperability are outside the ICT domain that is concerned with data handling.
The “common subset of data model” within Semantic Interoperability is that data that needs to be shared or federated with another system outside the control of the enterprise.
The “systems interoperability” plane of the Open Interoperability Framework (Figure 2), visualized by the blue part of the cube describes the information systems involved with interoperability or data integration. It is to be noted that the data model entirely belongs to the semantic layer of the Open Interoperability Framework.
The “organizational interoperability” plane of the Open Interoperability Framework is the green part in the interoperability cube described in Figure 2.
The “legal interoperability” plane of the Open Interoperability Framework is the red part in the interoperability cube described in Figure 2.
The detailed requirements for Semantic Interoperability are usually derived from the Information Architecture as part of phase B of TOGAF. Successful Technical Interoperability is a prerequisite for Semantic Interoperability. Cloud computing architecture requires interoperability as described by The Open Group Cloud Computing Interoperability and Portability IOP Project. An Open Group standard that can help supporting these objectives is the O-DEF (Open Data Element Framework).
For horizontal data integration, it is recommended to setup a table that lists for each data element concept and for each source of contributing data what semantic mismatches must be overcome. For the most common types of semantic mismatches O-DEF can be used to describe the mismatches. Based on that table, conversion mechanisms can be defined for each Data Element concept.
For vertical data integration the applicable data model must be compared with the data models of all sources of data for integration. How can you compare your data model with a data model that you cannot know about.
Here is where O-DEF comes in. By describing the Data Element Concepts in your own data model using O-DEF you can match your Data Element Concepts with O-DEF tags from different organizations, to discover matches. For each data element concept the semantic differences with the applicable data model must be identified. For the most common types of semantic mismatches O-DEF can be used to describe the mismatches. Based on that table conversion mechanisms can be defined for each Data Element concept.
On the level of the semantic interoperability layer a standard for semantic interaction is recommended. The Open Group has positioned O-DEF as the framework for this standard.
The following is a list of a few existing data standards that might be applicable depending on the organization’s situation that requires improved semantic interoperability within the boundaries of each standard.
ACORD – Insurance Industry – https://www.acord.org/
FPML – Financial Products – https://www.fpml.org/
NACHA – Payments (ACH) – https://www.nacha.org/
IFX Forum – Interactive Financial Exchange Forum – https://bms.ifxforum.org/
SWIFT – Secure Financial Messaging Services (ISO 20022) – https://www.swift.com/
XBRL – Business Reporting – https://www.xbrl.org/
HR – Human Resource Open Standards – https://www.hropenstandards.org/
ETIM – International Classification Standard for Technical Products – https://www.etim-international.com/
UNSPSC – United Nations Standard Products and Services Code – https://www.unspsc.org/
HL7 – Health Care – https://www.hl7.org/
SNOMED – Health Care Terminology – https://www.snomed.org/
OAGi – Open Applications Group – https://oagi.org/
X12 – Electronic Data Interchange (Business Transactions) – https://x12.org/
Association for Retail Technology Standards https://en.wikipedia.org/wiki/Association_for_Retail_Technology_Standards
The Organization for Data Exchange by Tele Transmission in Europe (ODETTE) for Automotive EDI - https://www.odette.org/
ASAM ODS https://www.asam.net/standards/detail/ods/ The ASAM ODS standard was created to simplify the universal interpretation of data acquired from testing, evaluation, and simulation applications. ODS (Open Data Services) focuses on the persistent storage and retrieval of testing data.
Association for Standardization of Automation and Measuring Systems - https://www.asam.net
UN/EDIFACT United Nations/Electronic Data Interchange for Administration, Commerce and Transport - https://www.edibasics.com/edi-resources/document-standards/edifact/
RosettaNet for IT EDI https://www.edibasics.com/edi-resources/document-standards/rosettanet/
The above data standards are domain specific and where they overlap, such as the data element concept for address, they have conflicts. In general, the above standards have many semantic mismatches with other standards.
To understand the range of semantic challenges that can be faced when solving semantic interoperability requirements, refer to the ISO 11179 standard. It describes a generic model of meta data, that are or may be needed in order to properly understand the meaning of data. If interoperating systems misunderstand the meaning of interchanged data, effective collaboration towards a common or compatible business goal is degraded. Most semantic mismatches can be prevented by using common semantic standards. An example of a semantic standard, consistent with the ISO 11179 standard is The Open Group’s Open Data Element Framework (O-DEF) standard. This kind of standard is needed to overcome any or all of the following:
• Different standards for object descriptions. Typically, each organization has its own data definitions, and apparently similar data definitions may represent (slightly) differently defined objects, due to which instances of a data element in one organization do not match similar instances in the other organization in all cases 10). The Open Group recommends to use the objects of (distributed) O-DEF, whenever possible.
• Different standards for property descriptions. Although ebXML is widely accepted as a common standard, many different schemes exist, in particular within specific knowledge domains. In many cases de-facto standards based on software package vendor are implied. The Open Group recommends to use the properties of (distributed) O-DEF, whenever possible.
• Different standards for value descriptions. Many standards for value description exist, like ISO 8601 for date and time, but many of these standards also cover representation. None of these standards is universally applicable for any data element concept, but instead are restricted to certain classes of objects, or worse enumerated lists of objects. In most cases these standards assume a classification of objects that denies or ignores semantics of context. In the future, The Open Group intends to extend O-DEF with a universal value type description concept that is independent of representation.
• Different standards for confidentiality and integrity attributes. Many enterprises have adopted a common 4-level confidentiality classification (public, company confidential, secret, and top-secret, or work according to ISO 2700x standards, but these standards leave sufficient implementation freedom to hamper any necessary secure interoperability. In the future, The Open Group intends to extend O-DEF with security extensions for semantics complementary to ISO 2700x standards. The O-DEF security extensions are intended to enable interoperability of security metadata and/or the secure interchange of metadata.
• Different standards for credentials and authentication levels. Many enterprises have started to implement federated identification that require them to trust identity schemes setup by other organizations. Open IDM is an example of a standard supported by The Open Group that helps implementing this objective. SAML 2.0 is commonly promoted standard for message formats used in federated identity management schemes. But all of these schemes do not implement provisions for different semantics across federation. The Open Group intends to extend O-DEF with identity management extensions to fill this gap. The O-DEF identity management extensions are intended to enable a common understanding of identity management related data using a SAML and/or OpenID federated identity management solution.
• Different standards for value classification descriptions. Classifications are often used to standardize business processes or to aggregate data, creating derived or higher-level data. One of the conditions for these derived or higher-level data to be semantically equivalent, is the use of common classification criteria. Across boundaries of an enterprise these common classification criteria cannot be assumed, but must be exchanged separately or as part of the regular data exchange. The Open Group intends to extend O-DEF with classification attributes, that enable automatic comparison of classification metadata.
• Different standards for value space descriptions. In many cases it makes a lot of difference to understand some quality attributes of a value of a data element, in particular when a value is absolute, approximated, statistically determined or other. The Open Group intends to extend O-DEF with value attributes in order to enable exchange of value space metadata.
• Different standards for relation descriptions. Many efforts in the domain of semantic interoperability relate to ontologies. In ontologies relations between data element concepts are described. O-DEF is not an ontology, and in its current form does not enable inference logic to be shared between collaborating enterprises. However, the O-DEF does define a taxonomy of roles, which are specialized types of relations between objects.
• Different standards for context descriptions. By definition the context of O-DEF Data Element Concepts must be understood as the context of an enterprise that owns the data. In distributed O-DEF this assumption about the context is relaxed to a specific context to be defined for each satellite vocabulary registrar, or even more granular for each tree managed by such registrar. Yet this context is assumed to be fixed in current versions of O-DEF. For more flexible semantic interoperability, the context description itself is metadata, that is relevant for the understanding of data element concepts. The Open Group intends to extend O-DEF with context attributes that enable any context of data element concepts to be exchanged between systems.
The O-DEF standard provides a good starting point for the objects, properties, and relations (roles) identified in Figure 3 above. If the current O-DEF does not have the object, property, or relation (role) required for a given organization, it can be extended as described in the O-DEF Guide.
The following table provides the root object classes defined by the O-DEF standard.
Identifier | Name | Description |
|---|---|---|
1 | Person | A human being, whether man, woman, or child. |
2 | Enterprise | A collection of people organized to achieve a common set of goals. |
3 | Resource | A source or supply from which benefit is produced. Typically, resources are materials, energy, services, knowledge, or other assets that are transformed, used, or consumed to produce benefit and in the process may be consumed or made unavailable. Note: A resource as defined here is not the same as a resource as defined in the W3C® RDF standard. |
4 | Location | A place or position. Typically, locations provide geographic or geometric context that characterizes the data element. |
5 | Event | An occurrence happening at some point or points in time, with or without the participation of human agents. |
6 | Condition | A particular mode of being of a person or thing; existing state; situation with respect to circumstances. |
7 | Environment | The natural or man-made surroundings of someone or something. |
8 | Law-Rule | A law (natural or man-made) or policy that governs a process. |
9 | Process | A series of actions, changes, or functions bringing about a result. |
10 | Product | The result of a process. |
11 | Substance | A material of a particular kind that bears physical and chemical properties. Substances can be solid, liquid, or gaseous, and stable or unstable. Examples of substances are: water, air, sugar, wood, iron, blood, wine, stone, pvc. |
12 | Information-Set | A collection of information, whether in physical form (such as a book), machine-readable form (such as a file on disc), or human-based form (such as a person’s recollection or an oral tradition). |
13 | Service | A valuable potential or actual action, deed, or effort to satisfy a need or to fulfill a demand. |
The following table provides the root properties defined by the O-DEF standard.
Identifier | Name | Description |
|---|---|---|
1 | Identifier | A value that is intended to identify uniquely the object of the data element. Example identifiers are social security numbers, automobile Vehicle Identification Numbers (VINs), drivers’ license numbers, engineering drawing numbers, and part serial numbers. A name can be an identifier in some contexts, but names are usually not used as identifiers because they are often not unique. |
2 | Name | A word or phrase that refers to the object of the data element but is not intended to identify it uniquely. Name is a specialized form of text. Note: Names are complicated and the full complexity is not addressed in this version of the standard. |
3 | Code | A value from an enumerated list of possible values that is not an indicator and that is not subject to continual change. Example codes are telephone area codes, postal zip codes, and country codes. |
4 | Indicator | A value that is one of only two (true or false) possible choices. Example indicators are temperature high, pressure low, and power on. |
5 | Measure | A numeric quantity that has an explicit or implied unit of measure other than a monetary unit. Basic categories of measure are length, time, mass, current, luminosity, and temperature. The UNECE Recommendation 20 (Rec 20) is an approved O-DEF plugin containing standard units of measure. |
6 | Quantity | An integral numeric quantity that has no unit of measurement. Examples are the quantity ordered of a product or the number of items in stock. |
7 | Amount | An explicit or implied monetary unit of measure. Example monetary units are Euros, British pounds, US dollars, and Canadian dollars. ISO 4217 is an approved O-DEF plugin containing standard currency codes. |
8 | Rate | A real (in the mathematical sense) numeric quantity, possibly expressed as a fraction, but not as a percentage. For example, 10 marriages per 1,000 ending in divorce is a rate. |
9 | Percent | A numeric quantity expressed as a percentage. A percent is a specialized rate. If the above divorce rate was expressed as one marriage per hundred, it would be a percent. Another example of a percent is an interest rate on a loan. |
10 | Date | A specific timeslot on a calendar with the precision of one day. An example is a date of birth expressed as year + month + day. |
11 | Date-Time | A specific date plus time (with any degree of precision) in the progression of time. An example is the date and time at which a patient’s temperature is taken, expressed as year + month + day + hour + minute. Other examples might specify time more or less precisely; for example, with seconds and microseconds, or without minutes. |
12 | Time | A specific time within a specific timeframe. For example, a day of the month, hour of the day, and minute of the hour might be used to specify when a regular meeting repeats. |
13 | Text | Text that is not an identifier, name, code, indicator, measure, quantity, amount, rate, percent, date, date-time, or time. Examples are descriptions of products offered for sale, the text of contracts, and passwords. |
14 | Binary | A value that is not an identifier, name, code, indicator, measure, quantity, amount, rate, percent, date, date-time, time, or text. |
The following table provides the root roles defined by the O-DEF standard.
Identifier | Name | Description |
|---|---|---|
1 | Trader | Any role derived from any kind of trade relation of the implied or referenced object. |
2 | Lineage | Any role derived from a relationship of the implied or referenced object with a common heritage. |
3 | Organized-Structure | Any role derived from the configurational/organizational relation of an object. |
4 | Citizenship | Any role derived from nationality of an implied or referenced person object. |
5 | Proxy | Any role derived from a kind of intermediation on behalf of an implied or referenced object. |
6 | Target | Any role derived from a treatment with the intent to change an implied or referenced object. |
7 | Capability | Any role derived from an acquired, trained, tuned, configurated, or calibrated capability of an implied or referenced object. |
8 | Collectiveness | Any role derived from collective characteristics of implied or referenced objects. |
9 | Leveragability | Any role derived from leveragability of an implied or referenced object. |
The following table illustrates several common data element concepts that many organizations use and perhaps have a requirement to exchange. The O-DEF provides a standard name plus a language independent identifier to support semantic interoperability between different natural languages. The syntax to connect the parts is also defined within the O-DEF standard.
Concept | O-DEF Name | O-DEF ID | Data Element |
|---|---|---|---|
Person Birth Date | Person_Date.Birth | 1_10.1 | 10-Jan-95 |
Person Family Name | Person_Name.Family | 1_2.1 | Brown |
Person Given Name | Person_Name.Given | 1_2.2 | John |
Customer Person Last Name | Person~Trader.Customer_Name.Family | 1~1.1_2.1 | Smith |
Customer Enterprise Name | Enterprise~Trader.Customer_Name | 2~1.1_2 | XYZ Corporation |
Patient Last Name | ~Target.Patient_Name.Family | ~6.1_2.1 | Smith |
Product Production Date | Product_Date.Production | 10_10.7 | 20-Mar-17 |
Product Delivery Date | Product_Date.Delivery | 10_10.15 | 27-Mar-17 |
Product Price | Product_Amount.Price | 10_7.2 | $295.90 |
Event Price | Event_Amount.Price | 5_7.2 | $40.00 |
Condition Description | Condition_Text.Description | 6_13.2 | Severe Damage |
Environment Description | Environment_Text.Description | 7_13.2 | 90 MPH Winds |
Resource Expiration Date | Resource_Date.Expiration | 3_10.5 | 10-Jan-20 |
Resource Calibration Date | Resource_Date.Calibration | 3_10.17 | 5-Apr-17 |
Person Salary | Person_Amount.Salary | 1_7.10 | $10,000 |
Resource Rent Amount | Resource_Amount.Rent | 3_7.18 | $2,500 |
Process Completion Date | Process_Date.Completion | 9_10.8 | 15-May-19 |
The O-DEF also supports plugins of certain existing standards. For example, the ‘product’ codes in the O-DEF standard are drawn from the United Nations Standard Products and Services Codes (UNSPSC). Originally developed by the United Nations Development Programme in 1998 to facilitate the delivery of supplies to developing countries and aid to disaster zones, the UNSPSC is essentially a list that describes tens of thousands of products and services, and ascribes a unique code to each.
The following is an example use of the UNSPSC plugin within the O-DEF standard.
Within the UNSPSCv18, Code Title “Passenger rail cars” = Code “25121603”.
Each passenger rail car has a unique identifier.
For this example, the context is from the point of view of a manufacturer of passenger rail cars, and therefore the O-DEF object class is “Product” and the O-DEF identifier is “10”.
The O-DEF object class name is:
Product;UNSPSCv18:[Passenger rail cars]
The associated O-DEF object class identifier is:
10;4:[25121603]
The complete data element concept name is:
Product;UNSPSCv18:[Passenger rail cars]_Identifier
The complete data element concept identifier is:
10;4:[25121603]_1
Data integration starts with the development of a data model that helps identifying the various owners of data to be integrated. The Open Interoperability Framework provides insight in the challenges to be overcome in order to combine data from different owners in a single (virtual) dataset. The O-DEF is an essential tool that enables interoperability at the semantic level to support data integration.
List the works cited in the text.
(Please note that the links below are good at the time of writing but cannot be guaranteed for the future.)
Identify the author here and discuss his/her background as it relates to the topic of the document. [Style: WP Paragraph]
Identify the author here and discuss his/her background as it relates to the topic of the document. Identify the author here and discuss his/her background as it relates to the topic of the document. Identify the author here and discuss his/her background as it relates to the topic of the document. Identify the author here and discuss his/her background as it relates to the topic of the document. Identify the author here and discuss his/her background as it relates to the topic of the document. Identify the author here and discuss his/her background as it relates to the topic of the document.
The Open Group is a global consortium that enables the achievement of business objectives through technology standards. Our diverse membership of more than 800 organizations includes customers, systems and solutions suppliers, tools vendors, integrators, academics, and consultants across multiple industries.
The mission of The Open Group is to drive the creation of Boundaryless Information Flow™ achieved by:
Further information on The Open Group is available at www.opengroup.org.
< >