Microsoft Word Scenarios-NeOnMethodology-CameraReadyVersion-vFinal doc



Yüklə 89,71 Kb.
Pdf görüntüsü
tarix02.03.2018
ölçüsü89,71 Kb.
#29264


NeOn Methodology for Building Ontology Networks: a 

Scenario-based Methodology 

Asunción Gómez-Pérez

1

, Mari Carmen Suárez-Figueroa



1

 

1



 Ontology Engineering Group. Departamento de Inteligencia Artificial. Facultad de 

Informática. Universidad Politécnica de Madrid. Boadilla del Monte, Madrid, Spain 

{asun, mcsuarez}@fi.upm.es

 

Abstract. The 1990s and the first years of this new millennium have witnessed 

the  growing  interest  of  many  practitioners  in  methodologies  that  support  the 

creation of single or isolated ontologies. All these approaches have supposed a 

step  forward  since  they  have  transformed  the  art  of  constructing  single 

ontologies  into  an  engineering  activity.  With  the  goal  of  speeding  up  the 

ontology development process, ontology practitioners are starting  to reuse and 

re-engineer  as  much  as  possible  knowledge  resources  (such  as  ontologies, 

thesauri,  lexicons,  and  classification  schemas),  which  already  have  reached 

some  degree  of  consensus.  In  this  paper,  we  present  the  set  of  nine  scenarios 

identified in the NeOn Methodology framework. Additionally, we present how 

such scenarios have been followed in different use cases. 



Keywords: Methodology, ontology development, reuse, re-engineering. 

1   Introduction 

There are well known methodological approaches (e.g., METHONTOLOGY [ 1], On-

To-Knowledge  [ 5],  and  DILIGENT  [ 4])  that  have  gone  a  step  forward  by  having 

transformed  the  art  of  constructing  single  ontologies

1

  into  an  engineering  activity. 



Other  methods  that  use  ontology  learning  techniques  [ 2]  propose  to  (semi)-

automatically build ontologies.  

However,  the  development  of  ontologies  in  different  international  and  national 

projects has revealed that there are different ways to build ontologies. Just to name a 

few  of  them,  in  the  Esperonto

2

  project  ontologies  were  built  from  scratch  using 



METHONTOLOGY;  in  Knowledge  Web

3

  the  aligning  and  versioning  of  ontologies 



was treated as well as the use of best practices or patterns; and in the SEEMP

4

 project, 



a  good  ontology  specification  document  helped  to  find  existing  ontologies  and 

consensual knowledge resources that were re-engineered into ontologies.  

                                                           

1

 



single ontology is an ontology that has not got any type of relationship (domain dependent 

or independent) with other ontologies 

2

 

http://www.esperonto.net 



3

 

http://knowledgeweb.semanticweb.org 



4

 http://www.seemp.org 




Up to date, there are no methodologies that help ontology developers to build large 

ontologies  in  settings  where  distributed  teams  could  collaboratively  build  ontologies 

by  reusing  and  possibly  re-engineering  knowledge  resources,  using  alignments  and 

having in mind the continuous evolution of the ontologies.  

It is foreseeable that the Semantic Web of the future will be characterized by using 

a large number of ontologies embedded in ontology networks

5

 built collaboratively by 



distributed teams. Such networks may include ontologies that already exist, mappings 

among ontologies, ontologies in continuous evolution, or they could be developed by 

reusing  available  ontological  and/or  non-ontological  resources  (such  as  glossaries, 

lexicons,  classification  schemes,  and  thesauri).  For  this  reason,  our  objective  is  to 

create the NeOn Methodology that supports both the collaborative aspects of ontology 

development and the reuse and dynamic evolution of ontology networks. 

In this paper we have identified a set of nine scenarios for building ontologies and 

ontology networks in the framework of the NeOn Methodology, 

emphasizing the reuse 

of existing knowledge resources (ontological and non-ontological), generalizing from 

previous  experiences,  covering  the  drawbacks  of  the  existing  methodologies,  and 

taking  into  account  the  new  trends  based  on  collaboration  and  dynamism.  We  also 

