OntologySummit2012: (Cross-Track-A2) "Ontology for Federation and Integration of Systems" Community Input

Track Co-Champions: Mr. CoryCasanave & Mr. AnatolyLevenchuk

The Problem and Our Mission:

Title: Ontology for federation and integration of systems

Problem statement: The ability to federate and integrate data, processes services and systems components is at the foundation of the modern enterprise, business eco-system and open, collaborative government. These capabilities are essential for enterprise supply chains, fighting terrorism, business, government, inter-organizational collaboration and integrating enterprise applications. Yet, this essential capability has remained difficult and expensive to achieve in complex systems which are frequently isolated, stove piped, and difficult to integrate. The inability of our systems to share information hampers the ability of our organizations to collaborate and for our processes, services, and information resources to work together. There are multiple standards, methodologies and tools’ being applied to this problem, yet the problem is still pervasive in every major organization and community. Systems engineering is successful when applied to a single system but lacks the capability to effectively leverage and integrate data in systems of systems that exist. Ontologies and semantic technologies are seen as part of the solution but have yet to become mainstream in most organizations but there is no consensus on the terminology, ontology or architecture supporting federation and integration.

Mission Statement: This track will bring together a cross-disciplinary group of experts to address the application of ontologies and semantic technologies to the federation, integration and sharing of processes, services and information across systems. Topics will include:

• Statements of real-world problems and use cases that demand federation and integration
• Analysis of current standards and techniques (including semantic technologies) for solving federation and integration – where these techniques are succeeding and where they are lacking
• The viewpoint of experts on the application of ontologies and semantic technologies to the federation and integration problem elaborated with the required approaches, standards, tools and technologies
• Terminologies and architectures supporting semantic integration and federation
• A discussion of practical outcomes and next steps

The outputs of this track will include:

• Categories of federation and integration use cases
• Solution architectures that include the standards, technologies and methodologies that may provide solutions
• Integration and federation terminology
• Experiences relating use cases and lessons learned

see also: OntologySummit2012_SystemsFederationIntegration_Synthesis

---

Questions and Answers

(from Ontology Summit list)

System Integration, Federation, Interoperability: too many terms with not clear meaning. Different communities of practice use different words and there are difficulties in understanding. Definition of system is not clear, definition of system of systems (federated system?) is not clear twice. Systems engineering have "system integration" process that provides assembling of ready to operate system from pre-implemented parts/modules. What kind process and what system (or system of systems) life cycle we address when speaks about systems/services integration, federation, interoperability?

MatthewWest: Let me start with Federation and Interoperability. These I think are easy and reflections of each other. Federation is what you have when you have established interoperability of some systems. Information Systems are interoperable when they can exchange the data that enables them to work together. Federation of some systems is a particular set of systems that are interoperable.

System Integration is a little more difficult because I have known two meanings over the years. In the early days, system integration meant the reengineering of an existing set of systems into a single integrated system. There is probably little mileage in this approach by now, but it may still be happening. Nowadays it seems to me to be being used as what you do to achieve interoperability.

Service-oriented approach suggests pay most of attention not to systems but to services. Should we speak about service integration, federation, interoperability?

MatthewWest: There are a couple of things here. The first is that a service is what something does. It has long been established for systems of any sort that decomposition by function is the most appropriate way to componentize a system. However, this is far from being the most important aspect of SOA. The key concept behind SOA is reuse. This both reduces cost and improves quality of software. So the secret of SOA is reusable components.

How integrate, federate and provide interoperability of processes (e.g. workflow traversal through several BPM engines, adaptive case management systems, complex event processors)?

What can be terminology, taxonomy, ontology of systems federation, integration, and interoperability?

MatthewWest: I think ontology is essential for SOA, though I do not see much explicit use of it. Terminologies are of course very important for integration, this is the common language that allows systems to talk to each other. Reasoning is usually done by bespoke code rather than general purpose reasoning engines, but can be particularly useful in interfacing systems to a common terminology.

How this ontology can help to build and assess architectures and frameworks for system/services integration, federation, and interoperability?

How we can express integration, federation, interoperability architectural patterns (like "bus" or "plug-ins") in such ontology?

There are ontology frameworks that specifically address integration, federation and interoperability on industry-wide scale (e.g. ISO 15926 that intended to system life cycle data integration). What special properties should have ontologies that serve integration, federation, interoperability purposes in comparison with other kinds of ontologies?

MatthewWest: We did quite a lot of work on this before we started (ISO15926). The most important things were:

• The broadest possible context,
• Extensible,
• Enable anything to be said that is valid (i.e. no artificial restrictions),
• Explicit ontological commitments that are followed consistently
• Strong methodology so that the same thing is represented in the same way by different analysts, including,
  • Choice of alternative approaches left open by ontological commitments,
  • Consistent representation so the same thing would get pretty much the same name from different analysts,

What languages we need for integration, federation, interoperability?

MatthewWest: You need a mapping language, which my experience suggests needs to have the equivalent power of First Order Logic.

What lessons we learned in integration, federation and interoperability projects that tried to use ontology-based methodology for achieve its goals?

