<?xml version="1.0" standalone="yes"?>
<Paper uid="P82-1004">
  <Title>What's in a Semantic Network?</Title>
  <Section position="4" start_page="21" end_page="22" type="metho">
    <SectionTitle>
3. Making Types Work for You
</SectionTitle>
    <Paragraph position="0"> The system described so far, though simple, is close to providing us with one of the most characteristic inferences made by semantic networks, namely inheritance. For example, we might have the following sort of information in our network:  These would be captured in the Hendrix formalism using his delineation mechanism.</Paragraph>
    <Paragraph position="1"> Note that relations such as &amp;quot;WARM-BLOODED&amp;quot; and &amp;quot;HAS-2-LEGS&amp;quot; should themselves be described as relations with roles, but that is not necessary for this example. Given these facts, and axioms (A.1) to (A.3), we can prove that &amp;quot;George has two legs&amp;quot; by using axiom  and then using (18) with (16) to conclude (19) HAS-2-LEGS(GEORGE1).</Paragraph>
    <Paragraph position="2"> In order to build a retriever that can perform these inferences automatically, we must be able to distinguish facts like (16) and (17) from arbitrary facts involving implications, for we cannot allow arbitrary chaining and retain efficiency. This could be done by checking for implications where the antecedent is composed entirely of type restrictions, but this is difficult to specify. The route we take follows the same technique described above when we introduced the TYPE and SUBTYPE predicates. We introduce new notation into the language that explicitly captures these cases. The new form is simply a version of the typed FOPC, where variables may be restricted by the type they range over. Thus, (16) and (17) become (20) v x:2-LEGGED-ANIMAI.S HAS-2-LEGS(x) (21) V y:MAMMALS WARM-BLOODED(y), The retriever now can be implemented as a typed theorem prover that operates only on atomic base facts (now including (20) and (21)) and axioms (A.1) to (A.3). We now can deduce that GEORGE1 has two legs and that he is warm-blooded. Note that objects can be of many different types as well as types being subtypes of different types. Thus, we could have done the above without the type PERSONS, by making GEORGE1 of type 2-LEGGED-ANIMALS and MAMMALS.</Paragraph>
  </Section>
  <Section position="5" start_page="22" end_page="22" type="metho">
    <SectionTitle>
4. Making Roles Work for You
</SectionTitle>
    <Paragraph position="0"> In the previous section we saw how properties could be inherited. This inheritance applies to role assertions as well. For example, given a type EVILNTS that has an  Note that the definition of the type ACTIONS could further specify the type of the values of its OMI&amp;quot;.CT role, but it could not contradict fact (25). Thus</Paragraph>
  </Section>
  <Section position="6" start_page="22" end_page="23" type="metho">
    <SectionTitle>
(26) V x:ACTIONS
3 y:PERSONS ROLE(x, OBJECT, y),
</SectionTitle>
    <Paragraph position="0"> further restricts the value of the OBJECT role for all individuals of type ACTIONS to be .of type PERSONS.</Paragraph>
    <Paragraph position="1"> Another common technique used in semantic network systems is to introduce more specific types of a given type by specifying one (or more) of the role values. For instance, one might introduce a subtype of  Then we could encode the general fact that all actions by Jack are violent by something like (29) v abj:ACTION-BY-JACK VIOLENT(abj).</Paragraph>
    <Paragraph position="2"> This is possible in our logic, but there is a more flexible and convenient way of capturing such information. Fact (29), given (27) and (28), is equivalent to</Paragraph>
    <Paragraph position="4"> If we can put this into a form that is recognizable to the retriever, then we could assert such facts directly without having to introduce arbitrary new types.</Paragraph>
    <Paragraph position="5"> The extension we make this time is from what we called a type logic to a role logic. This allows quantified variables to be restricted by role values as well as type.</Paragraph>
    <Paragraph position="6"> Thus, in this new notation, (30) would be expressed as (31) v a:ACH'IONS \[ACTOR JACK\] VIOLENT(a).</Paragraph>
    <Paragraph position="7"> In general, a formula of the form v a:T \[R1V1\]...\[RnVn\] Pa is equivalent to</Paragraph>
    <Paragraph position="9"> Correspondingly, an existentially cluantitied formula such as</Paragraph>
    <Paragraph position="11"> The retriever recognizes these new forms and fully reasons about the role restrictions. It is important to remember that each of these notation changes is an extension onto the original simple language. Everything that could be stated previously can still be stated. The new notation, besides often being more concise and convenient, is necessary only if the semantic network retrieval facilities are desired.</Paragraph>
    <Paragraph position="12"> Note also that we can now define the inverse of (28), and state that all actions with actor JACK are necessarily of type ACTION-BY-JACK. This can be expressed as (32) v a:ACTIONS \[ACTOR JACK\] TYPE(a, ACTION-BY-JACK).</Paragraph>
  </Section>
  <Section position="7" start_page="23" end_page="24" type="metho">
    <SectionTitle>
