X-Track-A2_CommuniqueInput--AnatolyLevenchuk_20120325a.txt


Date: Sun, 25 Mar 2012 17:01:40 +0400
From: "Anatoly Levenchuk" <ailev@asmp.msk.su>
To: "'Ontology Summit 2012 Organizing Committee'" <ontology-summit-org@interop.cim3.net>
Subject: Re: [ontology-summit-org] Ontology Summit Communique: Track Content Drafts- Due 25 March


Federation and Integration of Systems track synthesis
 
Ontologizing is a common practice within federation and integration of systems community. Most often ontology is used for provide mappings for data models of participating systems. This mappings would be done in two main architectures:
-- point-to-point (ad hoc) with an ontology knowledge for clarification of meaning of data in each systems
-- to common ontology (reference data) for a federation of systems
 
Also ontology can have use of providing powerful concepts (mereology etc.) for federation architectures description, adding means of federation description for architecture languages (both systems architecture and service architecture languages). There are no consensus yet what such ontology-based architectural language can look like.
 
Examples of systems integration/federation:
-- PLM systems in systems engineering is a means for system integration for CAD/CAE systems. This is already ontology/terminology based on a base of proprietary ontologies of PLM/CAD/CAE vendors. Most of PLM systems have federation/integration tools based on ontology.
-- there are deficiencies in PLM federation (multiple PLM with different ontologies/terminologies/data models), but strong demand from engineering community. PLM vendors not in help here because this require usage of vendor-neutral ontology.
-- there are multiple domains that need integration in this fields
is problems with process/project/case execution integration, but this is more experiments now and cannot be replicated as a product on a market.
 
 
Examples of neutral (“ontology as a standard”) ontologies, specifically targeted for systems integration/federation are ISO 15926, HDQM, Gellish, IDEAS. 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.
 
Up today there is no understanding for what can be mapping language for federation/integration. Opinions are different:
-- FOL as minimum
-- HOL as actually needed
-- general purpose language (with access for both mapping ontologies in their native representations),
-- combined of all above.
 
There are multiple questions about usability of semantic web (RDF/OWL ecosystem) for systems federation purposes, but this is mainstream now.
 
Main difficulties for ontology work in federation/integration of systems:
-- absence of quality reference data (available proved/trusted domain ontologies). Expectancy for linguistic processors that will parse engineering, financial and other domains standards and will provide this data. Expectancy of distributed manually producing such a data (ontology crowdsourcing) is not realized up to now. Multiple complex for ontologization domains: process/project/case management, geometry of engineering CAD systems, multi-physics real time models, etc.
-- no knowledge for distributed ontology development/evolution and federation (to map data of different systems first you should federate your reference data). Ontology versioning is a nightmare. Ontology granularity is an issue.
-- performance issues (including a) performance of ontology engines and b) performance of federated SPARQL endpoint on network)
-- quite complex low level API for data access in most available federated systems
-- no ontology/terminology of system federation/integration architecture domain and mapping/translation/compiling domain: this lead to difficulties in collecting of good practices in programming, modeling, ontologizing in-the-large and comparison of existing implementations/frameworks.
 
* * *
 
Sorry, this was not edited and approved by Cory Casanave, thus he may will wish to rewrite any part or all of this.
Not sure what address I need to send this, therefore I send to Organizing Committee 2012 list.
 
Best regards,
Anatoly