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 domains are stored in a Google
Spreadsheet . 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.
- OnToology will generate the documentation, the diagrams and
the evaluation of the ontology.
Structure of the GitHub repository
The tool selected to store the ontology is GitHub. Each module in DELTA ontology 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 is stored.
- All the resources generated by OnToology: diagrams, documentation of the ontology and evaluation report. The
next image shows the structure of the folders generated by OnToology for each ontology.
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. OnToology will evaluate the
ontology using
Oops! and generate an evaluation report every time there is
a push in the repository. The ontology developers also have to guarantee that the ontology meets all the
requirements identified.
Ontology Documentation
OnToology will generate the documentation using
Widoco every time
there is a push in the repository. 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.
OnToology will also generate the diagrams using
AR2DTool. It
will generate two kinds of diagrams:
- Class diagram
- Taxonomy diagram
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.
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 .