5. Equality
</SectionTitle>
    <Paragraph position="0"> One Of the crucial facilities needed by natural language systems is the ability to reason about whether individuals are equal. This issue is often finessed in semantic networks by assuming that each node represents a different individual, or that every type in the type hierarchy is disjoint. This assumption has been called E-saturation by \[Reiter, 1980\]. A natural language understanding system using such a representation must decide on the referent of each description as the meaning representation is constructed, since if it creates a new individual as the referent, that individual will then be distinct from all previously known individuals. Since in actual discourse the referent of a description is not always recognized until a few sentences later, this approach lacks generality.</Paragraph>
    <Paragraph position="1"> One approach to this problem is to introduce full reasoning about equality into the representation, but this rapidly produces a combinatorially, prohibitive search space. Thus other more specialized techniques are desired. We shall consider mechanisms for proving inequality f'trst, and then methods for proving equality.</Paragraph>
    <Paragraph position="2"> Hendrix \[1979\] introduced some mechanisms that enable inequality to be proven. In his system, mere are two forms of subtype links, and two forms of instance links. This can be viewed in our system as follows: the SUBTYPE and TYPE predicates discussed above make no commitment regarding equality. However, a new relation, DSUBTYPE(tl,t2) , asserts that t 1 is a SUBTYPE of t 2, and also that the elements of t 1 are distinct from all other elements of other DSUBTYPES oft 2. This is captured by the axioms</Paragraph>
    <Paragraph position="4"> We cannot express (A.4) in the current logic because the predicate IDFA',ITICAL operates on the syntactic form of its arguments rather than their referents. Two terms are IDENTICAL only if they are lexicaUy the same. To do this formally, we have to be able to refer to the syntactic form of terms. This can be done by introducing quotation into the logic along the lines of \[Perlis, 1981\], but is not important for the point of this paper.</Paragraph>
    <Paragraph position="5"> A similar trick is done with elements of a single type.</Paragraph>
    <Paragraph position="6"> The predicate DTYPE(i,t) asserts that i is an instance of type t, and also is distinct from any other instances of t where the DTYPE holds. Thus we need</Paragraph>
    <Paragraph position="8"> Another extremely useful categorization of objects is the partitioning of a type into a set of subtypes, i.e., each element of the type is a member of exactly one subtype.</Paragraph>
    <Paragraph position="9"> This can be defined in a similar manner as above.</Paragraph>
    <Paragraph position="10"> Turning to methods for proving equality, \[Tarjan, 1975\] describes an efficient method for computing relations that form an equivalence class. This is adapted to support full equality reasoning on ground terms. Of course it cannot effectively handle conditional assertions of equality, but it covers many of the typical cases.</Paragraph>
    <Paragraph position="11"> Another technique for proving equality exploits knowledge about types. Many types are such that their instances are completely defined by their roles. For such a type T, if two instances I1 and 12 of T agree on all their respective rc!~ then they are equal. If I1 and I2 have a role where their values are not equal, then I I and I2 are not equal. If we finally add the assumption that every instance of T can be characterized by its set of role values, then we can enumerate the instances of type T using a function (say t) that has an argument for each role value.</Paragraph>
    <Paragraph position="12">  For example, consider the type AGE-RELS of age properties, which takes two roles, an OBJECT and a VALUE. Thus, the property P1 that captures the assertion &amp;quot;John is 10&amp;quot; would be described as follows:  (33) TYPE(P1,AGE-RELS) A ROLE(PI,OBJECT, JOHN1) A ROLE(P1, VALUE, IO).</Paragraph>
    <Paragraph position="13">  The type AGE-RELS satisfies the above properties, so any individual of type AGE-RELS with OBJECT role JOHN1 and VALUE role 10 is equal to P1. The retriever encodes such knowledge in a preprocessing stage that assigns each individual of type AGE-RELS to a canonical name. The canonical name for P1 would simply be &amp;quot;age-rels(JOHNl,10)&amp;quot;.</Paragraph>
    <Paragraph position="14"> Once a representation has equality, it can capture some of the distinctions made by perspectives in KRL. The same object viewed from two different perspectives is captured by two nodes, each with its own type, roles, and relations, that are asserted to be equal.</Paragraph>
    <Paragraph position="15"> Note that one cannot expect more sophisticated reasoning about equality than the above from the retriever itself. Identifying two objects as equal is typically not a logical inference. Rather, it is a plausible inference by some specialized program such as the reference component of a natural language system which has to identify noun phrases. While the facts represented here would assist such a component in identifying possible referencts for a noun phrase given its description, it is unlikely that they would logically imply what the referent is.</Paragraph>
  </Section>
class="xml-element"></Paper>