EADS expert in the area of Information Technologies, Nicolas Figay is involved in research and industrial projects dealing with PLM Enterprise Applications Interoperability and Data Exchange, to support collaboration within Extended and Virtual Enterprise.

After obtaining E.I.S.T.I. Engineer diplôma in 1991 (Ecole Internationale des Sciences du Traitement de l’Information – CERGY- France), with specialization related to mathematics for the decision, he has been working for Aerospatiale (which became EADS) first as application development project leader and computer scientist, second as a researcher within the field of Computer Aided Product Development and System Engineering.

Involved in research projects dealing with usage of STEP (RISESTEP, SAVE) and interoperability of enterprise application (IDEAS FP5 Roadmap, ATHENA FP6 Program, OpenDevFactory), he is currently involved within Aerospace & Defense industrial projects (EADS Phenix, SEINE, BoostAerospace)as standard expert, but also in order to disseminate results of research projects within operational projects and to collect emerging needs and challenges requiring research activities, in order to produce accurate specifications for starting research projects such as CRESCENDO.

In the same time, he is involved in standardization activities (AFNOR IDMI and CN DSTI - French counterpart of ISO TC4 SC184 - , ASD Strategic Standardization Group and EADS Strategic Standardization Committee), as a teacher at I.T.I.N. (Institut des Techniques INformatique with a cursus dedicated to interoperability of enterprise application, based on usage of both manufacturing standards and ICT standards, all along the lifecycle of a software product and enterprise application and as a student at LIRIS (Université Lyon 1), where he is preparing a thesis within the team of Parisa Ghodous (Interoperability of Technical Enterprise Application within the extended enterprise).

The different activities allowed to develop a good knowledge of interoperability issues, from organizational, disciplines, application and ICT (Information and Communication Technology) viewpoints, and to support European Commission and research community to set up projects dealing with holistic approaches encompassing Enterprise Modeling, Model Driven Application Engineering, Service Oriented Architecture and Ontology usage.

ATHENA was the opportunity to work on a STEP binding to produce Semantic Graphs based on OWL Full from Express and P21 files which can be easily enriched with external knowledge and navigated a graphical way (OWLViz, Jambalaya,etc).

As a result, it appeared that automated transformation from EXPRESS is most of the time not appropriate, due to difference of expressivity between EXPRESS and OWL. In particular, no construct exist in EXPRESS to deal with relations/properties which is one of the foundation of OWL and allows to deal very simply with xyRelationship, xAssignment entities defined in STEP application protocols. It also provides way to deal simply with the SELECT types in EXPRESS.

The choice not to use OWL DL was motivated by the fact that application protocols are proposing a schema to specify, design and define a product all along the lifecycle, with the need to be able to produce construct that can be considered sometime as classes, sometimes as individual. Or a constraint put on OWL DL is a constraint on a thing that must be an individual or a class or a property (with exclusive choice). Establishment of a semantic graph brought a sufficient value without adding some complexity trying to produce DL models, with not yet mature engines.

With OWL2 and more mature reasoning engines (such as Pellet, Fact++), emerging large RDF stores, better management of import/export, annotations and subProperties, reconsidering OWL DL as a target is today more relevant, in particular to formalize logical mappings in OWL and to take advantage of reasoning engines for transformation through inference, and for logic validation of mapping between models (better than the way it is currently done within STEP application protocols).

Formalization exercises (description, mapping) allowed to identify some issues related to modeling weakness (from a logical point of view) for some application protocols, in particular due to the numerous ways to formalize relationships at application protocol levels, as EXPRESS does not support it. In the reverse, all the rules formalized with EXPRESS can't be formalized in OWL, as descriptions of operations and functions on literals are not supported by OWL. How to establish equivalence of models where some set of literals is equivalent to another as it can be obtained by functions? An example is definition of a circle, which can be obtained and is fully defined by different sets of parameters and associated way to construct it. If two modeling languages are not using the same, do we consider they are not equivalent? And when willing to transform the data from one to the other, reasoning is not sufficient, as we also need to ... calculate. (1VDC)

Finally, studying OMG MDA, UML, XMI and MOF, it also appeared that both EXPRESS and OWL are very poor when dealing with the specialization of the relationship required for Product Development. Nor EXPRESS nor OWL are providing dedicated constructs for breakdowns, being aggregates or compositions, while UML do. Within application protocols, such constructs are proposed (metamodel level) while it is part of the modeling constructs with UML or SysML. It should be the same thing for OWL which does not propose such construct, which are fundamental when designing a product. (1VDD)

In the reverse, UML being a tool used by designer at the design phase, it is very poor to deal with individuals and the way to formalize logic constraints is very complicated compared to OWL. (1VDE) Additional point, we are in a world where each standardization group produces its own modeling language with different goals and usage, but describing the same world. So why to use within Manufacturing community EXPRESS, OWL or UML. A response is may be "let's use together for appropriate usage". Most of the studies conclusion is: "languages are not equivalent but complementary". So why to choose?

One issue, nevertheless, is what was called "impedance mismatch" for people dealing with Object Relational Mapping, formalizing that we will loose information going from one language to another language.

Due to over numerous languages to use, are we going forward "impedance misMESS"?

Semantic preservation going from a representation of the same reality using one language to a second representation of the same reality using another language is more an more important, in order to avoid "formal language silos" and to produce set of reprentations using different languages but insuring coherency of these representations; effective usage of the produced formal models is also expected.

From industrial viewpoint, as we are more and more using Commercial Of the Shelves and as we are focusing in our core activities, it means that our providers are not using the same language than us. How to reconciliate enterprise, application users, and software product and developers viewpoints and make them talk together?

Today several initiatives are trying to define a framework to deal with numerous manufacturing eBusiness standards (ASD SSG, EADS SSC), with a difficulty due to usage of heterogeneous modeling languages based on different paradigms.

A solution could be to work on sets of coherent standardized languages, covering complete spectrum of needs and phases of application lifecycle. I'm convinced we have not to develop them, but to select those which are today relevant, and to learn how to use them together. EXPRESS, UML and OWL are candidates to be part of such a set, but should be completed by emerging SOA and BPM related languages which are not information centric, but are focusing on other aspect than information models.

It is nevertheless a pity that SOA W3C standards are syntactic, and not semantic. What about W3C recommendations for semantic services?

The presentation that will be made during the teleconference will synthesize all this, and extract some potential requirements to the ontology community.