present how such scenarios have been used in different use cases. 

The rest of the paper is organized as follows: Section 2 presents the state of the art 

on  methodologies  for  ontology  development;  Section  3  describes  the  research 

methodology followed to create the NeOn Methodology; Section 4 explains the set of 

scenarios  for  building  ontology  networks;  and  Section  5  shows  the  use  of  the 

scenarios in different project use cases. Finally, Section 6 provides some conclusions.  

2   State of the Art on Methodologies for Ontology Development 

METHONTOLOGY,  On-To-Knowledge,  and  DILIGENT  were  up  to  now  the  most 

referred methodologies for building ontologies. These methodologies mainly include 

guidelines  for  single  ontology  construction  ranging  from  ontology  requirements 

specification  to  ontology  implementation  and  they  are  mainly  targeted  to  ontology 

researchers. In this section we compare them according to the following dimensions: 

collaboration

6

 and dynamism



7

. Since reuse can be seen as a kind of collaboration, we 

have also analyzed the degree of coverage of these methodologies with regard to the 

reuse of ontological and non-ontological resources. 



METHONTOLOGY [ 1] enables the construction of ontologies at the knowledge 

level. It includes (a) the identification of the ontology development process; (b) a life 

cycle  based  on  evolving  prototypes;  and  (c)  some  techniques  to  carry  out 

management,  development-oriented,  and  support  activities.  With  respect  to  the 

aforementioned  dimensions,  notions  of  collaboration  are  not  included.  Although 

dynamic

 aspects are mentioned, detailed guidelines about how to manage versions are 

                                                           

5

 



An  ontology  network  is  a  collection  of  ontologies  related  together  via  a  variety  of  different 

meta-relationships such as mapping, modularization, version, and dependency relationships 

6

 

Collaboration  refers  to  consider  distributed  ontology  engineering  among  heterogeneous  and 



geographically distributed groups of domain experts and ontology practitioners 

7

 



Dynamism refers to the evolution and versioning of the ontologies 


not  provided.  Regarding  the  reuse  of  knowledge  resources,  METHONTOLOGY 

includes  the  list  of  activities  to  be  carried  out  during  ontology  reuse  and  re-



engineering processes

, but it does not provide detailed guidelines for such processes, 

nor  does  it  consider  different  levels  of  granularity  during  the  reuse  of  ontological 

resources  (e.g.,  modules  or  statements).  Moreover,  METHONTOLOGY  does  not 

consider  the  reuse  of  ontology  design  patterns  (ODPs)

8

  neither  the  reuse  nor  re-



engineering of non-ontological resources

The On-To-Knowledge methodology [ 5] proposes to build ontologies taking into 



account how these are going to be used in knowledge management applications. The 

processes proposed by this methodology are the following: feasibility study, kickoff, 

refinement,  evaluation,  and  maintenance.  Regarding  the  aspects  analyzed  in  this 

paper,  such  a  methodology  does  not  consider  collaboration.  Regarding  the  dynamic 

evolution  of  ontologies,  it  proposes  to  create  a  new  version  after  testing  possible 

effects  to  the  application.  However,  no  guidelines  about  how  to  manage  different 

versions  and  when  to  create  them  are  provided.  With  respect  to  the  reuse  of 

knowledge  resources,  in  the  kickoff  process  it  is  mentioned  that  developers  should 

look for potentially reusable ontologies. However, this methodology does not provide 

detailed guidelines for identifying such ontologies nor for reusing them. Besides, the 

methodology does not explicitly mention guidelines for the reuse and re-engineering 

of non-ontological resources

, nor for the reuse of ODPs

The  DILIGENT  methodology  [ 4]  is  intended  to  support  domain  experts  in  a 

distributed  setting  in  order  to  engineer  and  evolve  ontologies.  This  methodology  is 

focused  on  collaborative  and  distributed  ontology  engineering.  Its  ontology 

development process includes the following five activities: building, local adaptation, 

analysis,  revision,  and  local  update.  With  respect  to  the  dimensions  analyzed  here, 

