Introduction
As numerous domains, creativity is subject to digitalization. Several reviews have highlighted the existence of an important number of digital systems dedicated to creativity (Gabriel et al., Reference Gabriel, Monticolo, Camargo and Bourgault2016; Wang and Nickerson, Reference Wang and Nickerson2017). Although research on digital support dedicated to creativity is not recent – researches were done on e-brainstorming several decades ago as those from Aiken et al. (Reference Aiken, Krosp, Shirani and Martin1994). The era of knowledge (Powell and Snellman, Reference Powell and Snellman2004) urges companies to adopt systems that would valorize their intellectual capital. Wealth is in human imagination and creativity (Rifkin, Reference Rifkin2000). Intellectual capital is the driving force of this new era (Rifkin, Reference Rifkin2000). The manner companies can valorize this capital is by implementing knowledge management approach. Despite the difficulties to scale up the knowledge-based system several decades ago (Russell et al., Reference Russell, Norvig and Davis2010), the change of companies' culture is operating based on advanced technological infrastructure and concepts as enterprise 3.0 (Carbone et al., Reference Carbone, Contreras, Hernandez and Gomez-Perez2012) or industry 4.0. Although industry 4.0 is machine-oriented, as it connects them thanks to the Internet of Things and collecting massive amount of data, enterprise 3.0 and industry 4.0 also concern the early stage of innovation (Carbone et al., Reference Carbone, Contreras, Hernandez and Gomez-Perez2012). However, to better fit into the era of knowledge and the industry 4.0, the innovation paradigm should be tweaked. “In the past, innovation was defined largely by creativity and the development of new ideas. Today the term encompasses coordinated projects directed toward honing these ideas and converting them into developments that boost the bottom line.”. An indicator of this evolution of perspective concerning innovation is the emergence of support systems dedicated (Correa and Danilevicz, Reference Correa and Danilevicz2015). It remains innovation is not creativity, if generating ideas is not sufficient to innovate; it is a requirement that should be integrated into a larger process. Making the creative process explicit and deliberate is the foundations of the creative problem-solving (CPS) approach (Isaksen and Treffinger, Reference Isaksen and Treffinger2004). It aims to reach a balance between creative and critical thinking thanks to various tools (that will be mentioned as creative techniques in this article) to produce ideas of solutions (Isaksen and Treffinger, Reference Isaksen and Treffinger2004). The range of techniques and methodologies to drive the production of ideas has been largely expanded (Michalko, Reference Michalko2006; VanGundy, Reference VanGundy2008; Martin et al., Reference Martin, Hanington and Hanington2012) since the beginning of the CPS with the brainstorming (Osborn, Reference Osborn1963). Each technique has his purposes and should be applied accordingly (Isaksen and Treffinger, Reference Isaksen and Treffinger2004). A review of creative support systems (Gabriel et al., Reference Gabriel, Monticolo, Camargo and Bourgault2016) shows that the aspects of processes and variety of creative techniques are sparsely explored.
To address limits observed in the creative support system, the present research aimed to design a creative support system based on the organizational modeling of creativity workshops to manage knowledge during the creative process. As it is ambitious to respond to every situation, the application case is the application of a CPS approach (Isaksen and Treffinger, Reference Isaksen and Treffinger2004). The approach gathers people to solve a problem by applying various techniques (Isaksen and Treffinger, Reference Isaksen and Treffinger2004). In this approach, people can have different roles among three mains that are as follows (Isaksen and Treffinger, Reference Isaksen and Treffinger2004):
– The “client” is the decision-making authority or ownership over a particular situation or challenge. Its role is to supply “content-related expertise and provide convergence”.
– The “facilitator” structures and prepares the environment, acts as a catalyst for releasing and focusing the efforts of group members, uses appropriate methods and techniques, and is sensitive to the variety of group dynamics.
– The “participants” suggest options and provide a wide range of alternatives during the session. They work on the client's problem and generate ideas to solve it. For these reasons, this paper will refer to them as ideators.
These roles have been completed with three other roles based on decades of experiment of the authors in facilitating and organizing creative workshops in new product development process of companies:
– The “organizer” who pays attention to the availability of the involved people and resources.
– The “evaluator” is a person that contributes to the decision-making but is not part of the decision-making authority.
– The “expert” contributes to the critical thinking of the ideators as external of the workgroup.
These six roles work together to succeed the creativity workshop by creating a maximum of ideas, by comparing these ideas and evaluate them. In order to reach this objective, they share information and knowledge such as the description of the problem to solve, the details of creativity techniques that they can apply, their experiences, their know-how, etc. In order to assist the participants of the creativity workshops, we have to propose a knowledge management approach. Research about knowledge management proposes to use agent-based approaches to manage knowledge as the Multi-Agent Information System (Gandon, Reference Gandon2002a) or Agent Mediated Knowledge Management (Van Elst et al., Reference Van Elst, Dignum and Abecker2004). By analogy with these works, the complexity of the creativity workshops could be addressed by a multi-agent system designed with an organization-based approach. A multi-agent system dedicated to support creativity has been proposed (Gabriel et al., Reference Gabriel, Monticolo, Camargo and Bourgault2015) based on a design methodology dedicated to knowledge management that emphasizes organization, competences, and knowledge (Girodon et al., Reference Girodon, Monticolo, Bonjour and Perrier2015). However, it remains the approach does not detail the design of shared representation of knowledge between agents. The common way to define the concepts which are used for organizing and structuring the knowledge of organizations are ontologies (Studer et al., Reference Studer, Benjamins and Fensel1998). The ontologies provide consistent and reliable means to represent and aggregate knowledge from different sources (Hernández-González et al., Reference Hernández-González, García-Moreno, Rodríguez-García, Valencia-García and García-Sánchez2014). Several ontologies are proposed by the literature to describe accordingly innovation, creativity, brainstorming, or ideas. Practically, ontology engineering should reuse concepts from other ontologies (Noy and McGuinness, Reference Noy and McGuinness2001), but, in order to determine the relevant concept to reuse, it is necessary to implement an ontology engineering methodology (Suárez-Figueroa et al., Reference Suárez-Figueroa, Gómez-Pérez, Fernández-López, Suárez-Figueroa, Gómez-Pérez, Motta and Gangemi2012). A review highlighted the fact that various methodologies exist without being convincing about their reproducibility (Iqbal et al., Reference Iqbal, Murad, Mustapha and Sharef2013a). Moreover, as ontology engineering depends on the domain, the objective, and the engineering point of view, it was assumed it also depends on the design paradigm. As the creative support system is designed with an organizational perspective based on the modeling of the agent's interaction, this paper attempts to respond to this question:
How to design ontology that responds to the requirement of managing knowledge based on organizational modeling of the agents that will exploit this knowledge?
To respond to this issue, this article will first introduce the notion of ontology for representing knowledge and a review of the methodologies used in the ontology engineering domain. Based on the previous methodologies, this article will present an ontology engineering approach that adopts an organizational perspective. The ontology engineering approach is named O-DOCK for Ontology Design based on Organization, Competence, and Knowledge. Then, the results of the methodology applied to the case of the creative support system will be presented.
Representing the knowledge domain
Knowledge representation is a multidisciplinary subject implying from logic ontology and computation (Sowa, Reference Sowa1999). It takes his sources in Aristotle's philosophy. He made a systematic study of logic and introduced basement for reasoning (Russell et al., Reference Russell, Norvig and Davis2010). He presented the fundamental laws governing the rational part of the mind resulting in proper reasoning (Russell et al., Reference Russell, Norvig and Davis2010). It gave the basis for modern ontologies that are presented in the following subsection.
Concept of ontology
Ontology is the study of the categories of things that exist or may exist in some domain (Sowa, Reference Sowa1999). Ontology is “an explicit specification of a conceptualization” which is an abstract, simplified view of the world that is represented for some purpose (Gruber, Reference Gruber1993). A “conceptualization” refers to an abstract model of some phenomenon in the world by having identified the relevant concepts of that phenomenon (Studer et al., Reference Studer, Benjamins and Fensel1998). By definition, conceptualization is a partial representation of the perceived reality (Gandon, Reference Gandon2002b). Artificial Intelligence researchers quickly gave up capturing universally valid knowledge, because it turned out that specific use of knowledge influenced its modeling and representation (Studer et al., Reference Studer, Benjamins and Fensel1998). The domain of this conceptualization depends on the purpose of the ontology defined during its design. “Ontologies disambiguate and provide a consensual conceptual vocabulary” (Bullinger, Reference Bullinger2009). The notion of consensus comes from the philosophical origin of the notion of ontology. “Every ontology is a treaty – a social agreement – among people with some common motive in sharing.” (Russell et al., Reference Russell, Norvig and Davis2010). This knowledge representation through ontologies should be differed from taxonomies in two respects: they have richer internal structure and reflect some consensus (Studer et al., Reference Studer, Benjamins and Fensel1998). To deal with the richness of a domain, several abstraction levels should be distinguished in ontologies (Russell et al., Reference Russell, Norvig and Davis2010):
– Domain ontologies capture the knowledge valid for a particular domain.
– Generic ontologies are valid across several domains.
– Application ontologies contain all the necessary knowledge for modeling a particular domain.
○ Task ontologies provide terms specifically for particular tasks.
○ Method ontologies provide terms specific to particular problem-solving method.
– Representational ontologies do not commit to any particular domain.
From a technological perspective, ontology is a computational object encoding knowledge about a specific domain in machine-processable from making it available to information systems (Slimani, Reference Slimani2015). In short, ontology expresses meaning in a form that is logically precise, humanly readable, and computationally tractable (Sowa, Reference Sowa1999). These three aspects are gathered by current technologies as RDF (RDF Working Group, 2014) and even more with OWL (W3C OWL Working Group, 2012) that include description logic making easier description of definitions and properties of concepts. These technologies have emerged from the semantic Web field that aims to change the text-based Web to machine intelligible Web (Berners-Lee et al., Reference Berners-Lee, Hendler and Lassila2001). These languages eclipsed previous languages as KL-ONE (Brachman and Schmolze, Reference Brachman and Schmolze1985), LOOM (MacGregor, Reference MacGregor1991), KRYPTON (Brachman et al., Reference Brachman, Gilbert and Levesque1985), CYCL (Lenat and Guha, Reference Lenat and Guha1989), or Ontolingua (Gruber, Reference Gruber1993).
From an application perspective, ontologies permit interoperability between humans, between humans and machines, or even between machines (Sorli and Stokic, Reference Sorli and Stokic2009). The benefits of ontologies are multiple: definition of an explicit information model facilitating communication (Hernández-González et al., Reference Hernández-González, García-Moreno, Rodríguez-García, Valencia-García and García-Sánchez2014), improving search capabilities (Hernández-González et al., Reference Hernández-González, García-Moreno, Rodríguez-García, Valencia-García and García-Sánchez2014), improving management of information (Hernández-González et al., Reference Hernández-González, García-Moreno, Rodríguez-García, Valencia-García and García-Sánchez2014), achieving a more precise and efficient information retrieval (Afacan and Demirkan, Reference Afacan and Demirkan2011; Hernández-González et al., Reference Hernández-González, García-Moreno, Rodríguez-García, Valencia-García and García-Sánchez2014), and reducing the time required for accessing knowledge (Afacan and Demirkan, Reference Afacan and Demirkan2011). In addition to being machine readable and thus permitting computers to interpret and reason with the information in the ontology, it also provides flexibility in the information structure, enabling modifications and extensions even after the implementation of the ontology (Brandt et al., Reference Brandt, Morbach, Miatidis, Theißen, Jarke and Marquardt2008).
The ontologies have already been applied in various domains, such as chemicals (Brandt et al., Reference Brandt, Morbach, Miatidis, Theißen, Jarke and Marquardt2008), robotics (Vidoni et al., Reference Vidoni, García-Sánchez, Gasparetto and Martínez-Béjar2011), and medicine (Bertaud-Gounot et al., Reference Bertaud-Gounot, Duvauferrier and Burgun2012; Harispe et al., Reference Harispe, Sánchez, Ranwez, Janaqi and Montmain2014), as well as innovation and creativity. It has been implemented in the design field (Brandt et al., Reference Brandt, Morbach, Miatidis, Theißen, Jarke and Marquardt2008; Lee et al., Reference Lee, Chae, Kim and Kim2009; Afacan and Demirkan, Reference Afacan and Demirkan2011) or R&D management (Hernández-González et al., Reference Hernández-González, García-Moreno, Rodríguez-García, Valencia-García and García-Sánchez2014). Ontology is also a promising technology for Creative Support System that aims to provide decision support and knowledge management in creative contexts like creative workshops. Several ontologies could be quoted and reused, but according to ontology engineering methodologies, it requires some adaptation as the context and the problem to solve the influence the way knowledge will be represented (Suárez-Figueroa et al., Reference Suárez-Figueroa, Gómez-Pérez, Fernández-López, Suárez-Figueroa, Gómez-Pérez, Motta and Gangemi2012). Before deepening the ontology engineering methodology dedicated to creative workshops, the next subsection will review on the ontology engineering methodology.
Literature review of ontology engineering methodologies
Since the emergence of the concept of ontology in computer science, various methodologies for designing and implementing ontologies have been suggested. The main steps of the first methodologies to design ontology can be described as follows (Gruber, Reference Gruber1993; Gruninger and Fox, Reference Gruninger and Fox1995; Uschold and Gruninger, Reference Uschold and Gruninger1996): the definition of a scope of knowledge, the identification of concepts of the knowledge domain, the creation of semi-formal representation of concepts and their relations, the creation of the formal (computable) representation of the knowledge domain, and finally the implementation of the ontology in the system that would exploit the knowledge. The notion of motivation scenario has been introduced in the TOVE methodology that aimed to create a common-sense enterprise model (Gruninger and Fox, Reference Gruninger and Fox1995). The motivating scenario arises from the application, it describes the problem to solve, a potential solution, and a set of informal intended semantics for the objects and the relation of the ontology (Gruninger and Fox, Reference Gruninger and Fox1995). Then, the second important notion introduced in these methodologies is the use of competency questions that arise from the motivating scenario. It is a requirement under the form of questions that an ontology must be able to answer (Gruninger and Fox, Reference Gruninger and Fox1995; Uschold and Gruninger, Reference Uschold and Gruninger1996). From these foundations, various methodologies emerged with various perspectives. CommonKADS methodology (Schreiber, Reference Schreiber2000) was a widely used methodology for developing knowledge-based systems. The methodology considers the entire project of creating an ontology that would be integrated in knowledge systems from planning the project to the creation of the system. On-To-Knowledge (Sure et al., Reference Sure, Staab, Studer, Staab and Studer2004) methodology focuses on knowledge meta-process and knowledge process. UPON methodology derived from the Unified Software Development process and exploit the UML for developing ontologies (De Nicola et al., Reference De Nicola, Missikoff and Navigli2005). It aims to produce ontology with the purpose of serving its users. Due to the increasing number of ontology available online, NeOn methodology adopted a reuse-centric approach to construct network of ontologies (Suárez-Figueroa et al., Reference Suárez-Figueroa, Gómez-Pérez, Fernández-López, Suárez-Figueroa, Gómez-Pérez, Motta and Gangemi2012). Particularity of this methodology is that it supports nine flexible scenarios for collaboratively building ontologies and ontology networks (Suárez-Figueroa et al., Reference Suárez-Figueroa, Gómez-Pérez, Fernández-López, Suárez-Figueroa, Gómez-Pérez, Motta and Gangemi2012). An approach based on life cycle was proposed by Fujimoto and Aoyama (Reference Fujimoto and Aoyama2014). It reviews the life cycle of a main concept of knowledge domain and then deepen different phases of the life cycle to extend the domain (Fujimoto and Aoyama, Reference Fujimoto and Aoyama2014). Another methodology suggested identifying the competency questions from case-based reasoning approach (El-Sappagh et al., Reference El-Sappagh, El-Masri, Elmogy, Riad and Saddik2014).
The ambition of this article is to present a review of the methodologies of ontology engineering with an organizational perspective in order to design knowledge management systems. The specificity of the present context is that the knowledge system will support creative workshops that involve persons with various roles. In this context, the closest approach is CommonKADS methodology (Schreiber, Reference Schreiber2000). It models the business process, then models tasks, and finally models agents. The approach is clearly like the “Design based on Organization, Competences and Knowledge” used to develop the creative support system. The fact that both share similar approach and above all, they share a common vocabulary is coherent as both deal with knowledge management. Despite the common vocabulary and semantic, they differ concerning the representation of the information. To have a better idea of the O-DOCK approach, there are three steps (Fig. 1): modeling the human organization (what happens in the organizations), modeling the agents (what information and how the system should process it), and modeling the interactions between agents and members of the organization. The first two steps use the four same worksheets to model both humans and agents' organization. These worksheets are the organizational structure model, the process model, the activity model, and the role model. Applied to the human organization, organizational structure worksheet permits to explicit the objectives, the missions, and the process of the organization. For each process, the process worksheet represents the activities with their supports, resources, knowledge inputs, and outputs. For each activity, the collaboration of actors is elicited by the activity worksheet that details competences, knowledge, actions, responsibilities, production, and nature of the collaboration (Girodon et al., Reference Girodon, Monticolo, Bonjour and Perrier2015). Then, the role worksheet summarizes missions, competences, knowledge, and responsibilities for each role. The second step applies the same four worksheets in order to model the organization of digital agents that will contribute to satisfying missions of the “human” organization. The third and final step is representing the interaction between “human” and digital agents. In opposite, CommKADS provides six models: organizational models, task models, agent models, knowledge models, communication models, and design models. Each of these models is based on worksheets to ease their achievement. It results in specification of the digital system with the specification of the ontology, whereas the DOCK does not formalize yet the ontology. However, the various models produced thanks to DOCK set up an implicit semantic that represents the common knowledge domain of the members of the organization and the agents. This common knowledge can be extracted from the organizational modeling and formalized into ontology. As DOCK aims to simplify and make the process more schematic and straightforward, the UPON methodology (De Nicola et al., Reference De Nicola, Missikoff and Navigli2005) and the Human Centered Design Methodology (Iqbal et al., Reference Iqbal, Murad, Mustapha and Sharef2013b) have been considered for their graphical representation. UPON is interesting for the use of well-known Unified Modeling Language that provides a formal graphical representation. The use of UML is also the limits of UPON as the learning curve of UML is important. It is easy to use and almost to understand for non-computer science people. In opposite, the human-centered design methodology suggests using concept-mapping technique to represent and construct the knowledge domain with experts.
Cycles of the O-DOCK approach.
Although there is an existence of several ontology engineering methodologies, few of them provide enough quantity and clarity in their instructions to permit the application of them. This conclusion is shared with several literature reviews about ontology engineering methodologies (Corcho et al., Reference Corcho, Fernández-López and Gómez-Pérez2003; Iqbal et al., Reference Iqbal, Murad, Mustapha and Sharef2013a; Slimani, Reference Slimani2015). They also highlight limits about the lack of collaboration in the ontology engineering methodology. Moreover, according to Iqbal et al. (Reference Iqbal, Murad, Mustapha and Sharef2013a), very few of them cover the phases of reusing and redesigning the ontology, and few of them also have a relevant and efficient strategy for identifying the concepts.
Methodologies do no't only differ in terms of approach; they also present different process. Some examples of process notably from the above-mentioned references are listed in Appendix 1. According to this quick review of processes and conclusion of previous reviews (Corcho et al., Reference Corcho, Fernández-López and Gómez-Pérez2003; Iqbal et al., Reference Iqbal, Murad, Mustapha and Sharef2013a; Slimani, Reference Slimani2015), ontology engineering process has four main iterative stages: definition of the scope and finality, conceptualization of the vocabulary, development, and evaluation. However, what matters is not the main phases but the activities they imply. A part of the literature does not focus on steps but on guidelines and recommendations as ontology 101 (Noy and McGuinness, Reference Noy and McGuinness2001), Mikrokosmos (Mahesh et al., Reference Mahesh, Helmreich and Wilson1996), Menelas (Bouaud et al., Reference Bouaud, Bachimont, Charlet and Zweigenbaum1994). The activities are respectively:
– Defining the domain, the scope, the purpose of the ontologies,
– Explicit the competencies questions,
– Capture the concept of the domain that would be part of the ontology,
– Create a semi-formal representation of the domain,
– Identify related ontologies and concepts that can be integrated,
– Produce a formal version of the ontology,
– Validate if it responds to the initial requirements,
– Implement ontology.
To conclude this section, some ontology engineering methodologies are insightful in the present context of creating ontology from organizational modeling but do not provide enough instructions and details to reproduce it. However, this review identifies the activities that an ontology engineering methodology should integrate. The next section will detail the proposed methodology.
Organization-oriented ontology engineering methodology
To shorten and simplify the explanation of the methodology, the most coherent activities mentioned previously have been gathered. Four phases have been established from the activities: definition of the scope and finality (including domain, scope, purpose, and competencies), conceptualization of the vocabulary (including acquisition and reuse of concepts, and semi-formal representation), development (including formalization/programming and instantiation of concepts), and evaluation. Figure 2 represents these four phases and the iteration loops. Each of the phases will be detailed in the subsection with an example from the ontology applied to creative workshops. These phases and activities constitute the development stage of the ontology life cycle. Once designed, the ontologies can be integrated to the system that will exploit it and modify it. In the present case of ontology for creativity process, various data will be saved as instances and relations between instances to reach the expected functionalities in use. As the pillar of the ontology engineering methodology is a multi-agent system engineering methodology, the system development and integration is theoretically eased. O-DOCK covers the ontology life cycle, which includes ontology and system development, integration, deployment, and operation/maintenance (Neuhaus et al., Reference Neuhaus, Ray and Sriram2014), if it is considered with O-DOCK.
Ontology engineering activities split into phases.
Step 1: scope, goals, and competencies definition
As most methodologies, the first step is the preparation of the ontologies, which means the definition of the domain, the scope, and the purpose of the ontology. The domain of the ontology corresponds to the knowledge domain that the ontology represents. This domain implies the restriction of the scope to avoid the definition of unnecessary concepts. The scope implies the definition of a depth of details that the ontology should describe. The scope depends on the purpose of the ontology that refers to its objectives responding to questions as: Why is it created? What it is useful for? What should it do? The purpose can be associated with that of competency-questions (Uschold and Gruninger, Reference Uschold and Gruninger1996). The purpose is the overall objective, whereas the competency questions correspond to needs in terms of knowledge (Gruninger and Fox, Reference Gruninger and Fox1995). These competency questions are questions or claims that the ontology should be able to answer or achieve, so it can be perceived as functionalities of the ontology. The term competency will be preferred to the term competency questions, as it can also be a claim. The competencies are notably useful for verifying if the ontology correctly represents the knowledge domain and permits the expected assumptions. This verification is done during the validation/evaluation step.
In the case of the ontology for the creative support system, the goal of this system is to assist the different people involved in creative workshops to realize their tasks. The scope of the present ontology is to describe, specify, and represent all the concepts related to the organization and implementation of a creative workshop. For this reason, the ontology was named “Creative Workshop Management Ontology (CWMO).” To further detail the purpose and determine the competencies of the ontology, the organizational structure model of the O-DOCK methodology is used. In the present case, the objective of the organization can be broken down into missions and then into processes (Fig. 3). These processes can be described as follows:
• During the formalization of the problem, the problem to be solved creatively is formalized based on the “client”/project owner request. Besides the request to organize a creative workshop, the information about the problem, its context, the topic, and the subject are collected.
• The organization of the workshop consists of analyzing the information by the organizer to orient the workshop, redefine some information, and manage logistical aspects related to the workshop.
• The generation of ideas is accomplished by a set of “ideators” that apply creative techniques with the help of the facilitator in order to solve the problem. The orientation of the creative techniques should be adapted to the problem based on the information collected, the ideators involved, and the context.
• The evaluation of ideas compares the ideas generated with the specification of the problem, the context, and the expectations of the client. As for the evaluation, there are different techniques to evaluate the aspects of ideas according to the problem, the evaluator, and the context.
• Finally, communication/implementation of the ideas formalizes the ideas through different types of artifacts to complete, communicate, or test out the ideas.
Organizational structure of the human organization involved in a creative workshop.
All these processes can be described in a process model inspired by IDEF-0 (Cheng-Leong et al., Reference Cheng-Leong, Li Pheng and Keng Leng1999). It elicits the activities, the information/knowledge needed and produced by the activities, the information/knowledge that acts as a control, and the roles that support the activities. For instance, process 3 – Generation of the ideas – is detailed through a process model (Fig. 4). It shows the implication of the different roles on the activities and the knowledge required and produced.
Process model of the generation of ideas.
As the goal is to design a digital system that supports human tasks, the models highlight the activities done by humans according to their role and the information/knowledge produced or processes. The explicit knowledge of each activity eases the elicitation of competencies of the ontologies. Competencies can be determined for each process based on the knowledge required and produced by the activities. Table 1 provides some examples of competencies of the ontology. These competencies imply knowledge instantiated at different moments of the ontology life cycle. Some instances of concepts will be defined during the development as, for instance, the creative techniques and their properties. In opposite, some instances will be defined during a workshop as, for example, subject or ideas.
Example of ontology's competencies according to the process
Step 2: conceptualization
The second phase consists of determining the concepts and relations that will constitute the ontology. A way to get this vocabulary is to compile textual descriptions of the domain of “subject-verb-complement” sentences, then annotate the subject and object to identify the concepts and the predicate for their relations (Bachimont, Reference Bachimont2000). For example, the facilitator (subject) chooses (predicate) the creative technique (object). However, organizational modeling already formalizes knowledge in a schematic way. The process model permits identifying the knowledge and artifacts used and produced by the actors involved in activities. It enables the determination of the concepts of the knowledge domain. These concepts are indexed into the table with the name and definition. According to the completeness of the model, the concepts indexed are not sufficient and have to be extended. To do so, each indexed concept is reviewed to determine its relations and the concepts related. Each concept was reviewed by asking these questions: What characterizes an instance of this concept? To which other instances is it related and what is the relation? It enables identification of concepts that have been missed and that is important to represent the domain. The interest of these two questions is also to identify the relations between the concepts that can be systematically deduced from the organizational modeling. The relations indexed are differentiated into two types: concept relation that links two or more concepts and data relation that links a concept to a value as an integer, literal, or strings. At the end, there are three tables: concepts table (Table 2), concept relations table (Table 3), data relations table (Table 4). Concepts table only describes the concept name, the description, whereas relations table defines the name of the relation, its domain and its range, the definition and the name space. The interest of specifying the name space is to specify where the concept comes from, so it permits respecting the recommendation in terms of reuse of existing ontology (Noy and McGuinness, Reference Noy and McGuinness2001). At first, all the concepts and relations are original but once the entire knowledge domain is described with concepts and relations, they can be replaced by those already defined in other ontologies. In order to find similar concepts or relations, dedicated search engines can be used as Linked Open VocabularyFootnote 1 (LOV), SwoogleFootnote 2, WatsonFootnote 3. To search in these systems, special attention should be paid to the definition of the found concept. It should be the same as the starting concept. Concepts or relations can have the same name but being used in another context so possessing different definitions. In opposite, some concepts or relations can have close or similar definition but different names, which makes difficult to identify them.
Extract of the table of the concepts of CWMO
Extract of the table of concept relation
Extract of the table of data relation
Simultaneously, concepts and their relations can be graphically represented. It permits having an overall representation of the area of knowledge. It can be represented according to several formalism, such as UML class (Westerski, Reference Westerski2013), AML ontology diagram (Cervenka and Trencansky, Reference Cervenka and Trencansky2007), G-OWL (Héon et al., Reference Héon, Nkambou and Langheit2016), or simply with circles and edges. Figure 5 is an example of UML representation of CWMO.
Extract of the schematic semi-formal representation of the Creative Workshop Management Ontology.
Step 3: development
This phase consists of translating the concepts and the relations indexed into a computer-readable language. There are different specifications to make knowledge computer readable, notably the eXtensible Markup Language (XML), the Resource Description Framework (RDF), and the Web Ontology Language (OWL). OWLFootnote 4 extends RDFFootnote 5, which itself extends XML. They possess different degrees of expressivity. OWL 2 is those with the highest degree of expressivity that handle description logic, but it also possesses different profiles that limit this expressivity according to the application scenario. These specifications have various formalisms to implement them such as N3Footnote 6, TurtleFootnote 7, RDF/XML, OWL/XML, functional syntax, or Manchester syntax. The language used has significance for being operable with editing tools, API for manipulating the ontology in the application, or the inference engine. However, ontology editor as Protégé (Musen, Reference Musen2015) eases the creation of a formal ontology and compiles it in various languages. Moreover, there are some Web applications that enable translation from one syntax to another, such as the RDF translatorFootnote 8 for instance.
With the ontology editor Protégé and the description of the knowledge domain based on the table, the development of the ontology is quite simple as it specifies the name, the description, the domain, and the range of concepts and relations. For CWMO, an OWL file was generated with 39 concepts, the 79 concept relations, and the 32 data relations. Global representation of the ontology is given in Figure 6. Due to the important number of relations, they are only represented by colored arrows in the figure, labels are not shown to keep it readable.
Global representation of the ontology generated with Protégé.
Step 4: validation and evaluation of the ontology
The last phase concerns the validation and the evaluation of the ontology. This phase concerns three aspects: the syntax error according to the standard used, the consistency of the ontology according to the area of knowledge represented, and the satisfaction of the competencies. There are several tools available online to facilitate the conformation to the W3C recommendation and their validation, such as OntOlogy Pitfalls ScannerFootnote 9, OWL validatorFootnote 10, or RDF validatorFootnote 11. Once syntax and good practices are respected, the consistency of the ontology can be checked. It consists of verifying whether a reasoner can infer knowledge. This verification is only possible if the classes of the ontology are instantiated. If the reasoner generates a logical error, it should be fixed by modifying concepts, relations, or instances. Once it is possible to infer knowledge from the ontology, it does not mean the ontology correctly represents the knowledge domain. The only way to verify the representativeness of the ontology is to compare it with the competencies that it should theoretically have. The competencies are translated into requests (presently in SPARQL), submitted thanks to the Protégé ontology editor, and then compared the generated results to the expected results. If it is satisfactory, nothing is changed; otherwise, either the ontology is modified (Noy and McGuinness, Reference Noy and McGuinness2001) or the competencies and the corresponding SPQARL request are modified. These two alternatives are illustrated by the retro-action loops in Figure 2.
In order to verify the operational relevance of CWMO, its consistency was verified with the Pellet reasoner (Sirin et al., Reference Sirin, Parsia, Grau, Kalyanpur and Katz2007) integrated into Protégé. Once CWMO was operational (without any logical error), its ability to represent the knowledge domain was tested by translating its competencies into SPARQL requests (Table 5). The result of the SPARQL request is compared to the competence. These SPARQL request is applied with Protégé as illustrated in Figure 7 where the top frame represents the request applied on the ontology and the bottom frame the result of the request. Iteratively, adjustments are made by testing a SPARQL request and modifying the ontology or the request according to the result.
Example of translation of competences into SPARQL requests
SPARQL request to determine evaluation techniques applied on subject of creative workshop and the result.
Discussion of the methodology
The motivation for the creation of a new methodology was to propose a new approach to extract knowledge from the organizational modeling in order to integrate and structure these concepts in an ontology.
According to the review of methodologies, very few compare itself with other to measure the interest of the proposition. The only way to compare the present proposition to other methodologies is to use the same criteria used for the review of the ontology engineering methodologies (Iqbal et al., Reference Iqbal, Murad, Mustapha and Sharef2013a). These criteria are (Iqbal et al., Reference Iqbal, Murad, Mustapha and Sharef2013a): type of development, collaborative construction, reusability support, degree of application dependency, life cycle recommendations, strategies to identify concept, methodology detail, and interoperability support. The O-O-DOCK can be considered as implementing a stage-based development given that it follows stages and implements worksheets. In terms of collaboration, it was not explicitly considered. However, the organizational modeling generates graphical representations that are easy to share and that permit validation and correction of the process by other contributors. The semi-formal representation of the ontology has also the same advantage of being easily readable. Moreover, the actual version of the ontology editor protégé is available as a Web application that provides collaborative features. So, by itself, the methodology does not consider the collaborative aspects except for information collection and above all, the ontology editor Protégé permits collaborative engineering. The reusability of concepts from other ontologies is clearly considered during the conceptualization but it does not tackle the reuse of entire ontologies. Considering the aims of this work is to generate ontology for a new system; the interoperability with other systems is not considered. Additionally, there is no standard between systems concerning knowledge modeling of creativity process. Concerning the life cycle, it is considered as a part of the features of the ontology depends on the data that would be collected during the use of the system. The strategy for identifying concept can be considered as middle out since the organizational modeling is a collaboration with the knowledge engineer and experts (expert of creative workshops). Concerning the degree of application dependency, it can be considered as semi-independent as the O-DOCK methodology that is the pillar of this methodology is dedicated to knowledge management. Finally, the interest of this methodology is to provide the identification of concepts based on organization modeling. In addition, the methodology is quite modular as the O-DOCK methodology permits designing the ontology but also the system that will use it with the same modeling.
Conclusion
Ontology is becoming crucial in modern collaborative product/process innovation (Sorli and Stokic, Reference Sorli and Stokic2009). It permits capturing, sharing, and reasoning in an area of knowledge and thus facilitating collaboration and interoperability (Lee et al., Reference Lee, Chae, Kim and Kim2009). It also concerns creativity and creative workshops with the emergence of dedicated digital systems. However, these systems do not exploit the potential of ontologies concerning interoperability and reasoning. So, the aim was to create an ontology that contributes to a creative support system. As the digital system that would exploit the ontology was designed with an organizational approach, the knowledge of the domain was already implicitly formalized through organizational modeling. The ambition is to propose a methodology based on the organizational model. The literature review of ontology engineering methodology shows that to find an adapted off-the-shelf methodology despite decades of research on the subject. The articles attempt to respond to this issue by proposing a sufficiently detailed organization-based ontology engineering methodology. The application of the methodology lead to the creation of the CWMO that represents the knowledge domain of CPS workshop in order to provide the adapted knowledge to each person involved and to permit an acknowledged decision-making during the workshop.
The methodology has been created to respond to the needs of creating an ontology for a multi-agent creative support system, one of the perspectives would be validating the methodology with another ontology engineering project. Another perspective is to evaluate the ontology in real situations with the creative support system during a creative workshop. The last perspective would be to improve the O-O-DOCK ontology engineering methodology. The idea would be to create a generic ontology for describing the organizational modeling and partly automatize the process of creating the ontology. O-DOCK methodologies could be modified to integrate BPMN and use the BPMN ontologies (Rospocher et al., Reference Rospocher, Ghidini and Serafini2014), or in opposite, a kind of BPMN ontologies could be created for O-DOCK.
Alex Gabriel obtained his Industrial System Engineering master in 2013. Then, he completed his PhD in Industrial System Engineering in 2016 at the University de Lorraine, France. The theme of his dissertation is the knowledge management during the collaborative process of creativity workshop. Currently, he is assistant professor at Arts et Métiers ParisTech, France. The focus of his research is the use of new technologies for manage knowledge and provide assistance during the innovation, creativity and new product design processes.
Pedro Chavez Barrios is a PhD student at the University of Lorraine. His work is about knowledge engineering and semantic approaches to compare textual corpus.
Davy Monticolo is a Associate Professor at the University of Lorraine. He got his HDR in December 2015 and he received his Ph.D. (2008) in the University of Technology of Belfort-Montbélaird (France) and a M.S. (2005) degrees in the University of Savoie, France. His research interests are: Web Intelligence, Multi-Agents Systems, Knowledge Engineering and Modelling, Semantic Web and Ontologies used to design knowledge based systems. He is currently on the board of the French Research Group in Artificial Intelligence.
