Difference between revisions of "PrF UG intro planning a project"
(Automated import of articles) |
|||
| Line 5: | Line 5: | ||
The development of a successful knowledge-based system, | The development of a successful knowledge-based system, | ||
| − | built with {{#var:PrF}}, | + | built with {{#var:PrF}}, is more of an art than a science. |
| − | is more of an art than a science. | + | Nonetheless, we can suggest a standard pattern of use that new users should follow |
| − | Nonetheless, | + | to avoid some possible problems of systems development. |
| − | we can suggest a standard pattern of use that new users should follow to avoid some possible problems of systems development. {{#var:PrF}} is designed to support ''iterative development'', | + | {{#var:PrF}} is designed to support ''iterative development'', |
| − | where there are cycles of revision to the ontologies and other components of the knowledge-based system. | + | 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. | + | Developers should not expect to "complete" ontology development |
| − | In particular, | + | without considering other aspects of the process. |
| − | Knowledge Acquisition | + | In particular, Knowledge Acquisition (KA) |
| − | (KA) | ||
is critical to any knowledge-based system. | is critical to any knowledge-based system. | ||
For the development of a successful {{#var:PrF}} project, | For the development of a successful {{#var:PrF}} project, | ||
| Line 22: | Line 22: | ||
<li><p> | <li><p> | ||
Plan for the application and expected uses of the knowledge base. | 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. | + | This usually means working with domain experts that have a set of problems |
| + | that could be solved with knowledge-base technology. | ||
</p> | </p> | ||
<li><p> | <li><p> | ||
| − | Build an initial small ontology of | + | Build an initial small ontology of [[PrF_UG_classes|classes]] |
| − | + | and [[PrF_UG_slots|slots]]. | |
| − | and | ||
| − | |||
</p> | </p> | ||
| Line 35: | Line 34: | ||
When you have built this ontology (and later, | When you have built this ontology (and later, | ||
when you have extended it or opened it from a file), | when you have extended it or opened it from a file), | ||
| − | you can directly view | + | you can directly view [[PrF_UG_forms|forms]] |
| − | |||
for entering instance knowledge into the ontology, | for entering instance knowledge into the ontology, | ||
because {{#var:PrF}} generates initial forms "on the fly", | because {{#var:PrF}} generates initial forms "on the fly", | ||
| Line 43: | Line 41: | ||
<li><p> | <li><p> | ||
| − | You use these forms for acquiring slot values of your test | + | You use these forms for acquiring slot values |
| − | + | of your test [[PrF_UG_inst|instances]]. | |
| − | At this point, | + | 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, | This inevitably leads to a set of revisions, | ||
both to the ontology (2.) and to the forms (5.). | both to the ontology (2.) and to the forms (5.). | ||
| Line 55: | Line 54: | ||
<li><p> | <li><p> | ||
Customize the forms to a refined knowledge-acquisition tool, | Customize the forms to a refined knowledge-acquisition tool, | ||
| − | as explained in the | + | as explained in the [[PrF_UG_forms_understanding_forms|Forms]] strand. |
| − | |||
| − | |||
While constructing this customized version of the KA-subtool, | While constructing this customized version of the KA-subtool, | ||
further design problems in the original ontology may become apparent. | further design problems in the original ontology may become apparent. | ||
| − | If necessary, | + | If necessary, revise the ontology and repeat at 4. |
| − | |||
</p> | </p> | ||
<li><p> | <li><p> | ||
With your domain experts, | With your domain experts, | ||
| − | build a somewhat larger knowledge-base that can be tested with your application or problem-solving method. | + | build a somewhat larger knowledge-base |
| + | that can be tested with your application or problem-solving method. | ||
</p> | </p> | ||
| Line 77: | Line 74: | ||
The picture below shows this typical pattern of use for the {{#var:PrF}} subsystems. | The picture below shows this typical pattern of use for the {{#var:PrF}} subsystems. | ||
The black arrows indicate the forward progression through the process, | The black arrows indicate the forward progression through the process, | ||
| − | while the blue dotted arrows show places where revisions are usually necessary (either to the ontology or the knowledge-acquisition tool). | + | while the blue dotted arrows show places where revisions are usually necessary |
| + | (either to the ontology or the knowledge-acquisition tool). | ||
<div>[[Image:PrF_UG_all_process.gif|all_process]]</div> | <div>[[Image:PrF_UG_all_process.gif|all_process]]</div> | ||
| − | At the heart of a successful {{#var:PrF}} project is the design of the class and slot structure of the ontology. | + | At the heart of a successful {{#var:PrF}} project |
| − | In particular, | + | is the design of the class and slot structure of the ontology. |
| − | the model you use in building your ontology must balance the needs of the domain expert when building a knowledge base | + | 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) | (at knowledge-acquisition time) | ||
against the requirements of your problem-solving method or application (at run-time). | against the requirements of your problem-solving method or application (at run-time). | ||
| − | Hopefully, | + | Hopefully, these are not too contradictory! |
| − | these are not too contradictory! Ontology developers should therefore both: | + | Ontology developers should therefore both: |
<ul class='a'> | <ul class='a'> | ||
| Line 95: | Line 94: | ||
<li><p> | <li><p> | ||
| − | Design the ontology so that it can be used to generate and customize an appropriate KA-tool for a specific set of users. | + | Design the ontology so that it can be used |
| + | to generate and customize an appropriate KA-tool for a specific set of users. | ||
</p> | </p> | ||
</ul> | </ul> | ||
A simple problem, | A simple problem, | ||
| − | taken from the | + | taken from the [[PrF_UG_intro_newspaper_example|Newspaper Example]], |
| − | [[PrF_UG_intro_newspaper_example|Newspaper Example]], | ||
could be finding all advertisements that are more expensive than some threshold. | could be finding all advertisements that are more expensive than some threshold. | ||
To handle this problem, | To handle this problem, | ||
one should create an "advertisements" class that includes prices and publication dates. | 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. | + | 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. | ||
</div> | </div> | ||
Revision as of 00:06, October 16, 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:
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.
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.
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.
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.
With your domain experts, build a somewhat larger knowledge-base that can be tested with your application or problem-solving method.
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 this typical pattern of use for the Protege-Frames subsystems. The black arrows indicate the forward progression through the process, while the blue dotted arrows show places where revisions are usually necessary (either to the ontology or the knowledge-acquisition tool).
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.
