How We Work

This document provides a brief overview of our process for developing ontologies. It contains a minimal amount of technical detail sufficient to explain our approach to ontology development.

Overview

Each ontology is going to be stored in a GitHub repository.
Improvements and issues for each domain are discussed in the repository's GitHub issue tracker.
The requirements of each module are stored in the requirements folder as Excel sheets. When a developer generates a release version of a domain, the spreadsheet is converted to HTML and added to the repository.
The ontology developers have to evaluate the ontology and generate its documentation before publishing it.
The releases versions of the domains are published in the site.
Oops!, Foops! and OnToology will generate the evaluation, and the documentation of the ontology respectively.

Structure of the GitHub repository

The tool selected to store the ontology is GitHub. Each extension of the Conceptual Mapping will be stored in a repository. Each repository will include:

A folder where the implementation of the ontology is stored.
A folder where the ontology model (conceptualization) is stored.
A folder with the documentation of the ontology in HTML.
A folder with examples of the ontology.
A forlder with the ontology requirements.

GitHub Flow

For developing an ontology using GitHub we propose to follow some steps:

The central repository holds a main branch called master where the source code reflects the production-ready state.To work on something new, the ontology developers have to create a descriptively named branch off the master, so that the rest of the developers can see what is being worked on.
Once the branch is created, the developers add changes to the ontology and commit them. Each commit has to be associated with a commit message, which is a description explaining why a particular change was made, so that the developers can roll back changes if a bug is found.
After adding commits, the ontology developers have to open a pull request to discuss the modifications done to the ontology. After creating the pull request, some tests are executed to check if the ontology meets all the requirements identified.
If everyone agree and the ontology pass the tests the pull request is accepted and the changes are merged to the master branch.
When the developers want to publish a version of the ontology on the Web they have to create a pre-release version of it.

Development process

Once the ontology is implemented (for this step the developers can use an ontology editor like Protégé), it has to be evaluated and documented before its publication.

Ontology Evaluation

The ontology has to be evaluated according to syntactic, model and semantic errors. The developer will evaluate the ontology using Oops! and Foops!, which generates an evaluation report of the model. The ontology developers also have to guarantee that the ontology meets all the requirements identified.

Ontology Documentation

The developer will generate the documentation using Widoco every time there is a new version of the model. This documentation includes an HTML description of the ontology which describes the classes, properties and data properties of the ontology, and the license URI and title being used. The ontology development team in collaboration with the domain experts can complete this HTML documentation.

Ontology Versioning and change control

The ontologies are developed incrementally. For each ontology we may have several releases, which are stored in the GitHub repositories. Each release has a name that is assigned upon publication(e.g. v0.0.1). The content of each release is based on the discussions with the domain experts and the discussions hosted on the GitHub site.

Ontology Publication

Releases are published in the official site by the project webmaster, so the ontology and its documentation will be accessible to all the users. The site will publish additionally for each ontology the repositiory where is stored, its issue tracker, the releases created and the requirements associated to each ontology. The diagrams generated represent the ontology conceptualization, and follow the Chowlk notation.

Ontology Maintenance

If the ontology developers or domain experts want to update or add new requirements to the ontology they have to create a new issue in the GitHub issue tracker. This issue will let the developers to start a discussion and accept or regret the modifications. GitHub also provide a good practices guide for creating issues.