Hands-On Session: Collaborative and modular ontology development
Now it is time to try out a collaborative ontology engineering project. Together with your fellow tutorial participants you will try to construct an overall ontology. Preferably you should work in pairs, but it is also fine if you want to work alone. You will apply a "light version" of the XD methodology, where you go through the following steps:
- Select a story
- Elicit requirements
- Agree on the set of requirements with the teacher before proceeding
- Model the module using OWL
- Test module against your requirements
- Document everything in the google doc belonging to the story
- Send module OWL file (for instance in turtle format) to the teacher
- If there are other modules ready to be integrated, you might get assigned to do an integration, otherwise pick the next unassigned story and start the process with that story
Below you find a description of the imagined project context, as well as a list of stories that we imagine have been collected from some domain expert/"customer". Each story is described in terms of a title stating its main focus, the story text itself, a priority of the story (high, medium, low), and a number of related stories. Each story below comes in its own google doc, for you to be able to easily document your work and share it with the others that may be assigned to take over and integrate your module into the final ontology. As soon an you get assigned, or choose, a story, add your names by the heading "Story assigned to:" so that others can see the story is already taken, and change the status of the story to "being modelled". Once you release your module, i.e. send the file to the teacher and move to a new story/taks, then also change the status back to "none" again. If you get assigned a story for integration, do not change the names at the top (this is for the original developer names, we want to keep that trace) instead use the section at the bottom of each google doc for the integration documentation. But do change the status to "being integrated" so that others know the story is being treated.
When you are working on a story, try to focus only on that story. In principle you should ignore anything that is not explicitly mentioned in the story text. However, you do have a note with "related stories" in each document. So you may want to have a quick chat with the ontology engineers modelling those stories (if they have been started), just to check if you are thinking in completely different ways. But it is important NOT to get stuck in discussions, so just make a quick check, then go back and do your own thing. Do not mind if there are overlaps between modules, this should be managed in the integration step.
Testing of your modules can be done in two main ways: either using SPARQL queries, or using a reasoner. Which way you choose depends on what requirement you are trying to test. For both these cases you probably first want to add some test instances. Either you do this by importing your module into a new empty ontology, which will contain your test data, or you just add some test data directly into your ontology, which you then delete before releasing the module. To ask SPARQL queries in Protege you need to add a specific plugin for this (use the "check for plugins" option in the file menu, and once you added a plugin mark it in the Window -> Tabs menu). For reasoning you can use the HermiT reasoner that is shipped with Protege, or add another one. For this exercise, do not spend too much time on the testing part. Just try out a few queries if you can manage to get the SPARQL plugin to run. This is not the main focus here, and it does not matter so much if your module is not 100% correct.
If you want to look at some ODPs when you start to model, feel free to browse the list of submitted content ODPs at ontologydesignpatterns.org. However, this is not the main focus of the exercise, and you are not required to study ODPs, nor to reuse their OWL files. Nevertheless, here is a list of a few ODPs that may be interesting to look at in case you want some inspiration:
LinkÃ¶ping University is one of the larger universities in Sweden. The university now wants to build a semantic data management system for expert finding, competence and project management. For this an ontology is to be built in order to structure and reason over data related to researchers, research topics, projects, and other activities of researchers at the university.
StoriesStories are listed in order of priority, hence the stories with the lowest numbers have high priority, and so on. When you pick a new story, pick the one with the lowest number that is not already assigned to a pair.
- Story 1
- Story 2
- Story 3
- Story 4
- Story 5
- Story 6
- Story 7
- Story 8
- Story 9
- Story 10
- Story 11
- Story 12
- Story 13
- Story 14
Page responsible: Olaf Hartig
Last updated: 2018-03-14