The importance of knowledge domain in order to elicit requirements of a solution or product that fulfill the needs and expectative of clients and users is widely accepted among the research community [2] [12]; especially when the solution-solvers or product developers are not immerse in the application domain. Recently, the use of ontologies as a means to define and make explicit this knowledge has become seen as a good option [14] [6]. Domain ontologies can be used as a way of facilitating the understanding among stakeholders, detecting of missing and erroneous information and describing the domain in the way of domain specialists thinking, hence avoid ambiguous, insufficient and incomplete requirements. In this work, the term domain specialists refers to all people involved in the application domain, which could have partial and different knowledge of it depending on their role and experience.
In particular, the OWL Web Ontology Language has been designed for use by computer systems instead of just presenting information to humans. OWL facilitates greater machine interpretability of Web content by providing additional vocabulary to XML, RDF and RDF Scheme, along with a formal semantics. OWL allows us to describe the semantics of knowledge in a machine-accessible way, therefore it has promoted the development of multiple and varied software applications [1].
Nevertheless, ontology development is a complex and timeconsuming activity that seems to be an art rather than a formal method. Besides, not all domains are equal, there are domains where not all concepts and their relationships can be formally defined, the solutions of most of their problems are situated and diverse, not susceptible to be described by an algorithm, and where domain specialists use large amounts of tacit knowledge in order to solve problems. In this kind of domains, named Informally Structured Domains, providing certain structure that synthesizes the knowledge of domain specialists and make it explicit is fundamental in order to develop a correct and appropriate solution or product [9]. This structure can be proportionate by an OWL ontology.
The objective of this paper is to present a new approach to generate an OWL ontology from the Knowledge Domain Extended Lexicon (KDEL), in order to facilitate the understanding, development and validation of an ISD. There is a similar approach proposed by [3], however our work is designed keeping in mind the ISD characteristics. Thus, our motivations is to provide a tool that minimize the time to structure and visualize the domain knowledge, with the further aim of facilitating to discover relationships that could have hidden to domain specialist awareness.
The rest of this paper is structured as follows: Section 2 provides a detailed explication of KDEL, section 3 describes the OWL ontology language, the OWL building process from KDEL is introduced in section 4, section 5 reports the results of the application of the method in ISD real cases, finally section 6 concludes our work with future directions.
The term Universe of Discourse (UofD) generally refers to the collection of objects being discussed in a specific domain. It is evident that there is a correlation between the domain knowledge and the terms used daily by domain specialists. Thus, in order to assist to solution-solver or product developer in understanding the terms of the domain specialists, several authors [8] [13] propose the use of a glossary of common terms with the additional aim of facilitating communication and understanding of all involved in a project. Despite that natural language is ambiguous and depends on the context for interpretation, it is the only notation that is commonly readable and understandable by the domain specialists and its use encouraging them to participate dynamically in the first steps of any project [7].
One of these proposals is the Language Extended Lexical (LEL) [11], which is a set of terms related to the application domain with the aim of understanding the language of the problem without worrying about understanding the problem. In order to give an initial structure to the knowledge domain, each term in the UofD is classified as object, subject, verb or state and is described by a notion (denotation) and a behavioral response (connotation).
In order to deal with the challenges of ISD, the Knowledge of Domain on an Extended Lexicon (KDEL) evolves LEL by modifying two aspects of it. The first one is that, besides the classification of object, subject, verb and state, it incorporates definitions and NF-Requirements. The rationality behind this is that in the early stage of any development software project, the domain specialists do not have a clear idea of what they want. In ISD, even they do not have a well-defined structure of the application domain knowledge and a great quantity of it is tacit or implicit. Thus, the domain specialists interleave in their discourse needs, desires, domain properties, and current and future processes. To give a preliminary order to this information, KDEL characterizes the application domain in terms, which can be concepts, definitions and Non-Functional (NF) requirements; as it is explained below:
-Concepts. They are equivalents to the terms in LEL and are described by a notion (denotation) and a behavioral response (connotation). KDEL classify the concepts as objects, subjects or verbs. Unlike LEL, state is not considered as a concept because we consider that it is inherently attached to subjects or objects.
-Definitions. They are statements that assign a precise or consensual meaning to terms used in the applications domain, but that cannot be considered as concepts; thus they cannot have a behavioral response. Definitions are necessary in order to understand the context of the application domain.
-NF Requirements. They refer to concerns not related to the functionality of the software, such as usability, flexibility, performance, interoperability and security [5].
One of the objectives of the KDEL is to capture the NF-Requirements introduced in the early discourses of domain specialists; however, in subsequent stages of the process, solution-solvers of product developers can include more of them.
The second aspect that KDEL modifies is the internal structure of terms. The application domain will be affected after a solution or product was deployed in it; hence, the set of terms, as well as its denotation and connotation, will not be the same. To handle this issue, a future behavioral response is added to the structure of them, which is not mandatory; it is only added if it is evident in the early stages of the project. It allows the requirements engineers to gain more domain knowledge and explore new possibilities of solution by understanding the problem and the structure of the solution. Figure 1 depicts a scheme of KDEL in an UML class diagram.
Handling synonymous is a special issue of any representation of language. Two or more terms are synonymous if they share the meaning of a concept. In KDEL, when two or more terms are synonymous they share the same structure and the two terms are separated by a diagonal slash.
Based on the rules to describe terms proposed in [7], a set of suggestions for description of terms have been proposed for KDEL. Table 1 gives the rules of description for objects, Table 2 for subjects, Table 3 for verbs, Table 4 for definitions and Table 5 for NF-requirements.
Describe the goals to be achieved by the NF-requirement
Besides the rules describes allow, in order to build KDEL the following task are also necessary:
-Apply techniques of discourse analysis to identify syntactic constructions that could hide tacit knowledge.
-Record, for each term in KDEL, questions or comments that will be consulted to domain specialists. -The evaluator indicates to patients when the next test will be applied.
The concept of evaluator disappears in the future system; their functionalities will be carried out by the software system.
-Must the evaluator be a neuro psychologist? -How the evaluator determines that the patient has multiple sclerosis? -How he or she makes the evaluation? -How the evaluator defines the date of the next test?
KDEL facilitates to solution-solver or product developers to be familiar with the language of domain specialist; hence it minimizes the difficulties involved by describing the domain using a semiformal or formal method. However, there are some drawbacks such as the redundancy in the description of terms, which causes a validation time-rise. In addition, it must be considered the hard and time-consuming activity of using KDEL to build a graphical conceptual model, which will be used by solution-solvers or product developers in two different ways: to facilitate the validation of the structure of domain and to let bring to light relationships that were hide to domain specialists.
An ontology is an explicit formal specification of how to represent the entities and relationships that exist in a domain. They describe the properties of a domain and reasoning about it [4]. Ontologies have also been used to capture and synthesize knowledge from diverse domain specialists, especially when their knowledge depends on their own interests and points of view [6]. Thus, several authors have raised the use of ontologies to formalize the application domain.
OWL is a widely used proposal of formal languages for ontologies [1] , which is defined using the syntax of RDF/XML. The elements of an OWL ontology concern classes, properties, instances of classes, and relationships between these instances. This section presents the essential components of this language in order to introduce those elements.
As was mentioned above, KDEL is a glossary of interrelated terms. They are classified as object, subject or verb and have a description. In particular, objects and subjects represent an entity in the domain and have relationships with other terms, which are described in the current behavioral. Thus, there is a correlation of them with OWL classes. Likewise, the relationships between concepts are equivalent with OWL properties.
A set of heuristics, rules or methods that helps to solve problems faster than it would if all the computing were done, have been proposed in order to facilitate the conversion of KDEL to OWL, which are listed follows: their handling is considered to be future work.
In order to build an OWL ontology from a KDEL lexicon, the following process is proposed. The process works together with the heuristics proposed above.
1) Perform a pre-processing of KDEL based in the rules of description (Section 2.1). 2) Convert KDEL terms into OWL classes (Heuristics 1, 3, 5). 3) Convert KDEL relationships into OWL properties (Heuristic 4). 4) Convert KDEL synonymous into OWL classes by creating the OWL property between them: Is_Synonym_of (Heuristic 2). 5) Create an OWL file following the format of RDF/XML by integrating classes, properties and individuals, as identified in the previous steps. 6) Name the file created in the last step with the name selected for the OWL ontology including the file extension for OWL.
The solution-solvers or product developers must learn the domain terms in a short period of time in order to reduce the symmetry of ignorance, improve the cognitive dialogue and find, with the domain specialists, the set of solution or product requirements. However, in Informally Structured Domains, the universe of discourse is frequently too large and specialized. In addition, the process of validation of the terms is generally a boring and stressful task. Thus, a software system has been developed to support the handle of KDEL with the aims to facilitate the building, maintenance and validation of the KDEL. The system is designed to be used by the design team and it is able to manage several projects. The terms of KDEL are recorded in a relational database, following the structure showed in Figure 1.
This database is the input of another software system that executes the OWL ontology building process described in the previous section. The software also has the functionality of represent in a graphical format the RDF/XML file. Thus, it allows the visualization of KDEL with the aim of facilitating the validation process by domain specialists. In addition, if domain specialists realize that the description of a term must be improved, the software allows this change and automatically reconstructs the KDEL and the OWL file.
Figure 3 depicts a screen with the graphical representation of KDEL of the domain of cognitive diagnosis for multiple sclerosis patients. This project was developed for a Mexican real organization; thus the KDEL was developed in Spanish. However, it is not our intention to give a detail description of the lexical, but demonstrate the utility of the software tool in order to facilitate the validation of the domain terms and their relationships. The visualization also allows domain specialists to discover relationships that were hidden to them. Therefore, the software system is also appropriate for discovery knowledge issues. The generation of the ontology in each project allowed the extraction of relevant information from KDEL, which led to a view of the information in a synthesized way. This process also facilitated the correction of the following errors committed in KDEL: 1) repeated information, 2) ideas vaguely described, 3) ideas mixed or unfinished and 4) typing errors. In summary, the OWL ontology building process improves KDEL, which facilitates the validation of it. In addition, the automatic generation of the OWL ontology significantly shortens the time and effort required to generate a graphical representation of the domain and contributes to the understanding of the ISD.
The application of KDEL and the generation of an OWL ontology from it in order to provide certain structure and facilitate the understanding of the domain to the solution-solvers or product developers in ISD real cases showed that the process minimizes the time of understanding the domain. It also minimizes the time it would take the domain specialists to validate the domain structure due to the graphical domain visualization. Finally, the graphical domain visualization also facilitates the discovery or relationships that were hidden to the domain specialist; allowing the detection and correction of errors in KDEL.
As future work it is necessary to apply the process in others ISD real cases in order to verify their effectiveness and improved it, if necessary.
Our thanks to the Unity for Health Research UIS for its acronym in Spanish (Unidad de Investigación en Salud) for allowing us to work with them in the development of the rehabilitation system for multiple sclerosis patients.