Ontology of Enterprise Competencies Mounira Harzallah LINA – University of Nantes Rue christian Pauc, la Chantrerie, 44000 Nantes, France mounira.harzallah@iut-nantes.univ-nantes.fr Abstract. Ontologies constitute a pertinent mean to define and to manage com- petencies and knowledge in companies. The powerful inference mechanisms coming with ontologies allow improving the effectiveness of complex compe- tence and knowledge management processes. This paper represents a short synthesis on ontology definition, building and application. Then, thinking about interest of competence ontology and its building is exposed. 1 Introduction Enterprise competence and knowledge constitutes vast amounts of information re- sources to represent, to store and to process. They are treated to answer to many en- terprise complex needs. For that, it seems necessary to build a formal ontology of enterprise competence and knowledge. This ontology would concern enterprise knowledge, competence and domain. It can be composed of three integrated ontolo- gies: domain ontology, competence ontology and knowledge ontology. Links between them should be defined in order to pass from one to another (Fig. 1). Representation of enterprise domain constitutes a part of enterprise knowledge, but we consider it separately in order to distinguish it of other kinds of knowledge (e.g. knowledge of tasks, knowledge of facts). In te g ra te d O n to lo g y C o m p e te n c e D o m a in K n o w le d g e O n to lo g y O n to lo g y O n to lo g y D1 C1 D2 D3 K1 C2 C3 D4 D5 K2 K3 C4 Fig.1. Competence and Knowledge Integrated Ontology Reasoning on this ontology will concern the verification of the ontology consistence, the semi-automated adding of new competencies, domain aspects or knowledge, the supporting of competency and knowledge management, and so on. In this paper, we only deal with competence ontology. First, a brief synthesis about ontology definition and building is presented. Then, a vision concerning specially competence ontology building and its components is presented. 2 Ontology Definition and Building Many definitions have been proposed for the ontology in computer sciences. Several definition invariant can be find out: - An ontology concerns a domain [1], [2], [3], [4]; - An ontology brings concepts and relationships [1], [2], [3], [4] ; - An ontology should be accepted by a community [4]; - Ontologies describing general concepts (e.g. KR Ontology [1]) can be distin- guished from ontologies describing specific concepts (e.g. UMLS [6]). In spite of these invariant, we can also quote several divergences points: - If an ontology must be formal [3], [7], [8] or not [1]. Three ontology formalizations are approached (Fig. 2): 1) Terms definition. In this case, an ontology corresponds to a taxonomy (e.g. a dictionary), 2) Definition of concepts and their relationships. 3) Definition of axioms concerning concepts and their relationships [9]. - If an ontology is a conceptualization or a specification of a conceptualization [4]. - If instances of concepts belonging to an ontology are a part of the ontology itself or not [8]. C1, C2, C3, C4 – Concepts Ontology 1 Dictionary C1 Definition Vocabularies Domain C2 Definition C2 C3 Definition C4 Definition C3 C4 Entities Objects C1 Relations Ontology 2 C1 Axioms Is-a Predicates Ontology 3 C1 et C2 =>C3 C2 C3 => non C4 Part-of Part-of C1 => C4 etc. C3 C4 Fig. 2. Ontology Formalism Kinds Three kinds of building methods concerning ontologies can be distinguished: 1) Man- ual methods where experts of a specific domain built a new ontology or extend an existent ontology (for instance, the high level of Cyc [10], Wordnet [5]). 2) Auto- mated methods where an ontology is built by using techniques of text mining: con- cepts and their relationship are extracts, then verified by inference mechanisms to define a consistent ontology. 3) Mixed methods – an ontology is built by automated techniques, but it can be manually extended. Ontologies allow mainly to develop applications for extracting knowledge, for carry- ing out intelligent search in the web, for translating documents; for sharing the com- prehension of information between application users and developers; for understand- ing and re-using the knowledge of a specific domain, and so on. 3 Competence Ontology Building A competence ontology supports both the competency intra-operability and inter- operability over applications and users. Concerning competence intra-operability, it allows: 1) The shared comprehension of competencies and their using. 2) The unifica- tion of competence identification and evaluation. So, the decentralization of these processes is possible, once the competence semantic is ensured by the competence ontology. 3) The simplification of processing of curriculum vitae by expliciting it in the enterprise competence ontology. 4) The integration of competence reference grids of different workshops or departments. This is important when the enterprise reor- ganizes its structure and defines new workstations, and so on. Concerning competency interoperability, competence ontology allows sharing and exchanging competencies of an enterprise network (including supplier, subcontractor, and partner) by integrating their competence reference grids. Indeed, competence ontology allows translating the competence reference grid of each enterprise on a unified ontology, so unified seman- tic is used on enterprise network competence management. It is clear that competence ontology concerns the competencies related to a specific domain. This ontology is composed of competencies related between them. But, two points, at least, remain to be clarified: - The kind of relationships between competencies. Relationships - as Is-a or Part-of explaining aggregation of competencies, or the relationship explaining that an indi- vidual should have a given competency to acquire another one – can be used. Other relationship kinds are not evident to use! - What concepts would be on a competence ontology? Should a competence ontol- ogy includes only competencies or should it include another’s concepts concerning, for example the studied domain, its knowledge? We are interested to tow methods for competence ontology building: domain based method and competence similarity based method. Both are based on the model CRAI (Competency Resource Aspect individual) [11], [12]. These CRAI relationships are used: 1) a competence concerns one or more aspects of the specific domain under analysis, 2) a competence is a set of C-resources (knowledge, know-how and behav- ior), 3) a C-resource is related to at most one aspect, and 4) an individual has one or more C-resources (Fig.3.). The first method consists to define a competence ontology by building first an ontol- ogy of the domain (mainly by specialization of Aspect and further instantiation). Then, the relationship To-Concern (Cf. Fig. 3) is defined between competencies and domain aspects instances. The obtained result is it a competency ontology? We are beginning the competency ontology building of the computer domain of the company Cap Gemini, Nantes - France, using this method (Fig 4). To-Know-how 0, 1 0, n Dm 0,n 0,n 0,n 0,n 1,n XT Be- Individual Acquired C-Resource To-Know - Aspect Decomposed-In 0,1 0,n 0,n 1,n 0,n To-Concern Be-Associated 0,1 0,n To-Behave 1,n Competency 0,n Fig. 3. The EER schema representing the CRAI model The second method (competence similarity based) consists to build a competency ontology by extracting competency similarity rules, according to their likelihood. A similarity rule is as follow: c1, c2, ..., ck Þ cn where ci is any competency. The under- ling meaning of this rule is that if the competencies c1, c2, ..., ck are acquired by any individual then cn is acquired by the same individual. The likelihood of a similarity rule is calculated with an index, based on the nature of competencies (their C- Resources and Aspects concerned by them). In the sense, that the definition of simi- larity link between tow competencies c1 and c2, for example, that concern respectively {a1, a3} and {a2, a3} are based, on one hand, on the similarity of {a1, a3} and {a2, a3} and, on the other hand, on their common resources {rt1, r31, r32}. c1 and c2 have respectively {r11, r12, r13, rt1, r31, r32} and {r21, rt1, rt2, r31, r32}, rti is a transver- sal C-resource associated to one or more competencies. Complex Systems C1: To be competent on ES C2: To be competent on BDMS Program Systems C3: To be competent on Exploitation ES DBMS C4: To be competent on SQL Net Exploitation SQL Net Oracle Is-a C5: To be competent on PL/SQL Part-Of Uses UNIX PL/SQL Documentation Concerns Fig. 4. Computer and Competence Ontology This approach defines direct links (of similarity kind) between competencies. How- ever, do these competence links constitute a competence ontology? In the both cases, obtained results concern a domain. In the first case, relationships between domain concepts are defined, then relationships between competencies and domain concepts are defined and by deduction competencies relationships can be defined. In the second case, direct relationships between competencies are defined. To integrate a new competence (or a competence set) in the obtained result, in the first case, it is clear that its concerned aspect should be positioned in the domain ontology. In the second case, it should define its resources and concerned aspects, compared to existing resources and aspects. In other word, data about it should be positioned in the domain ontology. In conclusion, it seems that the tow methods can be integrated to give more semantic to competence relationships. 4 Conclusion In this paper, we have discussed some ways to build competence ontology. Two com- petence “pseudo-ontologies” based on domain and competence similarity definition have been presented. However, components and relationships that should constitute a competence ontology remain not clear. In other words, when can and can’t a compe- tency schema be considered as a competence ontology? More generally, when have and haven’t we dealt with ontology? References 1. J.F. Sowa, J.F.: KR Ontology. http://www.jfsowa.com/ontology/ (2001). 2. Smith, M.K., Welty, C., McGuinness, D.L.: OWL Web Ontology Language Guide. Intro- duction. www.w3.org/TR/2004/REC-owl-guide-20040210 (2004). 3. Noy, N.L., McGuinness, D.L.: Ontology Development. http://protege.stanford.edu/publications/ontology_development/ontology101-noy- mcguinness.html (2004). 4. Gruber, T.: A translation approach to portable ontologies. Knowledge Acquisition, 5(2), (1993) 199-220. 5. Climent, S.: Individuación e información Parte-Todo. Representación para el procesamiento computacional del lenguaje. Estudios de Lingüística Española (ELiEs), (1999). 6. Medicine National library http://www.nlm.nih.gov/research/umls/META2.HTML (2001). 7. Dogac, A., Laleci, G., Kabak, Y.: Exploiting Web Service Semantics: Taxonomies vs. Ontologies. http://research.microsoft.com/research/db/debull/A02dec/dogac1.ps (2002). 8. Noy, N., McGuinness, D.: Ontology Development 101: A Guide to Creating Your First Ontology. http://protege.stanford.edu/publications/ontology development/ontology101- noy-mcguinness.html (2001).. 9. Pidcock, W.: What are the differences between a vocabulary, a taxonomy, a thesaurus, an ontology, and a meta-model? http://www.metamodel.com/article.php?story=20030115211223271 (2001) 10. Documentation CycL http://www.cyc.com/doc/handbook/oe/06-el-hl-and-the- canonicalizer.html, (2002). 11. Harzallah, M., Berio, G.: Competency Modeling and management: A case study, ICEIS’04, Porto, 13-16 avril (2004). 12. Harzallah, M., Vernadat, F.: IT-Based competency modeling and management: from theory to practice in enterprise engineering and operations, Computers in Industry, 48 (2): (2002) 157-179.