collaboration

  is  the  central  point  in  this  methodology.  Regarding  the  dynamic 

dimension, DILIGENT proposes the creation of different versions of the ontology, but 

it  does  not  provide  guidelines  on  how  to  manage  such  versions  or  when  to  create 

different versions, nor how changes can affect. With regard to the reuse of knowledge 

resources,  the  methodology  does  not  include  guidelines  for  the  reuse  and  re-



engineering of existing knowledge resources

Taking  into  account  the  current  status  of  methodologies,  our  aim  is  to  create  the 



NeOn  Methodology  for  building  ontologies  and  ontology  networks

  covering  the 

drawbacks presented in the three methodologies analyzed, and benefiting from them. 

3   Research Methodology 

As  approach  to  build  the  NeOn  Methodology,  we  used  a  “divide  and  conquer” 

strategy by decomposing the  general problem to be solved in different subproblems. 

To obtain the solution to the general problem, that is, the development of an ontology 

network,  the  solutions  to  the  different  subproblems  are  combined.  In  our  case,  the 

subproblems  are  the  9  identified  scenarios,  which  are  composed  of  processes  and 

activities.  To  identify  the  scenarios,  we  based  on  the  different  studies  carried  out  to 

                                                           

8

 ODPs are considered ontology modeling solutions that after being recurrently used for solving 



similar design problems can be identified as generalized design solutions 


revise  the  state  of  the  art  of  ontology  development,  on  the  experience  of  building 

ontologies in different projects, and on the analysis of the NeOn

9

 use cases. 



It  is  worth  mentioning  that  based  on  [ 3],  the  main  principles  that  guided  the 

construction of the NeOn Methodology

 for building ontology networks were:  

1.

  The  methodology  should  be  general  enough  in  the  sense  that  it  should  not  be 



driven to solve ad-hoc cases. 

2.

  The methodology should be independent of the existing technology.  



3.

  The methodology should define each process or activity precisely; state clearly 

its  purpose,  inputs  and  outputs,  the  actors  involved,  when  its  execution  is  more 

convenient, and the set of methods, techniques and tools to be used.  

4.

  The  methodology  should  facilitate  a  promptly  assimilation  by  software 



developers and ontology practitioners.  

Apart from the aforementioned principles, we also used the following ones, based 

on ideas presented in [ 3]: 

 

Completeness. A methodology must consider all the cases presented and propose 

solutions to all of them.  

 

Consistency.  A  methodology  must produce the same set of results for the same 

problem, independently of who carries it out.  

 

Efficiency.  A  methodology  must  be  efficient  and  able  to  achieve  its  objective. 

This  means  that  the  methodology  should  allow  the  construction  of  ontologies 

with fewer resources (time, money, etc.) and with better quality.  

 

Environment.  Methodologies  can  be  classified  into  scientific  (where  ideas  are 

validated) and technological (where artifacts are built). The NeOn Methodology 

can be considered as a technological one, because the main result after applying it 

should be a technological product, that is, an ontology network.  

 

Finiteness. A methodology must be composed of a finite number of the elements 

and a finite number of activities and processes.   

 

Flexibility. A methodology must allow the adaptation to concrete needs. 

 

Perspectives. A methodology must facilitate the use of different approaches.  

 

Transparency.  A  methodology  must  be  like  a  white  box,  allowing  the  users  to 

know in every moment the processes or activities that are being performed, who 

is performing them, etc.  

 

Usability. The degree of difficulty in using the methodology must be minimal. 



4   NeOn Scenarios for Building Ontology Networks 

The  NeOn  Methodology  for  developing  ontology  networks  takes  into  account  the 

existence  of  multiple  ontologies  in  ontology  networks,  the  collaborative  ontology 

development, the dynamic dimension, and the reuse and re-engineering of knowledge 

resources.  One  of  the  key  elements  in  this  methodology  is  the  set  of  9  scenarios 

identified  for  building  ontologies  and  ontology  networks,  shown  in  Fig.  1.  Directed 

