PrF UG intro planning a project - Revision history

RichMorin at 01:19, November 14, 2008

2008-11-14T01:19:51Z

RichMorin at 19:26, October 31, 2008

2008-10-31T19:26:36Z

RichMorin at 19:26, October 31, 2008

2008-10-31T19:26:08Z

RichMorin at 19:25, October 31, 2008

2008-10-31T19:25:31Z

RichMorin at 19:18, October 31, 2008

2008-10-31T19:18:12Z

RichMorin at 19:17, October 31, 2008

2008-10-31T19:17:09Z

RichMorin at 00:20, October 23, 2008

2008-10-23T00:20:42Z

RichMorin at 08:06, October 16, 2008

2008-10-16T08:06:27Z

RichMorin: Automated import of articles

2008-10-09T09:00:25Z

Automated import of articles

New page

__NOTOC__
== Planning a {{#var:PrF}} Project ==

{{PrF_UG_TOC_intro}}<div id='prf_ug'>

The development of a successful knowledge-based system,
built with {{#var:PrF}},
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. {{#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.

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 {{#var:PrF}} project,
we would recommend the following steps:

<ol class='a'>
<li><p>
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.
</p>

<li><p>
Build an initial small ontology of
[[PrF_UG_classes|classes]]
and
[[PrF_UG_slots|slots]].
</p>

<li><p>
When you have built this ontology (and later,
when you have extended it or opened it from a file),
you can directly view
[[PrF_UG_forms|forms]]
for entering instance knowledge into the ontology,
because {{#var:PrF}} generates initial forms "on the fly",
in its role as a KA-tool generator.
</p>

<li><p>
You use these forms for acquiring slot values of your test
[[PrF_UG_inst|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.
</p>

<li><p>
Customize the forms to a refined knowledge-acquisition tool,
as explained in the
[[PrF_UG_forms_understanding_forms|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.
</p>

<li><p>
With your domain experts,
build a somewhat larger knowledge-base that can be tested with your application or problem-solving method.
</p>

<li><p>
Test the full application with your end-users.
This step can lead to further revisions to the ontology and the KA-subtool.
</p>
</ol>

The picture below shows this typical pattern of use for the {{#var:PrF}} 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).

<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.
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:

<ul class='a'>
<li><p>
Model the domain with a set of problems and a problem-solving method in mind.
</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.
</p>
</ul>

A simple problem,
taken from the
[[PrF_UG_intro_newspaper_example|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.

</div>

@@ Line 2: / Line 2: @@
 == Planning a {{#var:PrF}} Project ==
-{{PrF_UG_TOC_intro}}<div id='prf_ug'>
+<noinclude>{{PrF_UG_TOC_intro}}<div id='prf_ug'></noinclude>
 The development of a successful knowledge-based system,
@@ Line 110: / Line 110: @@
-</div>
+<noinclude></div></noinclude>

@@ Line 78: / Line 78: @@
 <div>[[Image:PrF_UG_intro_project_flow.png|frame|none|
-        typical workflow for a {{#var:PrF}}]] project</div>
+        typical workflow for a {{#var:PrF}} project]]</div>
 At the heart of a successful {{#var:PrF}} project

@@ Line 78: / Line 78: @@
 <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

@@ Line 72: / Line 72: @@
 </ol>
-The picture below shows this typical pattern of use for the {{#var:PrF}} subsystems.
+The picture below shows the typical workflow for a {{#var:PrF}} project.
-The black arrows indicate the forward progression through the process,
+The large arrowheads indicate the forward progression through the process,
-while the blue dotted arrows show places where revisions are usually necessary
+while the small arrowheads show places where revisions are usually necessary
 (either to the ontology or the knowledge-acquisition tool).
 <div>[[Image:PrF_UG_intro_project_flow.png|frame|none|

@@ Line 80: / Line 80: @@
         typical use pattern for {{#var:PrF}}]]</div>
-<div>[[Image:PrF_UG_project_flow.png|frame|none|
+<div>[[Image:PrF_UG_intro_project_flow.png|frame|none|
         typical project flow for {{#var:PrF}}]]</div>

@@ Line 77: / Line 77: @@
 (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|frame|none|
 At the heart of a successful {{#var:PrF}} project
@@ Line 107: / Line 108: @@
 would make it more difficult for the problem-solver
 to access all instances of advertisements and their prices.
 </div>

@@ Line 5: / Line 5: @@
 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
-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)
 is critical to any knowledge-based system.
 For the development of a successful {{#var:PrF}} project,
@@ Line 22: / Line 22: @@
    <li><p>
      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
      </p>
    <li><p>
-     Build an initial small ontology of
+     Build an initial small ontology of [[PrF_UG_classes|classes]]
-    [[PrF_UG_classes|classes]]
+     and [[PrF_UG_slots|slots]].
      </p>
@@ Line 35: / Line 34: @@
      When you have built this ontology (and later,
      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,
      because {{#var:PrF}} generates initial forms "on the fly",
@@ Line 43: / Line 41: @@
    <li><p>
-     You use these forms for acquiring slot values of your test
+     You use these forms for acquiring slot values
-    [[PrF_UG_inst|instances]].
+    of your test [[PrF_UG_inst|instances]].
-     At this point,
+     At this point, it is usually appropriate
-    it is usually appropriate to show the ontology and the filled-out instance forms to the domain experts or your expected users.
+    to show the ontology and the filled-out instance forms
      This inevitably leads to a set of revisions,
      both to the ontology (2.) and to the forms (5.).
@@ Line 55: / Line 54: @@
    <li><p>
      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,
      further design problems in the original ontology may become apparent.
-     If necessary,
+     If necessary, revise the ontology and repeat at 4.
      </p>
    <li><p>
      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
      </p>
@@ Line 77: / Line 74: @@
 The picture below shows this typical pattern of use for the {{#var:PrF}} 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).
+while the blue dotted arrows show places where revisions are usually necessary
 <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
 (at knowledge-acquisition 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'>
@@ Line 95: / Line 94: @@
    <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
      </p>
 </ul>
 A simple problem,
-taken from the
+taken from the [[PrF_UG_intro_newspaper_example|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.
+Spreading this information across all publication issues
 </div>