Difference between revisions of "PrF UG intro planning a project"

From Protege Wiki
Jump to: navigation, search
Line 78: Line 78:
  
 
<div>[[Image:PrF_UG_intro_project_flow.png|frame|none|
 
<div>[[Image:PrF_UG_intro_project_flow.png|frame|none|
       typical project flow for {{#var:PrF}}]]</div>
+
       typical workflow for a {{#var:PrF}}]] project</div>
  
 
At the heart of a successful {{#var:PrF}} project
 
At the heart of a successful {{#var:PrF}} project

Revision as of 12:26, October 31, 2008

Planning a Project


Protege-Frames User's Guide
Intoductory Topics
Using this Guide
What is Protege?
What is Protege-Frames?
Planning a Project
A Newspaper Example
Extending Protege
Glossary, Editing Help

The development of a successful knowledge-based system, built with Protege-Frames, is more of an art than a science. Nonetheless, we can suggest a standard pattern of use that new users should follow to avoid some possible problems of systems development. Protege-Frames is designed to support iterative development, where there are cycles of revision to the ontologies and other components of the knowledge-based system.

Developers should not expect to "complete" ontology development without considering other aspects of the process. In particular, Knowledge Acquisition (KA) is critical to any knowledge-based system. For the development of a successful Protege-Frames project, we would recommend the following steps:

  1. Plan for the application and expected uses of the knowledge base. This usually means working with domain experts that have a set of problems that could be solved with knowledge-base technology.

  2. Build an initial small ontology of classes and slots.

  3. When you have built this ontology (and later, when you have extended it or opened it from a file), you can directly view forms for entering instance knowledge into the ontology, because Protege-Frames generates initial forms "on the fly", in its role as a KA-tool generator.

  4. You use these forms for acquiring slot values of your test instances. At this point, it is usually appropriate to show the ontology and the filled-out instance forms to the domain experts or your expected users. This inevitably leads to a set of revisions, both to the ontology (2.) and to the forms (5.). Note that ontology modifications can be expensive; some changes could necessitate rebuilding some or all of the knowledge base.

  5. Customize the forms to a refined knowledge-acquisition tool, as explained in the Forms strand. While constructing this customized version of the KA-subtool, further design problems in the original ontology may become apparent. If necessary, revise the ontology and repeat at 4.

  6. With your domain experts, build a somewhat larger knowledge-base that can be tested with your application or problem-solving method.

  7. Test the full application with your end-users. This step can lead to further revisions to the ontology and the KA-subtool.

The picture below shows the typical workflow for a Protege-Frames project. The large arrowheads indicate the forward progression through the process, while the small arrowheads show places where revisions are usually necessary (either to the ontology or the knowledge-acquisition tool).

typical workflow for a Protege-Frames
project

At the heart of a successful Protege-Frames project is the design of the class and slot structure of the ontology. In particular, the model you use in building your ontology must balance the needs of the domain expert when building a knowledge base (at knowledge-acquisition time) against the requirements of your problem-solving method or application (at run-time). Hopefully, these are not too contradictory! Ontology developers should therefore both:

  • Model the domain with a set of problems and a problem-solving method in mind.

  • Design the ontology so that it can be used to generate and customize an appropriate KA-tool for a specific set of users.

A simple problem, taken from the Newspaper Example, could be finding all advertisements that are more expensive than some threshold. To handle this problem, one should create an "advertisements" class that includes prices and publication dates. Spreading this information across all publication issues would make it more difficult for the problem-solver to access all instances of advertisements and their prices.