EDON A METHOD FOR BUILDING AN ONTOLOGY AS SOFTWARE ARTEFACT

1. EDONA METHOD FOR BUILDING AN ONTOLOGY AS SOFTWARE ARTEFACT Emiliano Reynares, María Laura Caliusco, María Rosa Galli Doctorado en Ingeniería – Mención Sistemas de Información CIDISI UTN FRSF

2. AGENDA The problem Overview of EDON EDON Method Experiences from a study case Discussion and future research directions

3. THE PROBLEM • Recognizing the context • Environmental business dynamics • “Embededness” of business rules into software applications

4. THE PROBLEM • A proposal • Encapsulate business rules in a specific system component • RULES BASES, but… • using different attributes to represent the same thing • defining rules based on incompatible notions of the same concept • could affect the rule interaction [Zacharias, 2008]

5. THE PROBLEM • What about ontologies? • As artefacts intended to explicitly represent the data semantics, could encapsulate business rules while avoiding concept misunderstanding • BUT… • Ontology building process must be considered in the context of the software development project • Conceptual dynamics issue needs to be tackled [Hepp, 2007] • A descriptive path enable to quickly and smoothly evolve through further extended versions of the ontology

6. EDON EvolutiveDevelopment of ONtologies • Pursues three goals • To develop from scratch an ontology intended to encapsulate the declarative specification of business rules, supporting accurate and well-defined requirements of a software system • To enable the intertwining of ontology and software development process, facilitating a quick integration of both artefacts • To allow the ontology readily reflect the changes in quickly evolving domains by providing a phase model to evolve through successive versions of the ontology

7. EDON • Collaborately performed by • Domain Experts • DEs interact daily with the problem domain, so they have the knowledge to be modelled • Knowledge Engineers • KEs have the know-how for representing the reality in a way that supports the requirements of a software application • Modelling activities are performed at a high level of abstraction to facilitate the communication between these profiles • Short development iterations allow to readily reflect conceptual dynamics and changes in requirements, and both profiles can take advantage of what was learned during the building of earlier versions of the ontology

8. EDON In the context of software development process

9. EDON The process

10. EDON Requirements Selection Process

11. EDON • Requirements Selection Process in a study case • Functional requirements selected considering two issues: • Ontology should provide ontology-based reasoning over business rules • Human users of the software application should not interact directly with the underlying ontology but through the software application. • “Project”, “Researcher”, and “Funding agency” were considered the core entities • A storyboard exposing a functional requirement selected for further development: • “The software system should allow a researcher to upload a research project pending approval. During this upload, the software system must validate the input data against the rules defined by the agency intended to funding the project”

12. EDON Ontology Development Process

13. EDON Ontology Specification Activity in a study case

14. EDON • Ontology Conceptualization Activity in a study case • Representation of the knowledge associated to the domain entities by using the Lexicon Extended Language (LEL) [Leite et al, 1993] • Representation classified in four categories: “object”, “subject”, “verb”, and “state” • Term described by “notion” and “behavioral response”

15. EDON • Ontology Formalization Activity in a study case • Generation of a base ontology by performing a systematic process [Breitman et al, 2004] • It gives an ontological structure to the terminology described in the conceptualization activity • The structure is independent of any ontology implementation language but can be mapped into most of them

16. EDON • Ontology Refinement Activity in a study case • Extending the base ontology by focusing on the formulation of axioms • Knowledge obtained from the information sources identified • DEs collaborate with the aim of producing the tightest possible model of reality • KEs are focused on supporting a set of functional requirements

17. EDON • Ontology Implementation Activity in a study case • Encoding of the ontology in an implementation language • Evaluation increases along development stages. Three dimensions must be evaluated [Burton-Jones et al, 2005] [Gangemi et al, 2006]: • Syntactic dimension, regarding the way the ontology is written • Semantic dimension, concerning the consistent modelling of the ontology • Functional dimension, related to the intended use of the ontology

18. EDON Ontology Alignment Process

19. EDON • Ontology Aligment Activity in a study case • A new ontology is created by establishing a set of correspondences between entities belonging to two different ontologies [Pavel et al, 2011] • A correspondenceCo is a 4-uple { id, e1, e2, r} where: • Idistheidentifier of a givencorrespondence • E1 and e2 are entities of thefirst and thesecondontology, respectively • ristherelation holding betweene1 and e2 • So, thecorrespondenceCo:= {id, e1, e2, r} assertsthattherelationrholdsbetweenthe ontologies entitiese1 and e2

20. EDON Ontology Aligment Activity in a new iteration

21. EXPERIENCES • From a study case • Importance of requirements grouping activity • Requirements grouping activity has shown a deep influence in the efficiency of the overall ontology development process • More powerful conceptualization formalism • Although using LEL has proven to be useful to facilitate the communication between the DEs and KEs, a more powerful formalism will improve the way complex business rules are expressed • Software development team highlighted the ability to adapt the overall software system to changing business requirements with minor modifications on the software procedural code • DEs showed interested on the possibility of embed its knowledge in the software system, participating in the process and evolving from knowledge to ontology in a smooth way

22. DISCUSSION • EDON partly draws from the knowledge developed in several fields • Using of competency questions from TOVE Project • [Gruninger et al, 1995] • Definition of iterative life cycle • Definition of orthogonal activities • Definition of collaborative work of DEs and KEs from Methontology[Fernández-López et al, 1997] • Applying of the main principles of XP agile software methodology • [Beck, 2000] • Using of Application Languages from LELs • [Leite et al, 1993] • Using of a systematic process to evolve from LELs towards an ontology • [Breitman et al, 2004]

23. DISCUSSION • Distinctive features • Development of an ontology intended as a structural conceptual model of an information system, encoding business rules in a declarative way • Aptness to intertwine the software and ontology development process • Ontology development through a phase model that takes advantage of the benefits of agile approaches

24. FUTURE RESEARCH DIRECTIONS • Will be focused on the following areas • Tracing a set of guidelines • for the correct grouping of requirements will help the experts to improve the requirements selection process • Researching for a more powerful formalism • for ontology conceptualization with the aim to enable the expression of complex business rules in a high level of abstraction • Formulation of a systematic process • to generate the ontology structure from such high level expressions • Acquiring of additional validation cases

25. Questions? Emiliano Reynares, María Laura Caliusco, María Rosa Galli ereynares@frsf.utn.edu.ar mcaliusc@frsf.utn.edu.ar mrgalli@santafe-conicet.gov.ar CIDISI UTN FRSF