|
||||
|
The most fundamental syntax concept is the concept of names. Names are used in three different ways:
An element name uniquely identifies a knowledge element, of which there are seven classes:
NL-names are used in the NL-format (natural language format). KB-names are used in PR-format or internal format. Variable names are used in all formats. NL-names are always associated with a KB-name, and vice versa, almost all KB-names are associated with one or more NL-names (the association can be one-to-many because of different syntactic forms in the NL-format and because of synonyms). |
||||
|
There are few restrictions on NL-names which can consist of several words and also include digits and special characters such as hyphens, parenthesis etc. NL-names are case-sensitive. However, you are strongly recommended to observe the following restrictions:
USE GOOD NAMES! Technically speaking there is no inherent knowledge associated with a name in Pro/3. This is radically different from knowledge communicated in true natural language - natural language is intimately intertwined with knowledge and reasoning. For this reason, it is important to use names in Pro/3 which are as intuitive as possible. It is usually easy to find good intuitive names for data element types and entity types. These objects usually correspond to nouns. Predicate types Predicate types, which typically correspond to verbs, are harder to name with consistent style. Textbook cases would be generic names such as "exists", "is known" and "has". It is usually a good idea to use a wider variety, however no specific guidelines can easily be given. It is important to note that knowledge in knowledge base is physically organized according to the predicate type (in sentences and sentence rule conclusions). Different predicate types are stored in different chains (see knowledge base internals for details). Of importance is also the restrictions against recursive rules, which could become a problems with a very limited set of predicate types (see recursive rules). Inexact rules Inexact rule naming should not impose much problems, although it is of course often difficult to find a name which is not too long and at the same gives a reasonably good idea of what the rule stands for. Inexact rule evaluation is an important process in Pro/3 applications, and it is a good idea to use names which aid this process e.g. make names which are meaningful in the certainty rule reasoning drawings (name in red - formal parameter in green): bike is fuel efficient with grade 0.35 (from 0.7) given model name "XRV750 Africa Twin" Functions Functions are generally easy to name. Names should have in mind the syntax for calling functions i.e. such that the function call spells out (as much as possible) the meaning of the function (name in red - formal parameter in green): what = month name given month number 12? |
||||
| KB-names | ||||
|
KB-names are single-word names built from letters, digits and underscores. KB-names are case-sensitive. The syntax is: <lower_case_letter>+ { <letter> | <digit> | _ }* Note the following restrictions:
|
||||
| Variable names | ||||
|
Variable-names are
single-word names built from letters, digits and underscores. Variable-names
are case-sensitive. The syntax is: The following variable names are reserved for Pro/3-generated variables:
1 The first letter is always in upper case.
Variables occur both in NL- and PR-formats. It will be seen from the above syntaxes that this can lead to ambiguities in the NL-format, i.e. variable-names can be confused with NL-names. This is in most cases resolved by the parsing and syntax analysis process, such that any word or sequence or word which can be parsed as a NL-name will be interpreted as such, as long as the syntax analysis in total succeeds. The word will otherwise be interpreted as a variable. To avoid potential problems in this area, it is recommended as much as possible to avoid NL-names starting with upper case letters.
|