arrows  with  numbered  circles  associated  represent  the  different  scenarios.  Each 

scenario is decomposed into different processes or activities that are represented with 

colored circles or with rounded boxes. Such processes and activities are defined in the 

                                                           

9

 

http://www.neon-project.org 




NeOn  Glossary  of  Processes  and  Activities  [ 6].  Fig.  1  also  shows  (as  dotted  boxes) 

existing  knowledge  resources  to  be  reused  and  possible  outputs  (ontology  networks 

and alignments) that result from the execution of some of the scenarios. 

 

Fig. 1. Scenarios for Building Ontology Networks 

The  most  common  scenarios  that  may  arise  during  the  ontology  development  are 

the following, though such a set of scenarios can not be considered exhaustive.  



Scenario 1: From specification to implementation. Ontology developers develop 

the  ontology  network  from  scratch,  that  is,  without  reusing  existing  knowledge 

resources.  The  ontology  development  should  start  with  the  knowledge  acquisition 

activity

,  which should be carried out during the  whole development. Simultaneously 

with the knowledge acquisition, ontology developers should specify the requirements 

that the ontology should fulfill, by means of the ontology requirements specification 



activity

.  The  objective  of  this  activity  is  to  output  the  ontology  requirements 

specification  document  (ORSD)  that  includes  the  purpose,  the  scope  and  the 

implementation language of the ontology network, target group and intended uses of 

the ontology network, and the set of requirements the ontology network should fulfill, 

mainly  in  the  form  of  competency  questions  (CQs).  After  such  an  activity,  it  is 

advisory to carry out a quick search for knowledge resources using as input the terms 

appearing  in  the  ORSD.  The  search  results  allow  knowing  which  types  of  resources 

are  available  for  a  possible  reuse  during  the  development.  Then,  the  scheduling 

activity

  must be carried out, using the ORSD and the results of such a quick search. 

After  the  scheduling,  the  ontology  developers  should  carry  out  the  rest  of  the 

activities 

