Evaluation of SEON Ontology

[pedropaulofb]

Problems to be solved

The SEON ontology was divided and treated by different collaborators, which can result in duplicated, inconsistent, or incomplete data. Definitions must be done in order to solve these possible problems:

1. We need to define the best strategy for addressing this ontology. Must SEON be treated as a single ontology with multiple diagrams? Or SEON is just the composition of multiple individual ontologies (just like we're doing now)? This can be decided together with @fabianoruy, the main author of SEON.
   1.1) There is a paper describing GORO 2.0 and this can be taken into consideration for a decision. Check issue Evaluate approach for GORO ontology and start development #196.

2. We can already identify inconsistencies in the ontologies' metadata. One of them is their development year. We must verify all fields so they can be consistent.

3. As the ontologies extend UFO and also use OntoUML, should their ontologies' have both UFO and OntoUML in the metadata's conformsTo field?

General information

According to its website, the SEON Network is composed of the following networked ontologies:

Core Layer

• SPO - Software Process Ontology
• COM - Core Ontology on Measurement (external)
• EO - Enterprise Ontology (external)

Domain Layer

• SwO - Software Ontology
• ReqON - Requirements engineering Ontology subNetwork
  • RSRO - Reference Software Requirements Ontology
  • RRO - Runtime Requirements Ontology
  • GORO - Goal-Oriented Requirements Ontology
  • RDPO - Requirements Development Process Ontology
• DPO - Design Process Ontology
• CPO - Coding Process Ontology
• ROoST - Reference Ontology on Software Testing
• QAPO - Quality Assurance Process Ontology
• SPMO - Software Project Management Ontology
• CMPO - Configuration Management Process Ontology
• RSMO - Reference Software Measurement Ontology

By this moment, we have in the catalog:

• SPO
• SWO
• DPO
• SPMO
• CMPO
• QAPO - Quality Assurance Process Ontology

Consequently, the missing ontologies are:

• COM - Core Ontology on Measurement (external)
• EO - Enterprise Ontology (external)
• RSRO - Reference Software Requirements Ontology
• RRO - Runtime Requirements Ontology
• GORO - Goal-Oriented Requirements Ontology
• RDPO - Requirements Development Process Ontology
• CPO - Coding Process Ontology
• ROoST - Reference Ontology on Software Testing
• RSMO - Reference Software Measurement Ontology

[pedropaulofb]

It is important to mention that the SEON author already authorized it to be included into the catalog and also defined its license as CC BY 4.0.

[pedropaulofb]

After a meeting with Fabiano Ruy, we came to the following decisions:

1. We need to define the best strategy for addressing this ontology. Must SEON be treated as a single ontology with multiple diagrams? Or SEON is just the composition of multiple individual ontologies (just like we're doing now)? This can be decided together with @fabianoruy, the main author of SEON.

The ontologies are part of a network and have independent life cycles, hence they must be here represented in different datasets.

2. We can already identify inconsistencies in the ontologies' metadata. One of them is their development year. We must verify all fields so they can be consistent.
3. As the ontologies extend UFO and also use OntoUML, should their ontologies' have both UFO and OntoUML in the metadata's conformsTo field?`

Fabiano is going to check the metadata of all SEON ontologies already available. Issue #198 opened for this purpose.