Protégé in a DTAP environment
Posted: 06 Jan 2011, 13:03
Hi,
I'm struggling to set up a Development-Test-Acceptance-Production scheme for a Protégé knowledgebase, much like this is done in development projects.
The idea is the following:
- A collaborator makes changes to the knowledgebase (model & data) in the Dev environment. The Dev environment can be a locally hosted copy of Protégé and the model.
- Once these changes are tested (and possibly approved in some way) in the Test environment, they can be moved to the Acceptance environment.
- The acceptance environment can be accessed by multiple people and is used as pre-production stage.
- Once approved in acceptance, the changes are pushed to production.
Some ways to tackle the above scheme:
- Dev en Test are locally stored copies of the model. Every collaborator has his own copy to work on. This copy can easily be restored to the original situation. Restoring it to the latest production state is harder (see further).
- Acceptance and Production are two completely separate database instances, possibly (but not necessarily) hosted on different Protégé servers.
- By requiring that modifications to the model are scripted using Python, these changes can nicely be propagated from one environment to the next.
From a model point of view, this means that one can easily start from a baseline configuration by
1) loading the essential_baseline project
2) applying the model changes by executing the correct scripts in the right order
What I'm still missing, is a flexible mechanism to move the data from one environment to the next. This is relevant in two directions: from development to production in order to push updates, but also the reverse direction in order to start testing on the latest and most accurate version of the data in production.
There are some things I've tried:
- Importing all instances by script at all times. This, however, turns out to be impractical
- Exporting all data in some way, and importing it in the target project. This turns out to become impractical too.
- Using the 'Prompt' plugin in order to copy/move frames between ontologies. This seems to work for a relatively simple list of instances, but yields unexpected results when applied to a larger and more complex set of instances.
- By exporting a project and using this as the basis of a 'new' project. This practically means removing the complete production database in order to proceed from acceptance to production.
Are there other ways to tackle the same issue/situation? How do other users handle the systematic development of the architecture documentation?
Thanks!
Toni
I'm struggling to set up a Development-Test-Acceptance-Production scheme for a Protégé knowledgebase, much like this is done in development projects.
The idea is the following:
- A collaborator makes changes to the knowledgebase (model & data) in the Dev environment. The Dev environment can be a locally hosted copy of Protégé and the model.
- Once these changes are tested (and possibly approved in some way) in the Test environment, they can be moved to the Acceptance environment.
- The acceptance environment can be accessed by multiple people and is used as pre-production stage.
- Once approved in acceptance, the changes are pushed to production.
Some ways to tackle the above scheme:
- Dev en Test are locally stored copies of the model. Every collaborator has his own copy to work on. This copy can easily be restored to the original situation. Restoring it to the latest production state is harder (see further).
- Acceptance and Production are two completely separate database instances, possibly (but not necessarily) hosted on different Protégé servers.
- By requiring that modifications to the model are scripted using Python, these changes can nicely be propagated from one environment to the next.
From a model point of view, this means that one can easily start from a baseline configuration by
1) loading the essential_baseline project
2) applying the model changes by executing the correct scripts in the right order
What I'm still missing, is a flexible mechanism to move the data from one environment to the next. This is relevant in two directions: from development to production in order to push updates, but also the reverse direction in order to start testing on the latest and most accurate version of the data in production.
There are some things I've tried:
- Importing all instances by script at all times. This, however, turns out to be impractical
- Exporting all data in some way, and importing it in the target project. This turns out to become impractical too.
- Using the 'Prompt' plugin in order to copy/move frames between ontologies. This seems to work for a relatively simple list of instances, but yields unexpected results when applied to a larger and more complex set of instances.
- By exporting a project and using this as the basis of a 'new' project. This practically means removing the complete production database in order to proceed from acceptance to production.
Are there other ways to tackle the same issue/situation? How do other users handle the systematic development of the architecture documentation?
Thanks!
Toni