MatthewWest: The most important lessons we learnt were:

• The place where you compromise because you think that will never happen, will happen within 6 months,
• You can start small and grow, A little helps a little, a lot helps a lot.
• Have a quality improvement plan, the larger you get and the more people involved, the harder it is to maintain consistent quality.

What are the special capabilities ontologies have to offer for federation and integration that are not served by more traditional federation and integrations approaches such as ETL, SOA, Event Systems, etc?

EricLittle: They often work in conjunction. I currently have a client in the medical device industry, for whom we have built a very large semantic integration system which runs in a private cloud computing system at their facility. It presently contains 36 ontologies (which link together 9 DBs, plus all spread sheet materials data). The ontologies are federated into data source, data source integration (single and multi source), domains and product genealogy (where advanced business/scientific rules sit). We use several layers of SOA to transmit data to a series of user-driven applications (desktop, laptop, mobile, apps, etc.). We have an ETL layer that provides a “semantic cache” necessary for integration with certain business intelligence UIs where people can do ad hoc querying or drive through the data in a multitude of ways. We also are beginning to employ business process modeling toolsets to provide process mappings, alerts, security layers, etc., across the enterprise and link that information to the data sources that relate to materials, equipment, documents/reports, tests, R&D data, production data, etc.

In short it is not like one should ever conceive of having an ontology do all of those things. The semantics provide the common vocabulary and set of integrated models, the logics/reasoner run over them in the form of queries, rules, autoclassifications, etc., the cloud provides the hardware, provisioning and computational horsepower to perform functions over large data graphs, the SOA layers provide means to move information to other technologies within the cloud, etc.

KatherineGoodier: I also find that in applying ontology and semantics to solving federation issues, the solution always involves a combined approach.

What features of current ontologies, or related inference capabilities, are or are not particularly useful for federation and integration?

EricLittle: Overly large models which are not federated, overly complex logics which are not decidable. People want to examine large amounts of data very quickly. This is not an academic exercise in this world. Things need to be fast with very straight-forward and intuitive front ends.

KatherineGoodier: The close integration with a co-produced front end is an innovative practice. Involving the information consumer in the design works for me.

Are upper and/or mid ontologies useful and/or necessary for semantic integration and federation?

EricLittle: Yes, very useful, but need to be federated and capable of expansion and integration with other data models. The idea of making SMEs accept someone else’s language and terminologies is simply not realistic. Good semantic systems I have seen have highly reusable components and are extensible without a lot of extra investment on the part of the company.

Where do existing ontological languages such as OWL, CL or basic FOL meet or not meet the needs of federation and integration?

EricLittle: This depends on what you want to do. My company (Orbis Technologies uses different logics for different applications). The one mentioned above utilizes Object Logic and it works very nicely.

What is the relationship between conceptual modeling and and/or logical models and ontologies?

EricLittle: I’m not sure there always is one – other than to say I understand conceptual models to be epistemic models, probably linked to specific perspectives, logic models are how the reasoner is going to perform (but I am not going to pretend to hold to this distinction). One thing everyone in industry needs to be aware of is explicitly capturing different kinds of data and having different parts of the models that can perform different tasks. Real world objects (documents, equipment, products, personnel, etc.) should be placed in real world domain ontologies. Information entities (metadata, ontologies about data objects or measurements, etc.) should be properly placed in their own domains. Entities extracted from NLP processing should be placed in its proper spot. Inferred relations and autoclassifications should be put in their spots, and so on. This way people (and reasoners) can better interpret and use the data. Doing this little bit of metaphysical cleanup is useful for moving forward as projects continue to evolve and grow. Clients can be educated into this systems approach for the ontology and often will see the value once the system begins producing good results.

What tools ,standards or other capabilities are missing?

EricLittle: Scalability is a big issue still for many ontology solutions. This often can be fixed, but not through ontologies per se. One can enhance the system on several levels. First, at the data source level itself (we sometimes can clean up the tables themselves, normalize DBs, etc.). One can federate out the models at various layers to better handle queries and rules. One can use things like Hadoop/MapReduce approaches to be able to thread queries and algorithms so as to only utilize those parts of the models needed for certain reports, queries or investigations. Again, ontologies themselves do not really provide all of the answers here. This is a systems approach – sometimes one even cheats on the front end by performing lazy loading, etc., to make the experience seem faster than it is because things are loading in the background.

KatherineGoodier: I agree.

If ontologies solve this problem, why isn’t the problem solved?

EricLittle: I think my position is clear by now – ontologies do not solve many of these problems. This is like asking “if I have a wiring diagram that shows the entire structure of my car, why does it not fix itself?” The mechanic can use that diagram to solve problems easier than poking around blindly, but the ontology is just a map or a model of the classes, attributes, time stamps, events, etc., that people care about within a certain set of domains (I’m sure I will get flamed by my fellow philosophers for making this kind of crude statement – and I get the value of deep metaphysics). The point is the ontology is NOT an end-to-end system, it is part of the puzzle. It provides an important backbone for all of the things I list above, but it does not provide the solution in isolation.

---

Enter your input below ... (please identify yourself and date your entry)

• ...