(conceptualization

formalization

and 



implementation

using 



METHONTOLOGY or On-To-Knowledge. 


Scenario  2:  Reusing  and  re-engineering  non-ontological  resources  (NORs)

Ontology developers should carry out the non-ontological resource reuse process for 

deciding,  according  to  the  requirements  in  the  ORSD,  which  existing  NORs  can  be 

reused  to  build  the  ontology.  Then,  the  non-ontological  resource  re-engineering 



process

 should be performed to transform the selected NORs into ontologies. 



Scenario  3:  Reusing  ontological  resources.  Ontology  developers  use  existing 

ontological  resources  for  building  ontology  networks.  There  are  different  ways  of 

reusing ontological resources: (a) ontologies can be reused  as a whole; (b) only one 

part  or  module



10

  can  be  reused;  and  (c)  ontology  statements

11

  can  be  reused.  Terms 



that  appear  in  the  ORSD  are  used  by  ontology  developers  in  the  search  for  existing 

ontological  resources  to  be  reused.  For  integrating  the  ontological  resources  to  be 

reused, ontology developers can decide to reuse them such as they are in the ontology 

network  being  developed  following  the  activities  of  Scenario  1.  If  the  resources  are 

needed,  for  example,  in  another  implementation  language,  ontology  developers  can 

perform a re-engineering process following Scenario 4. Another possibility is to have 

several  ontological  resources  on  the  same  domain;  then,  the  ontological  resources 

could be merged to obtain a new ontological resource following Scenarios 5 or 6. 



Scenario  4:  Reusing  and  re-engineering  ontological  resources.  Ontology 

developers  reuse  existing  ontological  resources  and  re-engineer  them  before  their 

integration in the ontology network. The ontological resource re-engineering process 

is composed of the following activities [ 6]: ontological resource reverse engineering



ontological  resource  restructuring

,  and  ontological  resource  forward  engineering

These activities might be carried out at four different levels, depending on the needs 

of each particular case: at the specification level, at the conceptualization level, at the 

formalization  level,  and  at  the  implementation  level.  After  carrying  out  the 

ontological resource re-engineering process, ontology developers should integrate its 

result into the corresponding activity of Scenario 1. 

Scenario  5:  Reusing  and  merging  ontological  resources.  Ontology  developers 

reuse  and  merge  existing  ontological  resources  in  the  development  of  the  ontology 

network. This scenario arises only in those cases where several ontological resources 

in  the  same  domain  are  selected  for  reuse  and  when  ontology  developers  wish  to 

create  a  new  ontological  resource  from  two  or  more,  possibly  overlapping,  source 

ontological  resources.  It  is  also  possible  that  ontology  developers  wish  only  to 

establish alignments among the selected resources in order to create the network.  

Scenario  6:  Reusing,  merging  and  re-engineering  ontological  resources

Ontology  developers  reuse,  merge,  and  re-engineer  existing  ontological  resources  in 

the  ontology  network  building.  This  scenario  has  the  same  sequence  of  activities  as 

Scenario  5;  however,  here  ontology  developers  can  decide  not  to  use  the  set  of 

merged ontological resource such as it is, but to re-engineer it. Once the set of merged 

ontological resources is re-engineered, the result of such process should be integrated 

in the corresponding activity of Scenario 1. 

                                                           

10 

A module is a part of the ontology that defines a relevant set of terms 



11 

An ontology statement contains three components: subjectpredicate, and object 




Scenario 7: Reusing ontology design patterns. Ontology developers access ODPs 

repositories

12

 to reuse ODPs for different purposes: to reduce modeling difficulties, to 



speed up the modeling process, or to check the adequacy of modeling decisions.  

Scenario  8:  Restructuring  ontological  resources.  Ontology  developers 

restructure ontological resources to be integrated in the ontology network being built. 

Such an ontology restructuring activity can be performed in the following  ways: (1) 

modularizing the ontology in different ontology modules; (2) pruning the branches of 

the  taxonomy  not  considered  necessary;  (3)  extending  the  ontology  including  (in 

width)  new  concepts  and  relations;  and  (4)  specializing  those  branches  that  require 

more granularity and including more specialized domain concepts and relations. 

Scenario  9:  Localizing  ontological  resources.  Ontology  developers  adapt  an 

existing ontology to one or various languages and culture communities, obtaining as a 

result  a  multilingual  ontology.  Once  the  ontology  has  been  conceptualized,  its 

adaptation  to  a  particular  natural  language  different  from  the  language  used  in  the 

conceptualization  can  be  required.  Such  an  adaptation  requires  the  translation  of  all 

ontology  labels  into  one  or  several  natural  languages,  being  these  languages  other 

than the original language of the conceptualization. 

In this section we have included a brief description of the 9 scenarios identified in 

the NeOn Methodology. These scenarios can be combined in different ways, and any 

combination of scenarios should include Scenario 1 because this scenario is made up 

of the core activities that have to be performed in any ontology development. 

It is worth also mentioning that in the framework of the NeOn Methodology there 

are prescriptive  methodological guidelines

13

 for carrying out processes and activities 



involved  in  Scenario  1  (ontology  requirements  specification  and  scheduling), 

Scenario  2,  Scenario  3,  Scenario  7,  Scenario  8  (ontology  modularization),  and 

Scenario 9; and also for ontology evaluation and ontology evolution.  

5   Applying the NeOn Scenarios 

In this section  we briefly present 2 different use cases in  which the NeOn Scenarios 

has been applied: the NeOn Invoicing Management case and the SEEMP case. 

The  ontology  network  for  the  NeOn  invoicing  management  use  case

14

,  which 



contains  all  the  concepts  related  to  the  invoice  management  in  the  pharmaceutical 

industry, was built following Scenarios 1, 2, 3, 8, and 9. Ontology developers reused 

different non-ontological resources for electronic invoicing (e.g., Universal Business 

Language (UBL), EDIFACT, xCBL) as part of Scenario 2. A generic description of 

concepts  from  SUMO,  DOLCE,  and  W3C  Time  ontologies  were  reused  as  part  of 

Scenario  3.  The  general  invoice  ontology  was  specialized  for  each  laboratory 

involved in the use case as part of Scenario 8. Regarding Scenario 9, ontology users 

belong to different regions in Spain in which different languages are used. 

                                                           

12

 



http://ontologydesignpatterns.org 

13

 



Deliverables D5.4.1, D5.3.2, and D5.4.2 (http://www.neon-project.org/) 

14

 



Deliverable D8.3.1 (http://www.neon-project.org/) 


The ontology network for the SEEMP use case should represent knowledge about 

Curricula Vitae and job offers among Employment Services (ES) placed in different 

countries.  Such  a  network  is  formed  by  (1)  a  set  of  local  ontology  networks, 

representing  each  of  them  the  local  and  particular  view  that  each  ES  has  of  the 

employment market, and (2) a reference ontology network representing a standardized 

and  agreed  view  of  the  employment  market  at  the  European  level.  The  SEEMP 

ontology is a network of ontology networks that was built following Scenarios 1, 2, 4 

and  5.  To  build  the  local  and  the  reference  ontology  networks,  several  NORs 

(international  standards  such  as  NACE  and  ISCO-88;  ES  classifications;  and 

international  codes  such  as  ISO  3166)  were  reused  and  re-engineered  as  part  of 

Scenario  2.  The  DAML  time  ontology  was  reused  and  re-engineered  as  part  of 

Scenario 4. Finally, as part of Scenario 5, a set of alignments  were defined between 

each local ontology and the reference ontology in order to create the SEEMP network.   

6   Conclusion 

In  this  paper,  we  have  presented  the  NeOn  Methodology  for  building  ontology 



networks

,  a  scenario-based  methodology,  covering  the  drawbacks  presented  in  the 

three aforementioned methodologies and benefiting from their advantages. This paper 

supposes  a  step  forward  since  it  identifies  a  set  of  9  flexible  scenarios  for  building 

ontologies and ontology  networks. The scenarios proposed are flexible because they 

can be  combined among them, almost the contrary to  the rigid scenario encountered 

for  building  ontologies  from  scratch  and  presented  in  METHONTOLOGY,  On-To-

Knowledge and DILIGENT. Additionally, this paper shows how such scenarios have 

been followed in different use cases within European projects.  

 

Acknowledgments. This work was supported by the NeOn project (FP6-027595).  



References 

1.

  Fernández-López, M., Gómez-Pérez, A., Pazos A., Pazos J. Building a Chemical Ontology 



Using Methontology and the Ontology Design Environment. IEEE Intelligent Systems & 

their applications 4(1):37–46. 1999. 

2.

  Gómez-Pérez,  A.,  Manzano-Macho,  D.  An overview  of  methods  and  tools  for ontology 



learning from texts, Knowl. Eng. Rev. 19 (3) (2004). 187–212. 

3.

  Paradela,  L.:  PhD  Thesis:  Una  Metodología  para  la  Gestión  del  Conocimiento.  Spain. 



Universidad Politécnica de Madrid, 2001. 

4.

  Pinto, H. S., Tempich, C., Staab, S.: DILIGENT: Towards a fine-grained methodology for 



DIstributed, Loosely-controlled and evolvInG Engineering of oNTologies. 16th European 

Conference on Artificial Intelligence (ECAI 2004), pp. 393--397.  

5.

  Staab, S., Schnurr, H.P., Studer, R., Sure, Y.: Knowledge Processes and Ontologies. IEEE 



Intelligent Systems 16(1):26–34. (2001). 

6.

  Suárez-Figueroa,  M.  C.,  Gómez-Pérez,  A.:  Towards  a  Glossary  of  Activities  in  the 



Ontology Engineering Field. 6th Language Resources and Evaluation Conference (LREC 

2008). Marrakech (Morocco). 



Yüklə 89,71 Kb.

Dostları ilə paylaş:




Verilənlər bazası müəlliflik hüququ ilə müdafiə olunur ©www.genderi.org 2024
rəhbərliyinə müraciət

    Ana səhifə