Nicolas Blanc

Thomas Montroig

Joseph Roumier

Laurent Romary

Jacek Szymanski

Denis Reboul

Building Conceptual Models by Knowledge Management Methodology

ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

I. INTRODUCTION

The Proteus project is aimed to integrate existent software tools not designed to work in co-operation in a complete system based on information exchange. By this way, we are considering that each tool brings services that will be used to help the end-user to deal with its tasks within the maintenance operations. So, Proteus is a Service Oriented Application dedicated to the maintenance field, thanks to the use of existent software it is intended to gather and manage.

From the end-user point of view, all the operations are performed by the same tool: the general Proteus Application. But actually, taking all the architecture into account leads the fact that each action implements many calls to services spread among the various tools used in the field of maintenance. Moreover, whichever is the concrete Proteus application, the main functionalities will be the same in spite of the differences revealed on the tools that are chosen for the application.

These observations reveal that even if Proteus is designed as a fully distributed system, a centralised organisation needs to be brought as a keystone of all the architecture. This keystone is identified as the "Proteus Information Repository" (PIR) and clearly puts the stress on the close cooperation needed between tools by furnishing them an unique way to communicate and by listing the possible existing link between resources thanks to a representation of the application domain.

From the project point of view, all the partners working on the research tasks need to specify how the tools they are describing will communicate (this is the ideal description of a tool). To do so, they also need to know how the other tools communicate when they need to use information they do not handle. The problem raised here is a computer-oriented vision of the application needed to describe the tools and the services. Here again, the notion of "Proteus Information Repository" helps the researchers to have a common basis on which to work: it provides common languages to describe architectural resources and services.

The main key-point of the Proteus Information Repository is its ability to combine two complementary approaches designed to be used at different points but describing the same notions from different points of view. These approaches and their full ability to cohabit are the subject of this paper which will first of all describe the different aspects of the description before showing how the strong link is built between them. Then, the use of these models will be shown at different steps of the Proteus platform implementation.

II. TWO ASPECTS OF A DESCRIPTION

A. Describing distributed services: a common language

Since the project includes many partners working on different issues but with the same goal, a common language needs to be used in order to describe every processes. This language must enables every partner to:

-have a quick general view of a process, -define precisely the tools on which the partners are working, -get information without having to be an computer expert.

These needs lead to use a tool as simple as possible which could describe all the tools to enable efficient communication within the project. The language proposed is UML (Unified Modelling Language) because of its graphical view understandable by a non computer-specialist but very close to the structures it describes.

Thanks to this language, the description of the ideal tools becomes possible. Describing ideal tools is essential in the scope of the project: in the architecture of the final application, Proteus must be adapted to the concrete application. That is to say that without knowing which will be the functions of the tools that will be used in a concrete application, a corresponding ideal tool must be described. A tool may be defined as a set of services and in the scope of maintenance, we find the following tools:

-CMMS: Computerised Maintenance Management System -SCADA: Supervisory Control And Data Acquisition -ERP: Enterprise Resource Planning -Expert System -E-documentation server Whichever will be the concrete tool, a component will be added to adapt it to the Proteus requirements. This component is an ICA (Intelligent Core Adapter) which will be the bridge between an ideal description and the concrete tool. Thus, from the Proteus point of view, there will be allways only ideal tools with well defined interfaces.

B. Describing a domain: a knowledge representation a. Why an ontology ?

To ensure te consistency between the differents elements that compose an industrial domain, to permit their cooperation, it was mandatory to use a common representation of the information that lie in the domain [Huber02]. This knowledge representation has to be built to achieve a goal, this task is user-driven [Noy00]. This is why in the Proteus project, we were lead to propose an Ontology for Industrial Maintenance, in which the key concept is the Equipment.

The definition of an ontology we chose for Proteus is basically a "formal description of concepts in a domain of discourse […], properties of each concept describing various features and attributes of the concept(slots (sometimes called roles or properties)) and restrictions on slots(facets (sometimes called role restrictions))" [Noy00].

Moreover, an ontology or any other categorization system for knowledge is a way to access more easily and faster to the required information [Rosch78]. Industrial Maintenance deals with many different kind of concepts and services, and the amount amount of information to deal with might be very challenging, this is why using an ontology is required.

