A system for collaborative ontology development process. Given a repository with an owl file, OnToology will survey it and produce diagrams, a complete documentation and validation based on common pitfalls. It also offers seamless publication of user ontologies with w3id using GitHub pages.

You can find a live version of OnToology online: http://ontoology.linkeddata.es.

Team: Ahmad Alobaid, Daniel Garijo, Maria Poveda, Idafen Santa, Alba Fernandez Izquierdo, Oscar Corcho

License: Apache License v2

If you want to cite Ontoology in a scientific paper or technical report, you can use the following Bibtex citation or directly this text: Alobaid A, Garijo D, Poveda-Villalón M, Santana-Pérez I, Fernández-Izquierdo A, Corcho O (2019) Automating ontology engineering support activities with OnToology. Journal of Web Semantics 57:100472, https://doi.org/10.1016/j.websem.2018.09.003

The development of OnToology has been supported by the Spanish national project Datos 4.0 (TIN2016-78011-C4-4-R)

Here is a list of tools being used by OnToology.

• owl2jsonld ( zenodo )
• Widoco ( zenodo )
• OOPS!
• AR2DTool
• oops-report
• Themis

If you are an ontology engineer willing to use OnToology, you can check our step by step documentation. You can also check our list of Frequently Asked Questions

We provide some documentation for developers who want to contribute to the development OnToology or for those who are interested in deploying OnToology locally or in their servers. Feel free to contact us if you are interested in contributing to the project.

There are two kinds of tests:

1. Using mock. These kinds of tests use a list of stored requests expected from GitHub APIs. These are fast and do not need GitHub keys or setup.
2. Using real GitHub repos. These kinds of tests uses GitHub APIs. These tests can take some time and need special keys to access relevant test repos. For this reason, these are not available for the public. However, they are executed automatically after each merge to the main branch.

This is only available for certain people

1. Copy the keys into the folder ssh
2. Create a file scripts/secret_setup.sh
3. Write the following and fill the missing values (currently the private app is not added in the tests, so it can be left empty). (see secret setup section below).
4. Run the tests on docker

sh scripts/run_docker_tests.sh

Note: If you made changes, you might need to rebuild the image docker-compose build

#!/bin/sh
export github_password=""
export github_email=""
export client_id_login=""
export client_id_public=""
export client_id_private=""
export client_secret_login=""
export client_secret_public=""
export client_secret_private=""
export test_user_token=""
export test_user_email=""
export github_username=""

1. Setup (see Run Tests on Real GitHub Repo section here)
2. Run the following: sh scripts/run_docker.sh
3. Go to 127.0.0.1:8000 and start using OnToology.

1. Clone the repo.
2. Set up the variables in OnToology/localwsgi.py (see above for the details).
3. Create virtual env (optional).
4. Install dependencies using pip (pip install -r requirements).
5. Run the stiqueue server (with the ip and port).
6. Run OnToology/sqclient.py.

Sometimes things happens and the processes or the APIs fail. Here are the common ones and how to resolve them.

1. Access permissions on the server. OnToology generates the resources, which are automatically has different permissions (probably www-data) rather than the user itself. So, make sure that the apache user has the permission to do so.
2. GitHub permissions. When users add their repo to OnToology, the proper permissions will be added. There are two:
   1. OnToology access.
   2. OnToologyUser as a collaborator. In this case, the last thing that will be shown in the user log will be new htaccess: (if the repo didn't has any ontology published before. If the repo has published an ontology before, you will see that OnToology tried several times to publish, but failed).

docker-compose up
docker ps
docker exec -it <container name> /bin/sh