<?xml version="1.0" standalone="yes"?>
<Paper uid="J80-3004">
  <Title>Understanding Spoken Language</Title>
  <Section position="2" start_page="0" end_page="0" type="abstr">
    <SectionTitle>
FRONT-LEG and TYPICAL-ELEPHANT'S-
</SectionTitle>
    <Paragraph position="0"> TYPICAL-LEG? It cannot be *VC, because that would make CLYDE'S-LEFT-FRONT-LEG one of the legs of the typical elephant, not one of Clyde's legs. In fact, if general information is to be stored about elephants' left front legs, we need TYPICAL-ELEPHANT'S-LEFT-FRONT-LEG, an *INDV role-node with *VC to TYPICAL-ELEPHANT'S-TYPICAL-LEG, and we cannot confuse this with Clyde's left front leg. Fahlman's solution is to make CLYDE'S-LEFT-FRONT-LEG another kind of node, a *MAP-node, with a map-wire to TYPICAL-ELEPHANT'S-LEFT-FRONT-LEG. Meanwhile, CLYDE'S-TYPICAL-LEG is a *TMAP-node with map-wire to TYPICAL-ELEPHANT'S-TYPICAL-LEG. All *MAP and *TMAP nodes also have an owner-wire to the individual which owns them, paralleling the EXISTENCE-link of their parents. Because of Fahlman's marking inheritance scheme, it is not necessary to connect CLYDE'S-LEFT-FRONT-LEG to CLYDE'S-TYPICAL-LEG as well. I leave it to the reader to examine the following alternative proposal.</Paragraph>
    <Paragraph position="1"> Give CLYDE'S-LEFT-FRONT-LEG a *VC link to TYPICAL-ELEPHANT'S-LEFT-FRONT-LEG. This requires TYPICAL-ELEPHANT'S-LEFT-FRONT-LEG to be a *TYPE-node, which is not the case in NETL. The associated set-node would then be ELEPHANT'S-LEFT-FRONT-LEG-SET, a node representing the set of all left front legs of elephants, and quite distinct from the set of left front legs of the typical elephant, for which a node would not exist since it is a singleton set. ELEPHANT'S-LEFT-FRONT-LEG-SET is not a subset of TYPICAL-ELEPHANT'S-LEG-SET, because the latter represents the set of legs of the typical elephant, whereas the former represents the set of left front legs of all elephants. They both must be subsets of the set of legs of all elephants, represented by ELEPHANT-LEG-SET, a set-node with associated type-node TYPICAL-ELEPHANT-LEG. Certainly, one role-node of the description based on TYPICAL-ELEPHANT-LEG is TYPICAL-ELEPHANT-LEG'S-ELEPHANT. It would be nice if this were just our old friend TYPICAL-ELEPHANT but this does not seem to be the case since TYPICAL-ELEPHANT is a base-node and TYPICAL-ELEPHANT-LEG'S-ELEPHANT is a role-node. From a predicate calculus point of view, what we have done is construct formulas for &amp;quot;For every elephant there is a leg ...&amp;quot; and &amp;quot;For every elephant leg there is an elephant ...&amp;quot; If one of the advantages of the typical-member technique seems to be the ability to collapse *VC chains, and thus see an individual as a virtual copy of its hierarchical ancestors, consider what Fahlman calls the &amp;quot;copy-confusion&amp;quot; problem. This problem appears in several guises. In one, we try to find the weight of 184 American Journal of Computational Linguistics, Volume 6, Number 3-4, July-December 1980 Book Reviews NETL: A System for Representing and Using Real-World Knowledge Clyde's trunk. CLYDE and CLYDE'S-TRUNK are both *VCs of TYPICAL-PHYSICAL-OBJECT, which has a weight as one of its role-nodes. In the process of collapsing *VC chains we lose the distinction between Clyde's trunk's weight and Clyde's weight. In another version of the problem, the typical family has both a father and a child. Since Clyde is the father in one family and a child in another, copy-confusion causes Clyde to be seen as his own father. Fahlman considers four solutions to this problem. For the first solution &amp;quot;I am not yet sure whether it is impossible to do this, or just very difficult. A second possibility is to abandon the virtual-copy semantics ... I feel that this approach should be taken only as a last resort ...</Paragraph>
    <Paragraph position="2"> A third approach ... seems a needlessly complex and economically unattractive solution ... the fourth solution is the one that seems to me the most promising, and is the one that I am using in the current version of NETL ... A few possible relevant nodes will be missed by this approach ... The parallel portions of the system are not complete, in the logician's sense, but they were never intended to be; we wanted to be able to do the most important deductions very fast, and I believe that NETL still does that&amp;quot; \[p. 148-53\]. Even the fourth solution seems to compromise on some features earlier considered beneficial, and even on the virtual-copy idea itself, &amp;quot;In some cases, it is useful to create pseudo-individuals to fill roles in the middle of long role-chains; this tends to break up the chains into more manageable sections&amp;quot; \[p. 152\].</Paragraph>
    <Paragraph position="3"> Fahlman feels that &amp;quot;The copy-confusion problem, in its various guises, is principally a problem of properly implementing an essentially correct semantic notation in a parallel manner; the binding-ambiguity problem, on the other hand, results from a shortcoming of the semantic notation itself&amp;quot; \[p. 153\]. This problem arises when, in a predicate calculus approach there would be a statement with two or more universally  quantified variables ranging over the same set. Consider the HATES relation between TYPICAL-ELEPHANT and TYPICAL-ELEPHANT. Does this mean that every elephant hates himself, or that every elephant hates every elephant including himself? What about &amp;quot;every elephant hates every elephant other than himself&amp;quot;? Fahlman decides by fiat (there is no other way) that it means the first. To get the third, he introduces *OTHER-nodes. Every *OTHER-node has a type-wire to a *TYPE-node and represents every other element of the associated set. &amp;quot;Every elephant hates himself&amp;quot; is represented by TYPICAL-ELEPHANT HATES TYPICAL-ELEPHANT. &amp;quot;Every elephant hates every other elephant&amp;quot; is represented by</Paragraph>
  </Section>
class="xml-element"></Paper>