{"id":20,"date":"2018-07-25T09:51:48","date_gmt":"2018-07-25T09:51:48","guid":{"rendered":"http:\/\/dectau.uclm.es\/bousi-prolog\/?p=20"},"modified":"2025-04-10T16:30:48","modified_gmt":"2025-04-10T16:30:48","slug":"language-overview","status":"publish","type":"post","link":"https:\/\/dectau.uclm.es\/bousi-prolog\/2018\/07\/25\/language-overview\/","title":{"rendered":"LANGUAGE OVERVIEW"},"content":{"rendered":"<p>The BPL syntax is mainly the Prolog syntax but enriched with a built-in symbol \u201c~\u201d used for describing proximity relations (actually, fuzzy binary relations which are automatically converted into proximity or similarity relations) by means of what we call a proximity equation. Proximity equations are expressions of the form:<\/p>\n<p style=\"text-align: center\">&lt;symbol&gt; ~ &lt;symbol&gt; = &lt;proximity degree&gt;<span class=\"Apple-converted-space\">\u00a0<\/span><\/p>\n<p>Although, a proximity equation represents an arbitrary fuzzy binary relation, its intuitive reading is that two constants, n-ary function symbols or n-ary predicate symbols are approximate or similar with a certain degree. That is, a proximity equation<\/p>\n<p style=\"text-align: center\">a~b = \u03b1<\/p>\n<p>can be understood in both directions: a is approximate\/similar to b and b is approximate\/similar to a with degree \u03b1. Therefore, a BPL program is a sequence of Prolog facts and rules followed by a sequence of proximity equations.<span class=\"Apple-converted-space\">\u00a0<\/span><\/p>\n<p>Example 1. Suppose a fragment of a database that stores a semantic network with information about people\u2019s names and hair color, as well as the approximate relation between black, brown and blond hair.<span class=\"Apple-converted-space\">\u00a0<\/span><\/p>\n<pre><strong>% BPL directive<span class=\"Apple-converted-space\">\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 <\/span>% FACTS\r\n :- transitivity(no). <span class=\"Apple-converted-space\">\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 <\/span>is_a(john, person).\r\n <span class=\"Apple-converted-space\">\u00a0\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 <\/span>is_a(peter, person).\r\n% SIMILARITY EQUATIONS <span class=\"Apple-converted-space\">\u00a0 \u00a0 \u00a0 \u00a0  <\/span>is_a(mary, person).\r\n <span class=\"Apple-converted-space\">\u00a0<\/span>black~brown=0.6.<span class=\"Apple-converted-space\">\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 <\/span>hair_color(john,black).\r\n <span class=\"Apple-converted-space\">\u00a0<\/span>black~blond=0.3.<span class=\"Apple-converted-space\">\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 <\/span>hair_color(peter,brown).\r\n <span class=\"Apple-converted-space\">\u00a0<\/span>blond~brown=0.6.<span class=\"Apple-converted-space\">\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 <\/span>hair_color(mary,blond).<\/strong><\/pre>\n<p>In a standard Prolog system, if we ask about whether peter\u2019s hair is blond, \u201c?- hair color(peter, blond)\u201d, the system fails. However BPL allows us to obtain the answer \u201cYes with 0.6\u201d.<span class=\"Apple-converted-space\">\u00a0<\/span><\/p>\n<p>To obtain this answer, the BPL system operates as follows: i) First it gen- erates the reflexive, symmetric closure of the fuzzy relation {R(black, brown) = 0.6, R(black,blond) = 0.3, R(blond,brown) = 0.6}, constructing a proxim- ity relation. ii) Then it tries to unify the goal hair color(peter, blond) and (eventually) the fact hair color(peter,brown). Because there exists the en- try R(brown, blond) = 0.6 in the constructed proximity relation (that is, brown is approximate to blond), the unification process succeeds with approximation degree 0.6.<span class=\"Apple-converted-space\">\u00a0<\/span><\/p>\n<p>The above example serves to illustrate both the syntax and the operational se- mantics of the language. Also, it is important to note that, in the last example, to inhibit the construction of the transitive closure (and therefore the construc- tion of a similarity relation) has been crucial to model the information properly and to obtain a convenient result. This effect is obtained by the BPL directive transitivity which disables or enables the construction of the transitive closure of a fuzzy relation during the compilation process. If a similarity relation would be generated, the system would constructed the entries R(brown, blond) = 0.3 and R(blond,brown) = 0.3, overlapping the initial approximation degree pro- vided by the user and leading to a wrong information modeling<span class=\"Apple-converted-space\">\u00a0<\/span><\/p>\n<p><span style=\"color: #800080\"><b>Unification and term comparison.<\/b><span class=\"Apple-converted-space\">\u00a0<\/span><\/span><br \/>\nBPL implements a weak unification operator, also denoted by &#8216;~&#8217;. It can be used, in the source language, to construct expressions like &#8216;Term1 ~ Term2 =:= Degree&#8217; which is interpreted as follows: The expression is true if Term1 and Term2 are unifiable by proximity with approximation degree equal to Degree. In general, we can construct expressions &#8216;Term1 ~ Term2 &lt;op&gt; Degree&#8217; where \u201c&lt;op&gt;\u201d is a comparison arithmetic operator or the symbol \u201c=\u201d. In the last case, the construction \u201cTerm1 ~ Term2 = Degree\u201d success if Term1 and Term2 are weak unifiable with approximation degree Degree. \u00a0Note that these are crisp expressions which are evaluated to the approximation degree 1.0.<\/p>\n<p>Starting with BPL version 3.4, an\u00a0explicit weak unification operator &#8216;~~&#8217; was implemented,\u00a0which is the fuzzy counterpart of the syntactical unification operator &#8216;=&#8217; of standard Prolog. The\u00a0expression\u00a0&#8216;Term1 ~~ Term2&#8217; \u00a0success with degree D if\u00a0\u00a0Term1 and Term2 are unifiable by proximity with approximation degree D. Note that contrary to the last operator\u00a0 &#8216;~&#8217;, this is a fuzzy operator that returns\u00a0approximation degrees between 0 and 1.0.<\/p>\n<p>The expressions built with these operators may be introduced in a query as well as in the body of a clause.<\/p>\n<p><span style=\"color: #800080\"><b>Fuzzy sets.<\/b><\/span><span class=\"Apple-converted-space\">\u00a0<\/span><br \/>\nBPL makes use of two directives to define and declare the structure of a linguistic variable: domain and fuzzy_set.<span class=\"Apple-converted-space\">\u00a0<\/span><\/p>\n<p>The domain directive allows to declare and define the universe of discourse or domain associated to a linguistic variable.<span class=\"Apple-converted-space\">\u00a0 <\/span>The fuzzy_set directive allows to declare and define a list of fuzzy subsets (which are associated to the primary terms of a linguistic variable) on a predefined domain. At this time, it is possible to define two types of membership functions: either a trapezoidal function or a triangular function.<span class=\"Apple-converted-space\">\u00a0<\/span><\/p>\n<p>BPL provides modifiers that can be applied to fuzzy subsets. Additionally, a BPL program may include what we call &#8220;domain points&#8221; and &#8220;domain ranges&#8221;.<span class=\"Apple-converted-space\">\u00a0<\/span><\/p>\n<p>Example 2. BPL models the following fuzzy inference in a very natural way: &#8220;if $x$<span class=\"Apple-converted-space\">\u00a0 <\/span>is young then $x$ is fast&#8221; and &#8220;Robert is middle&#8221; then &#8220;Robert is somewhat fast&#8221;.<\/p>\n<pre><strong>% DIRECTIVES\r\n :-domain(age, 0, 100, years).\r\n :-fuzzy_set(age,[young(0,0,30,50), middle(20,40,60,80),\r\n                  old(50,80,100,100)]).\r\n :-domain(speed, 0, 40, km\/h).\r\n :-fuzzy_set(speed,[slow(0,0,15,20), normal(15,20,25,40),\r\n                    fast(25,30,40,40)]).\r\n\r\n% FACTS AND RULES\r\n speed(X, fast) :- age(X, young). <span class=\"Apple-converted-space\">\u00a0 \u00a0 \u00a0 \u00a0<\/span>\r\n age(robert, middle).<\/strong><\/pre>\n<p>Now, if we launch the goal: &#8220;?- speed(robert,somewhat#fast). The BPL system answers &#8220;Yes with 0.375&#8221;.<\/p>\n<p><span style=\"color: #800080\"><b>Definite Clause Grammars.<\/b><\/span><br \/>\nVersion 3.6 has introduced the ability\u00a0to work with Definite Clause Grammars (DCG) natively.\u00a0 DCGs were initially\u00a0a notation for writing production rules for defining grammars, but now they can be used to parse, generate and check lists. In addition, they form a comfortable interface to difference lists.<\/p>\n<p><span style=\"color: #800080\"><b>WordNet and BPL.<\/b><\/span><span class=\"Apple-converted-space\">\u00a0<\/span><br \/>\nIn Bousi\u223cProlog, the wn-connect subsystem must be made visible before using the built-ins (public predicates) defined in its modules.\u00a0This can be done interactively, without the requirement of loading a BPL program first, by launching the following goal:<\/p>\n<pre><strong>BPL&gt; ensure_loaded(wn(wn_connect)).<\/strong>\r\n<strong>Yes<\/strong>\r\n<strong>With approximation degree: 1 .<\/strong><\/pre>\n<p>or loading\u00a0a program, with\u00a0the directive <strong>\u00a0:- wn connect.<\/strong> in the first line of the program.<\/p>\n<p>Remember that BPL directives must be used within a program. BPL directives \u00a0to access the WordNet database and all the ancillary stuff for related predicates are the following:<\/p>\n<p><strong>:- wn_connect.<\/strong><br \/>\nThis directive performs the necessary actions to connect BPL to the WordNet resources. It must occur before any other access to WordNet, and it assumes that the environment variable <strong>WNDB<\/strong> has been set to the OS directory in which the WordNet database is stored.<\/p>\n<p>There is an alternative to this directive if the environment variable cannot be set or the user simply does not want to:<\/p>\n<p><strong>:- wn_connect(Directory).<\/strong><br \/>\nWhere <strong>Directory<\/strong> is the directory where the WordNet database is located.<\/p>\n<p>Next directives are responsible for generating proximity equations building an ontology:<\/p>\n<p><strong>:- wn_gen_prox_equations(Msr, LL_of_Pats).<\/strong><br \/>\nWhere <strong>Msr<\/strong> is the similarity measure which can have any of the following constant values: \u00a0<strong>path<\/strong>, \u00a0<strong>wup<\/strong> (Wu &amp; Palmer, 1994), <strong>lch<\/strong> (Leacock &amp; Chodorow, 1998), <strong>res<\/strong> (Resnik, 1995), <strong>jcn<\/strong> (Jiang &amp; Conrath, 1997) and <strong>lin<\/strong> (Lin, 1998).\u00a0The second argument <strong>LL_of_Pats<\/strong> is a list for which each element is another list containing the patterns that must be related\u00a0by\u00a0proximity equations.<br \/>\nThe pattern can be either a word or the structure <strong>Word:Type:Sense<\/strong>, where <strong>Word<\/strong> is the word, <strong>Type<\/strong> is its type (either <strong>n<\/strong> for noun or <strong>v<\/strong> for verb)\u00a0and <strong>Sense<\/strong> is the sense number in its synset.<br \/>\nIf the pattern is simply a word, then a sense number of 1 is assumed, and its type is made to match to all other words in the same list.<\/p>\n<p><strong><span style=\"color: #993366\">Filtering techniques.<\/span><\/strong><br \/>\nThe BPL code can be optimized using filtering techniques. The idea is that the proximity equations in the program files and ontology can be filtered according to the lambda cut, so that the proximity equations that relate the terms with a degree lower than the lambda cut are discarded. Also, this technique prevents the generation of certain rules after the parsing phase, which greatly reduces non-determinism and, therefore, the search tree for a given goal.<\/p>\n<p>Filtering can be activated or deactivated inside a BPL program, using a directive, or from the the BPL shell, using the command <strong>fl<\/strong>:<br \/>\n&#8211; Filtering directive: \u00a0 \u00a0<strong>:-filtering(+Boolean).<\/strong>\u00a0 \u00a0If the parameter Boolean is true, activates filtering, if it is false, disables filtering.<br \/>\n&#8211; Command fl: \u00a0 \u00a0<strong>fl +Boolean<\/strong>. \u00a0 Same behaviour as the directive.<\/p>\n<p>On the other hand, the lambda-cut can be modified using the BPL shell command <strong>lc<\/strong>.<\/p>\n<p><strong><span style=\"color: #993366\">Tail recursion and Indexing.<\/span><\/strong><br \/>\nBousi~Prolog implements WSLD-resolution by translating BPL code into Prolog code. The translation process is called BPL expansion and the translated code, TPL code. BPL expansion has two drawbacks: first, expanded rules breaks tail recursion and, second, it avoids the benefits of clause indexing techniques available in current implementations of Prolog.<\/p>\n<p><strong>Tail recursion<\/strong> is lost because when the rules of the BPL source program are expanded, partial degrees are composed by means of a last call to the internal predicate <strong>degree_composition\/2<\/strong>. So, if a predicate in the source program is defined by tail recursion, when expanding the rule to obtain the TPL program, the last call is not anymore a call to the recursive predicate, and Prolog cannot perform last call optimization when the TPL program is consulted. This problem can be solved by computing the partial degrees first (by means of a call to the predicate <strong>degree_composition\/2<\/strong>) and passing them, on the fly, through an accumulator parameter of each call in the body of a rule, keeping the last call as the recursive call.<\/p>\n<p>A new directive \u00a0<strong>:-degree accumulator(+Boolean)<\/strong> is provided for either enabling or disabling degree accumulator translation. Enabling this translation implies not breaking tail recursion optimization\u00a0in BPL programs. By default, it is enabled (<strong>Boolean=true<\/strong>).<\/p>\n<p>Problems with <strong>indexing<\/strong> arise because, for accomplishing a proximity based semantics with a crisp syntactic unification, it is necessary to flatten and linearise the rules of the BPL source program. In this way, two drawbacks occur: first, head unification is delayed up to the clause body, which avoids some Prolog compiler optimisations; and, second, the indexation on head arguments in the rules is lost. We have introduced some techniques to remedy some aspects of these indexing problems.<\/p>\n<p>A new directive \u00a0<strong>:-indexing(+Boolean)<\/strong> is at disposal of a BPL system user for either enabling or disabling indexing optimization. By default, it is enabled (<strong>Boolean=true<\/strong>).<\/p>\n<p><strong><span style=\"color: #993366\">Hypothetical reasoning.<\/span><\/strong><br \/>\nBousi~Prolog added the ability to reason hypothetically starting with version 4.0.<\/p>\n<p>Hypothetical reasoning (also called `what-if&#8217; analysis) allows for making deductions in terms of assumed data. It has a wide range of applications, ranging from planning and scheduling, logistics, healthcare and everything related to decision making in possible scenarios.<\/p>\n<p>In the field of Logic Programming it is common to use the so-called &#8220;embedded implication&#8221; (<strong>=&gt;<\/strong>) (see the papers from Bonner) to model hypothetical reasoning. In that context and roughly speaking, hypothetical reasoning works as follows: given a program <strong>P<\/strong>, a goal <strong>R =&gt; G<\/strong>, where <strong>R<\/strong> is a rule and <strong>G<\/strong> a goal, is derivable from <strong>P<\/strong> if <strong>G<\/strong> is derivable by assuming that <strong>R<\/strong> holds. This is done by building a new computational context make up of the union of the rule <strong>R<\/strong> to the program <strong>P<\/strong>.<\/p>\n<p>In order to perform this type of hypothetical reasoning, it has been necessary to extend both the syntax and the operational mechanism of the Bousi~Prolog language.<\/p>\n<p>Hypothetical Bousi~Prolog extends BPL rules with embedded implications in their bodies. A Hypothetical BPL rule is a conditional formula:<\/p>\n<p style=\"text-align: left;padding-left: 90px\"><strong>\u00a0A :- E_1, &#8230;, E_n<\/strong><\/p>\n<p style=\"text-align: left\">where the antecedent <strong>A<\/strong> is an atom and the consequent is a conjunction of embedded implications <strong>E_i<\/strong>. When the body is empty, we write simply <strong>A<\/strong> (which is a rule equivalent to <strong>A :- true<\/strong>).<\/p>\n<p>An embedded implication <strong>E<\/strong> is the following:<\/p>\n<p style=\"padding-left: 90px\">1) \u00a0<strong> A<\/strong>, an atom; or<br \/>\n2) \u00a0<strong> R =&gt; E<\/strong>, where <strong>R<\/strong> is a rule.<\/p>\n<p>Thus, an embedded implication can consist of a chain of embedded implications:<\/p>\n<p style=\"padding-left: 90px\"><strong>R_1 =&gt; (R_2 =&gt; (&#8230; (R_n =&gt; A) &#8230;))<\/strong>,<\/p>\n<p>where each <strong>R_i<\/strong>\u00a0is a rule and <strong>A<\/strong> is an atom. As syntactic sugar, this chain is rewritten as <strong>R_1 \/\\ \u00a0&#8230; \/\\ R_n =&gt; A<\/strong>.<\/p>\n<p>To access the hypothetical mode, two ways are possible:<\/p>\n<ul>\n<li>From a program, using the\u00a0program directive <strong>:- hypothetical(&lt;Boolean&gt;)<\/strong> for enabling or disabling hypothetical mode.<\/li>\n<li>From the BPL shell, by means of the command <strong>hy &lt;Boolean&gt;<\/strong> for switching between normal and hypothetical reasoning modes.<\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"<p>The BPL syntax is mainly the Prolog syntax but enriched with a built-in symbol \u201c~\u201d used for describing proximity relations (actually, fuzzy binary relations which are automatically converted into proximity or similarity relations) by means of what we call a proximity equation. Proximity equations are expressions of the form: &lt;symbol&gt; ~ &lt;symbol&gt; = &lt;proximity degree&gt;\u00a0 &hellip; <\/p>\n<p class=\"link-more\"><a href=\"https:\/\/dectau.uclm.es\/bousi-prolog\/2018\/07\/25\/language-overview\/\" class=\"more-link\">Continue reading<span class=\"screen-reader-text\"> &#8220;LANGUAGE OVERVIEW&#8221;<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-20","post","type-post","status-publish","format-standard","hentry","category-sin-categoria"],"_links":{"self":[{"href":"https:\/\/dectau.uclm.es\/bousi-prolog\/wp-json\/wp\/v2\/posts\/20","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/dectau.uclm.es\/bousi-prolog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/dectau.uclm.es\/bousi-prolog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/dectau.uclm.es\/bousi-prolog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/dectau.uclm.es\/bousi-prolog\/wp-json\/wp\/v2\/comments?post=20"}],"version-history":[{"count":17,"href":"https:\/\/dectau.uclm.es\/bousi-prolog\/wp-json\/wp\/v2\/posts\/20\/revisions"}],"predecessor-version":[{"id":407,"href":"https:\/\/dectau.uclm.es\/bousi-prolog\/wp-json\/wp\/v2\/posts\/20\/revisions\/407"}],"wp:attachment":[{"href":"https:\/\/dectau.uclm.es\/bousi-prolog\/wp-json\/wp\/v2\/media?parent=20"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/dectau.uclm.es\/bousi-prolog\/wp-json\/wp\/v2\/categories?post=20"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/dectau.uclm.es\/bousi-prolog\/wp-json\/wp\/v2\/tags?post=20"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}