<?xml version="1.0" standalone="yes"?>
<Paper uid="P82-1004">
  <Title>What's in a Semantic Network?</Title>
  <Section position="2" start_page="0" end_page="20" type="abstr">
    <SectionTitle>
Abstract
</SectionTitle>
    <Paragraph position="0"> Ever since Woods's &amp;quot;What's in a Link&amp;quot; paper, there has been a growing concern for formalization in the study of knowledge representation. Several arguments have been made that frame representation languages and semantic-network languages are syntactic variants of the ftrst-order predicate calculus (FOPC). The typical argument proceeds by showing how any given frame or network representation can be mapped to a logically isomorphic FOPC representation. For the past two years we have been studying the formalization of knowledge retrievers as well as the representation languages that they operate on. This paper presents a representation language in the notation of FOPC whose form facilitates the design of a semantic-network-like retriever.</Paragraph>
    <Paragraph position="1"> I. Introduction We are engaged in a long-term project to construct a system that can partake in extended English dialogues on some reasonably well specified range of topics. A major part of this effort so far has been the specification of a knowledge representation. Because of the wide range of issues that we are trying to capture, which includes the representation of plans, actions, time, and individuals' beliefs and intentions, it is crucial to work within a framework general enough to accommodate each issue. Thus, we began developing our representation within the first-order predicate calculus. So far, this has presented no problems, and we aim to continue within this framework until some problem forces us to do otherwise.</Paragraph>
    <Paragraph position="2"> Given this framework, we need to be able to build reasonably efficient systems for use in the project. In particular, the knowledge representation must be able to support the natural language understanding task. This requires that certain forms of inference must be made.</Paragraph>
    <Paragraph position="3"> ~'~ Within a general theorem-proving framework, however, those inferences desired would be lost within a wide range of undesired inferences. Thus we have spent considerable effort in constructing a specialized inference component that can support the language understanding task.</Paragraph>
    <Paragraph position="4"> Before such a component could be built, we needed to identify what inferences were desired. Not surprisingly, much of the behavior we desire can be found within existing semantic network systems used for natural language understanding. Thus the question &amp;quot;What inferences do we need?&amp;quot; can be answered by answering the question &amp;quot;What's in a semantic network?&amp;quot; Ever since Woods's \[1975\] &amp;quot;What's in a Link&amp;quot; paper, there has been a growing concern for formalization in the study of knowledge representation. Several arguments have been made that frame representation languages and semantic-network languages are syntactic variants of the f~st-order predicate calculus (FOPC).</Paragraph>
    <Paragraph position="5"> The typical argument (e.g., \[Hayes, 1979; Nilsson, 1980; Charniak, 1981a\]) proceeds by showing how any given frame or network representation can be mapped to a logically isomorphic (i.e., logically equivalent when the mapping between the two notations is accounted for) FOPC representation. We emphasize the term &amp;quot;logically isomorphic&amp;quot; because these arguments have primarily dealt with the content (semantics) of the representations rather than their forms (syntax). Though these arguments are valid and scientifically important, they do not answer our question.</Paragraph>
    <Paragraph position="6"> Semantic networks not only represent information but facilitate the retrieval of relevant facts. For instance, all the facts about the object JOHN are stored with a pointer directly to one node representing JOHN (e.g., see the papers in \[Findler, 1979\]). Another example concerns the inheritance of properties. Given a fact such as &amp;quot;All canaries are yellow,&amp;quot; most network systems would automatically conclude that &amp;quot;Tweety is yellow,&amp;quot; given that Tweety is a canary. This is typically implemented within the network matcher or retriever.</Paragraph>
    <Paragraph position="7"> We have demonstrated elsewhere \[Frisch and Allen, 1982\] the utility of viewing a knowledge retriever as a specialized inference engine (theorem prover). A specialized inference engine is tailored to treat certain predicate, function, and constant symbols differently than others. This is done by building into the inference engine certain true sentences involving these symbols  and the control needed to handle with these sentences.</Paragraph>
    <Paragraph position="8"> The inference engine must also be able to recognize when it is able to use its specialized machinery. That is, its specialized knowledge must be coupled to the form of the situations that it can deal with.</Paragraph>
    <Paragraph position="9"> For illustration, consider an instance of the ubiquitous type hierarchies of semantic networks:  By mapping the types AUTOS and MUSTANGS to be predicates which are true only of automobiles and mustangs respectively, the following two FOPC sentences are logically isomorphic to the network:</Paragraph>
    <Paragraph position="11"> However, these two sentences have not captured the form of the network, and furthermore, not doing so is problematic to the design of a retriever. The subtype and type links have been built into the network language because the network retriever has been built to handle them specially. That is, the retriever does not view a subtype link as an arbitrary implication such as (1.1) and it does not view a type link as an arbitrary atomic sentence such as (1.2).</Paragraph>
    <Paragraph position="12"> In our representation language we capture the form as wetl as the content of the network. By introducing two predicates, TYPE and SUBTYPE, we capture the meaning of the type and subtype links. TYPE(~O is true iff the individual i is a member of the type (set of objects) t, and SUBTYPE(tl, t 2) is true iff the type t I is a subtype (subset) of the type t 2. Thus, in our language, the following two sentences would be used to represent what was intended by the network:</Paragraph>
    <Paragraph position="14"> It is now easy to build a retriever that recognizes subtype and type assertions by matching predicate names. Contrast this to the case where the representation language used (1.1) and (1.2) and the retriever would have to recognize these as sentences to be handled in a special manner.</Paragraph>
    <Paragraph position="15"> But what must the retriever know about the SUBTYPE and TYPE predicates in order that it can reason (make inferences) with them? There are two assertions, (A.1) and (A.2), such that {(1.1),(1.2)} is logically isomorphic to {(2.1),(2.2),(A.1),(A.2)}. (Note: throughout this paper, axioms that define the retriever's capabilities will be referred to as built-in axioms and specially labeled A.1, A.2, etc.)  The retriever will also need to know how to control inferences with these axioms, but this issue is considered only briefly in this paper.</Paragraph>
    <Paragraph position="16"> The design of a semantic-network language often continues by introducing new kinds of nodes and links into the language. This process may terminate with a fixed set of node and link types that are the knowledge-structuring primitives out of which all representations are built. Others have referred to these knowledge-structuring primitives as epistemological primitives \[Brachman, 1979\], structural relations \[Shapiro, 1979\], and system relations \[Shapiro, 1971\]. If a fLxed set of knowledge-structuring primitives is used in the language, then a retriever can be built that knows how to deal with all of them.</Paragraph>
    <Paragraph position="17"> The design of our representation language very much mimics this approach. Our knowledge-structuring primitives include a fixed set of predicate names and terms denoting three kinds of elements in the domain.</Paragraph>
    <Paragraph position="18"> We give meaning to these primitives by writing domain-independent axioms involving them. Thus far in this paper we have introduced two predicates (TYPE and SUBTYPE'), two kinds of elements (individuals and types), and two axioms ((A.1) and (A.2)). We shall name types in uppercase and individuals in uppercase letters followed by at least one digit.</Paragraph>
    <Paragraph position="19"> Considering the above analysis, a retrieval now is viewed as an attempt to prove some queried fact logically follows from the base facts (e.g., (2.1), (2.2)) and the built-in axioms (such as A.1 and A.2). For the purposes of this paper, we can consider aa~ t~ase facts to be atomic formulae (i.e., they contain no logical operators except negation). While compound formulae such as disjunctions can be represented, they are of little use to the semantic network retrieval facility, and so will  not be considered in this paper. We have implemented a retriever along these lines and it is currently being used in the Rochester Dialogue System \[Allen, 1982\].</Paragraph>
  </Section>
class="xml-element"></Paper>