You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@nlpcraft.apache.org by ar...@apache.org on 2022/12/06 19:13:27 UTC
[incubator-nlpcraft-website] branch NLPCRAFT-513-intents updated: Update intent-matching.html
This is an automated email from the ASF dual-hosted git repository.
aradzinski pushed a commit to branch NLPCRAFT-513-intents
in repository https://gitbox.apache.org/repos/asf/incubator-nlpcraft-website.git
The following commit(s) were added to refs/heads/NLPCRAFT-513-intents by this push:
new 7a41ee7 Update intent-matching.html
7a41ee7 is described below
commit 7a41ee75690a83b2ab161250e6ffac0148cde26d
Author: Aaron Radzinski <ar...@datalingvo.com>
AuthorDate: Tue Dec 6 11:13:21 2022 -0800
Update intent-matching.html
---
intent-matching.html | 25 ++++++++++++-------------
1 file changed, 12 insertions(+), 13 deletions(-)
diff --git a/intent-matching.html b/intent-matching.html
index 50b5bbd..414e671 100644
--- a/intent-matching.html
+++ b/intent-matching.html
@@ -25,16 +25,17 @@ id: intent_matching
<section>
<h2 class="section-title">Overview <a href="#"><i class="top-link fas fa-fw fa-angle-double-up"></i></a></h2>
<p>
- {% scaladoc NCModel NCModel %} processing logic is defined as a collection of one or more intents. The sections
+ {% scaladoc NCModel NCModel %} processing logic is defined as a <a href="/pipeline-components.html">pipeline</a> and the
+ collection of one or more intents to be matched on. The sections
below explain what intent is, how to define it in your model, and how it works.
</p>
</section>
<section id="intent">
<h2 class="section-title">Intent <a href="#"><i class="top-link fas fa-fw fa-angle-double-up"></i></a></h2>
<p>
- The goal of the data model implementation is to take the user input text and
- match it to a specific user-defined code that will execute for that input. The mechanism that
- provides this matching is called an <em>intent</em>.
+ The goal of the data model implementation is to take the user input text, pass it through processing
+ <a href="/pipeline-components.html">pipeline</a> and match the resulting variants to a specific user-defined
+ code that will execute for that input. The mechanism that provides this matching is called an <em>intent</em>.
</p>
<p>
The intent generally refers to the goal that the end-user had in mind when speaking or typing the input utterance.
@@ -62,13 +63,14 @@ id: intent_matching
here's a simple intent <code>x</code> with two terms <code>a</code> and <code>b</code>:
</p>
<pre class="brush: idl">
+ /* Intent 'x' definition. */
intent=x
- term(a)~{# == 'my_elm'}
- term(b)={has(ent_groups, "my_group")}
+ term(a)~{# == 'my_elm'} // Term 'a'.
+ term(b)={has(ent_groups, "my_group")} // Term 'b'.
</pre>
<p>
IDL intent defines a match between the parsed user input represented as the collection of
- {% scaladoc NCEntity entities %},
+ {% scaladoc2 NCEntity entities %},
and the user-define callback method. IDL intents are <a href="#binding">bound</a> to their callbacks via
<a href="#binding">Java annotation</a> and can be <a href="#idl_location">located</a> in the same Java annotations or
in external <code>*.idl</code> files.
@@ -326,9 +328,6 @@ id: intent_matching
annotation to link term's entities to a formal parameter of the callback method. Note that term ID follows
the same lexical rules as intent ID.
</p>
- <p>
- Term's body can be defined via <b>IDL Expression</b>:
- </p>
<p>
Inside of curly brackets <code>{</code> <code>}</code> you can have an optional list of term variables
and the mandatory term expression that must evaluate to a boolean value. Term variable name must start with
@@ -486,11 +485,11 @@ id: intent_matching
</ul>
<h2 id="intent-lifecycle" class="section-sub-title">Intent Lifecycle <a href="#"><i class="top-link fas fa-fw fa-angle-double-up"></i></a></h2>
<p>
- During {% scaladoc NCModelClient NCModelClient %} start it scans the provided model class for the intents.
+ During {% scaladoc NCModelClient NCModelClient %} initialization it scans the provided model class for the intents.
All found intents are compiled into an internal representation.
</p>
<p>
- Note that not all intents problems can be detected at the compilation phase,
+ Note that not all intent-related problems can be detected at the compilation phase,
and {% scaladoc NCModelClient NCModelClient %} can be initialized with intents
not being completely validated. For example, each term in the intent must evaluate to a boolean result. This can
only be checked at runtime. Another example is the number and the types of parameters passed into IDL function
@@ -499,7 +498,7 @@ id: intent_matching
<p>
Intents are compiled only once during the {% scaladoc NCModelClient NCModelClient %} initialization and
cannot be re-compiled. Model logic, however, can affect the intent behavior through
- {% scaladoc NCModel NCModel %} callback methods and request data all of which can change at runtime and
+ {% scaladoc NCModel NCModel %} callback methods and metadata all of which can change at runtime and
are accessible through <a href="#idl_functions">IDL functions.</a>
</p>
<h2 id="intent-examples" class="section-sub-title">Intent Examples <a href="#"><i class="top-link fas fa-fw fa-angle-double-up"></i></a></h2>