b. An ontology for Proteus

The ontology designed for Proteus is entitled the PIR (Proteus Information Repository). It is designed to allow the highest interoperability and compatibility with other systems and applications.

For these purposes, the PIR is modular following two axes :

-a vertical axe (cf. fig.

A. Applying services to a concept

To link the UML representation with the ontological one, we need to list for each instance (resource) all the available applicable services.

General Concepts (GMO) Application Profiles

Industrial contexts

High interoperability Wider Coverage

Lower interoperability Lower Coverage

External Sources This resource-oriented representation wills permit us to consider that the resources are handled by services furnished through external software tools.

For this reason, a table will be use to summarise the set of methods that can be applied on a basic resource:

Resource Service 1 Method 1.1 Method 1.2 Service 2 Method 2.1 Method 2.2
Let's consider an equipment to maintain, a pump, and its spare parts. Some services are dedicated to provide them methods to be handled, as represented below:

Has spare parts Fits to equipment

The services applied on these two resources are: Pump Spare Parts Management getSparepart(idEquipment) Spare parts Spare Parts Management getEquipment(idSparepart)

We will also suppose that an Equipment has an attribute giving a unique identifier enabling the various tools to identify it uniquely by always passing it as a parameter when the method of the service is called.

B. Setting top level concepts (GMO stabilisation)

The GMO should be the representation of the basics of maintenance resources that must be handled to perform a full maintenance process. This point of view introduces a maintenance-oriented description in order to have a more adapted tool.

The resources described in §3.1 will have to comply with the ones listed in the GMO.

The GMO representation makes it possible to describe and classify the resources with a hierarchical point of view. The services identified by the representation exposed in the previous sections then links the resources together: an attribute described in the ontology is by this way represented by a service furnished by a "Service Provider" (such as CMMS, E-Doc, …). By this way, at the implementation point of view, an attribute in the GMO is represented by a method found in a service set within a maintenance tool.

C. A continuous process

We will now consider the job of every partner in charge of the services described in §3.1 that will list the method that can be applied on the basic resources. For example each partner will find in the GMO a class called "Equipment" with no method listed at this starting point. Then, he will complete the table with the methods he provides.

The partners are organised in working group. The proposal will be validate for each working group and then widespread to all.

A specific task force, the PIR task force, does the validation process of the proposals. In each working group a corresponding mender of the PIR task force will help in the definition of the services. As the Task Force gathers application experts and modelling experts, the model will be consistent and very close to the description needed to perform a well definition of the domain.

IV. USAGE OF THESE DESCRIPTIONS

One of the first usages of this multi-oriented approach is a more efficient organisation of the tasks performed by the various partners by having common basis on which to work. But another aim for the notion of a centralised information repository is also to be ran in a production implementation. This concrete application may be used at two steps of the implementation: the configuration step and the running step.

A. At the configuration step

The first step when setting up an installation is to configure it. In the case of the Proteus platform, the configuration stands for the listing of the available services and the comparison with the attended services.

Indeed, the conceptual Proteus platform describes a set of ideal services that need to be furnished by the software maintenance tools such as SCADA, e-documentation server, expert systems, CMMS and ERP in order for the platform to run efficiently. All the services described as explained in § 3 must then be located in the scope of the real implementation. Everything would be easy if all the software tools that can be found on the market had the same functionalities. But this is unfortunately not the case and depending on the installation that has already been performed before the decision to implement the platform on a concrete site, some services may be found in a tool or another (sometimes in several ones). Starting from the observation that the platform must be adapted at the application field without having to modify any of the existent tools, the issue becomes here: how to determine which real tool is the most representative of an attended function ?

The solution is here again to use the centralised repository known in the scope of Proteus as the PIR which will bring enough information to design a method to configure the platform.

As the PIR gathers a description of all the basic concepts on the instances of which the ideal listed services can be applied, the parallel must be done with the already installed tools. Actually, with a well implemented configurator, the configuration becomes an audit consisting in listing the available services with their location (the tool implementing the service). Then, thanks to the configurator tool, each ideal service will have an equivalent in the concrete tool and the linking of the "ideal description" and the "real description" will build the platform.

Each ideal service is consequently located and the platform is ready to be launched.

B. At a running step

As mentioned in §4.1, the PIR contains all what is necessary to have the platform running. But actually, another condition is required to get a fully functional platform: the knowledge of the structure of the services. This knowledge is here offered by the normalisation of the interfaces defined for every set of service: the ICA. Having the information of the location of a service and its description enables so to get a complete running system as show the following scenario.

Let's consider a service called to order Spare Parts relative to a given Equipment. This service knows how to calculate the cost of a Spare Part, where to send the order and all other ordering relative operation, but it can't find by itself the Spare Parts needed by an Equipment.

That's why it needs to call the service dedicated to find this type of resource linked to an equipment. As it is designed to work in co-operation with this other service, the ordering service exactly knows how to call the service if it is available: it knows the method to call, the parameters to give and the structure of the returned result. The information it needs is: where can I find the service ? Is it available on this platform ?

The consequence of these question is that the service must search for the required information. As previously explained, this kind of information can be given by the PIR. So, the service we are dealing with will call the PIR to know if the type of information needed is available on this platform. If it is, the location (address) of the service will be used to call it.

The power of the PIR notion is here again demonstrated: by its full integration in the project (from the conception of the project to the running mode of the platform without forgetting its ability to get a platform configured), it gathers all the information needed to get quick and relevant access to specific data.

V. CONCLUSION

This approach of the description of a domain modelized differently depending on the intended application shows the ability to make cohabit two complementary visions. Thanks to this knowledge management methodology, a domain can be described by specialists of the application field in order for computer specialists to develop special tools on the same application field, without having to be experts in the domain. This brings a powerful collaboration enlarging the capabilities of tools dedicated to an application field (here industrial maintenance) with a strong link to the needs reported from the end-users.

Figure

  Figure x.x PIR vertical modularity

Figure

  Figure y.y PIR horizontal modularity at GMO level


Harry Bunt
email: harry.bunt@uvt.nl

Laurent Romary
email: laurent.romary@loria.fr

Standardization in Multimodal Content Representation: Some Methodological Issues

In this paper we discuss some basic methodological considerations of the activities undertaken in the ACL-SIGSEM Working Group on the Representation of Multimodal Semantic Information. This independent expert group was founded on the instigation of the International Organization for Standardisation ISO for investigating the possibilities to develop well-founded guidelines for the representation and annotation of semantic information in interactive multimodal contexts, with the aim to support the interoperability and reuse of multimodal and language resources.

Introduction

In response to the growing recognition of the importance of interoperability and commonality to enable the sharing, merging and comparing of language resources for developing NLP applications, the International Organisation for Standardisation (ISO) has formed a subcommittee (SC4, Language Resources Management) dedicated to the preparation of international standards and guidelines for the representation and annotation of linguistic data. Proposals are for example under development for morphosyntactic annotation [START_REF] Clément | Language Resource Management -Morphosyntactic Annotation Framework[END_REF], for lexical representation [START_REF] George | Language Resource Management -Lexical Resource Markup Framework (LMF)[END_REF] and for an XML-based representation format for feature structures (Lee, 2004).

Another potentially important area was recognised to be that of representing the semantic content of linguistic data and, more generally, of multimodal data, where language is used in combination with other modalities. As a first step in this area, an independent expert group was formed in 2002 within ACL SIGSEM, the Working Group on the Representation of Multimodal Semantic Information (MM-SemR). The activities of this Working Group so far consist primarily of:

1. studying and comparing existing representational systems and their underlying principles (see e.g. [START_REF] Bunt | Underspecification in Semantic Representations: Which Techniques for What Purpose?[END_REF]; 2. identifying commonalities in different approaches to semantic representation and annotation; 3. developing methodological principles for identifying and characterising representational concepts for multimodal content.

The present paper discusses some initial steps relating to (3), inspired by ongoing discussions in the MMSemR Working Group and by methodological considerations that have emerged from ISO activities in other domains.

It may be noted that, in general, ISO activities in the area of language technology are not so much aimed at stan-dardization in the sense of proposing particular formats that should be used, but rather at identifying and documenting valuable and common concepts in different approaches and providing guidelines for using these concepts to support interoperability and reuse of resources.

Semantic Content Representation

The representation of semantic content is crucial for intelligent multimodal dialogue systems, where users may for example combine speech with graphics, gestures, and the use of facial expressions and where the system may combine speech, text, graphics, and other sounds and visual elements. An intelligent multimodal interface requires the fusion and coordination of multimodal input and output at a semantic level, taking into account the current state of the interaction and the context. The communication between the components of such a system relies on an enabling representation system that should support all stages of multimodal input processing and output generation.

Multimodal interactive systems combine more than one 'language' in which to exchange information, typically including some form of natural language (NL) in combination with graphics, i.e. with a gestural language. This means that multimodal semantic content includes NL semantic content. In view of the overwhelming amount of ambiguity and vagueness inherent in NL, computational semantics has in recent years moved in the direction of computing underspecified representations, that capture semantic information in an utterance rather than represent 'the meaning' of the utterance. This is a useful development for multimodal semantic fusion, and it has the effect that the difference between semantic representations and semantic annotations becomes gradual rather than principled, thus allowing the use of common concepts.

Prerequisite to semantic information representation is a well-delineated notion of 'meaning' which is appropriate in a multimodal context. [START_REF] Bunt | Towards multimodal content representation[END_REF] have pro-posed to define meaning as the way in which an utterance is meant to change the information state of an interpreting system upon understanding. (The final clause of this definition serves to exclude state-changing effects due to processing beyond establishing the utterance meaning). This definition is broad in the sense that it includes aspects of meaning which are often regarded as "pragmatic" rather than semantic; it is also "pragmatic" in flavour in considering utterance meaning, i.e. meaning in context, rather than sentence meaning.

In the area of multimodal content representation, ISO does not aim at developing a standard fixed representation format. That would be seen by many researchers as a hindrance rather than as support for their activities. Instead, future ISO activities could sensibly aim at providing welldefined concepts ('data categories' in ISO jargon, or 'descriptors') as a basis for semantic representation and annotation. Note that 'descriptors' (or 'data categories') are abstract concepts, not elements of a particular format or representation language.

A semantic descriptor will often make sense only in combination with certain other descriptors, and not in combination with others, reflecting that alternative semantic theories use different concepts. The ultimate goal is therefore not to propose a single set of descriptors to be used, but a larger set from which coherent subsets can be taken according to one's theoretical preferences. If {C 1 , C 2 ,.. C n } is such a coherent set, its use in building representations means that a representation language L a has corresponding descriptive terms {c a1 , c a2 ,.. c an }.

One of the requirements on any content representation system is that of "semantic adequacy", by which is meant that the representation language itself has a well-defined semantics. For the representation language L a , a modeltheoretic semantics can be given by specifying a model which will have elements {d a1 , d a2 ,.., d an } as denotations of the corresponding descriptor names in L a . For instance, a representation in Minimal Recursion Semantics [START_REF] Copestake | Minimal Recursion Semantics[END_REF] may have the part [AGENT: john], containing the descriptor name AGENT, which in a model M a = < D a , F a > corresponds to a set of pairs of individuals, such that the second element of each pair is the agent of the event corresponding to the first.

Models, Data Models, and Metamodels

Looking for commonalities in alternative approaches, as is typical for ISO work, often implies looking at alternative models. In particular, when computational resources are concerned, the notion of a data model is often used to capture basic aspects of a particular approach, usually in a semi-formal way. [START_REF] Codd | A relational model for large shared data banks[END_REF] is often credited for having introduced this for discussing the organization and meaning of the contents of data bases (in particular his famous 'relational data model'). If we want to capture what several models have in common, we may move to a more abstract level, and this is where the term 'metamodel' has emerged. The claim of the present paper is that this semi-formal notion of metamodel may be construed more formally by relating it to the notion of model as used in model-theoretic semantics, and may be helpful as a methodological tool for the definition of abstract concepts for the representation and annotation of semantic information.

A model, in model-theoretic semantics, does two things: (1) it provides the basic ingredients from which denotations can be constructed for the terms of a representation language; and (2) it assigns denotations to the descriptive terms of the language. For instance, a model for the language of standard first-order predicate calculus, P L 1 , the mother of all representation languages, has the form M = < D, F > where D is a set of individuals and F is a function assigning to descriptive terms of P L 1 either individuals (in the case of individual constants) or sets of k-tuples of individuals (in the case of k-ary predicate constants).

The aim of the MMSemR Working Group to identify commonalities in different approaches to semantic representation and common representational concepts, disregarding representational formats but with a concern for well-defined concepts, calls for a methodological basis in providing a semantics for abstract representational concepts. This must be more abstract than a standard modeltheoretic semantics in two respects:

1. it is not concerned with a particular representation format, or language, hence not with particular descriptive terms; 2. it is not concerned with a particular domain of individual objects.

Instead, we are concerned with such considerations as that we want to able to represent information about events and about individuals participating in events, i.e., we are concerned with descriptive categories, and descriptive concepts. Providing a semantics for descriptive categories and concepts then comes down to two things:

1. the specification of the semantic categories corresponding to descriptive categories; 2. the specification of the semantic objects corresponding to specific descriptive concepts.

A metamodel is an abstract specification of the kinds of descriptors that are considered, and how they are modeltheoretically supported. In the case of P L 1 , a metamodel should say that the descriptors which are considered are (1) descriptors of individuals (ids), and (2) descriptors of predicates (pds); their semantic support by a model should be such that individual descriptors correspond to individuals, and k-ary predicate descriptors to sets of k-tuples of individuals. This can be formulated mathematically by defining a first-order metamodel as a pair:

(

1) M M (1) = < ind, {(id → ind), (pd → S k [ind])} >
where ind is the type of individuals, and S k [t] is the type of sets of k-tuples of elements of type t (with 0 ≤ k). Characteristic for a first-order model is that it supports only representations in terms of individuals and predicates applied to individuals (first-order predicates, expressing properties of and relations between individuals). In particular, it does not support predicates applied to first-order predicates. A second-order metamodel, supporting also secondorder predicates, has the following structure:

(

2) M M (2) = < ind, {(id → ind), (pd (1) → S k [ind], (pd (2) → S n [S k [ind]])} > for k, n ≥ 1, where S n [S k [D]
] is the set of n-tuples of elements of S k [D], i.e., the set of properties of (and n-ary relations between) properties of (and relations between) individuals. Metamodels can be seen as characterizations of a class of models, and may be useful for indicating the general approach to a certain task involving complex information. As an example, consider the following two alternative views on feature structures in linguistics.

The first is that of feature structure as a graph viewed as a set-theoretical construct. [START_REF] Carpenter | The Logic of Typed Feature Structures[END_REF], for example, defines a typed feature structure as, given a set Feat of features and a set Type of (hierarchically ordered) types, a quadruple

(3) < N, n 0 , θ, F >
where N is a finite set whose elements are called nodes; where n 0 ∈ N , where θ is a total function from N to Type (typing) and where F is a partial function from N × Feat to N (defining arcs, labelled with feature names, that connect the nodes). The node n 0 is the root of the graph; every node in N is required to be reachable from the root node. [START_REF] Pollard | Head-Driven Phrase Structure Grammar[END_REF] use this view when they introduce feature structures as semantic entities in the interpretation of representations of linguistic information. They refer to graphs as "modelling structures", i.e., as structures that play a role in models, and they introduce AVMs as structures in a "description language" that is to be interpreted in terms of feature structures-as-graphs: "Throughout this volume we will describe feature structures using attribute-value (AVM) diagrams". (Pollard & Sag, 1987, 19-20).

This view corresponds to the following metamodel that distinguishes nonterminal and terminal nodes and types:

nonterminal nodes ❄ ❄ (2) (3) (1) (3) ❄ types ✻ terminal nodes
Diagram 1: Metamodel with graphs as model elements Relations of type (1) in this metamodel correspond to features like HEAD-DAUGHTER in HPSG, those of type (2) to atomic-valued features like GENDER, and those of type (3) to the typing function θ.

An alternative view is that of graphs as representations, as a notational alternative to AVMs rather than as the objects interpreting AVMs. For example, Lee (2004) introduces feature structures as ways of capturing information, and mentions graphs as a notation for feature structures. Aware of these alternative possible views, [START_REF] Pollard | Head-Driven Phrase Structure Grammar[END_REF] note that "A common source of confusion is that feature structures themselves can be used as descriptions of other feature structures." One way to avoid confusion is to consider the metamodels corresponding to alternative views.

In the graphs-as-representations view, the graph (4) and the AVM (5) are seen as equivalent representations that can both be interpreted as representing the complex predicate (6). ( 4)

AGR NUM noun ----> agr ----> sing | +-----> fem GENDER (5)     noun AGR NUM sing GENDER fem     (6) λx : noun(x) ∧ num(x) = sing ∧ gender(x) = f em
(simplifying slightly). This interpretation reflects a similar view on information as that of first-order logic, with two kinds of individuals: the kind of things that x stands for (words and phrases) and the kind of atomic attribute values like 'fem' and 'sing'. These values are associated with word-like individuals through two-place predicates that are in fact functions; moreover, types such as 'noun' correspond to unary predicates. This corresponds to the metamodel visualized in Diagram 2.

Metamodels for Semantic Representation

The definition of multimodal meaning mentioned above, in terms of the way in which a communicative action changes the information state of an addressee, has some immediate implications on the basic ingredients that should be available for the description of semantic information. A communicative action is, first of all, an event: something that happens at some point in time (or between two time points). Second, it has at least two participants: the agent who performs the action and the one at whom the action is addressed. Third, these participants have different roles; that of agent and addressee. So we minimally want to distinguish events; entities participating in events; temporal objects for anchoring events; roles relating events to participants, and temporal functions for anchoring events in time. Events are needed not only for describing communicative events, but also for the semantic analysis of NL sentences, where 'roles' correspond to semantic relations. As such events may have other events as 'participants', we have included functional relations between events in the metamodel of Diagram 3; 'participants' in this diagram should then be understood as 'participants other than events'.

The metamodel shown here is evidently very general, and as such would seem to be of little use. Still, it may be interesting to note that a multimodal interactive system, currently under development jointly by research groups at LORIA in Nancy (France) and the university in Saarbruecken (Germany), the MIAMM system, makes use of a metamodel that is only marginally more complex. This metamodel is shown in Figure 1 in the form of a UML diagram. It supports, in addition to the metamodel of Diagram 3, relations like part-whole within participants and within events, and relations between temporal objects (temporal relations). For further discussion see [START_REF] Kumar | A Comprehensive Framework for Multimodal Meaning Representation[END_REF].

Whereas metamodels do indeed seem to be a useful tool in describing semantically well-founded concepts for semantic representation and annotation, just as in ordinary model-theoretic semantics the intended meaning of a concept cannot be captured by indicating formal relations with entities in a metamodel. An much needed additional tool is that of a data category registry, i.e. a software repository documenting common and valuable concepts (Romary, 2004). At LORIA in Nancy preliminary work has been undertaken to set up such a registry, from which Figure 2 shows a simplified example.

Another interesting application of metamodels to the comparative study of meaning representation is that of cha-/Addressee/ Definition: An entity that is an intended recipient of of a communicative event, whose state of information is intended to be influenced by the event. Source: (implicit) an event, whose eventType should be /CommunicativeAct/. Target: a participant (user or system). racterizing structural models of dialogue, like Rhetorical Structure Theory [START_REF] Mann | Rhetorical Structure Theory: Toward a functional theory of text organization[END_REF], versus information-state change approaches, like Dynamic Interpretation Theory [START_REF] Bunt | Dialogue Pragmatics and Context Specification[END_REF]. Unfortunately, limitations of space prevent us from discussing this application in the present paper.

Concluding Remarks

In this paper we have discussed the notion of a metamodel in relation to data models and models in model-theoretic semantics, and outlined its possible use together with a data category registry in the definition of abstract elementary descriptors of semantic information.

  First-order metamodel for feature structures Relations of type (1) in this diagram (1) correspond again to features like HEAD-DAUGHTER; (2) to atomic-valued features like GENDER; (3) to features like SYNSEM, and (4) to features like AGR(EEMENT).

Figure 1 :

 1 Figure 1: The MMIL Metamodel

Figure 2 :

 2 Figure 2: Sample data category registry entry.