% % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % %
%                                                                           %
% File:            multiple.dtr                                             %
% Purpose:         ordered multiple inheritance -- two techniques           %
% Authors:         Gerald Gazdar, Roger Evans & Lionel Moser, April 1991    %
%                  revised by Gerald Gazdar, August 1993                    %
% Email:           geraldg@cogs.sussex.ac.uk, Roger.Evans@itri.bton.ac.uk   %
% Address:         COGS, Sussex University, Brighton BN1 9QH, UK            %
%                  ITRI, Univ. Brighton, Lewes Road, Brighton BN2 4GJ, UK   %
% Documentation:   see item cited below                                     %
% Related files:   ordering.dtr                                             %
% Version:         2.02                                                     %
%      Copyright (c) University of Sussex 1993.  All rights reserved.       %
%                                                                           %
% % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % %

% Roger Evans, Gerald Gazdar, & Lionel Moser (1993) "Prioritised multiple
% inheritance in DATR" in Ted Briscoe, Valeria de Paiva & Ann Copestake,
% eds., Inheritance, Defaults, and the Lexicon, Cambridge, CUP, 38-46.

% Various researchers using default inheritance networks for lexical
% representation have wished to use a general form of multiple inheri-
% tance constrained by an explicit preference ordering on the parent nodes
% ("if you can get the info from node A, then do so, otherwise try node B,
% and if that fails, then take a look at node C").  Flickinger's 1987 PhD
% dissertation and the work of Russell, Warwick and their colleagues at
% ISSCO provide clear examples of this style of analysis.  This file
% shows how one can reconstruct analyses of this kind within DATR, despite
% the latter's commitment to an orthogonal form of inheritance.  Using
% essentially the same example throughout, it illustrates two different
% techniques for achieving the same end.  Although each variant below is
% is restricted to two parent nodes and simple binary properties, the same
% techniques generalize to arbitrary attribute-value information and an
% arbitrary number of parent nodes (see 'ordering.dtr').

% FIRST METHOD, USING EVALUABLE PATHS

Idem:   <> == undef
        <undef> == <>
        <true> == true
        <false> == false.

John:   <> == Idem
        <is agile> == true
        <is brave> == false
        <is devious> == true
        <is energetic> == false
        <is generous> == true
        <is happy> == false.

Mary:   <> == Idem
        <is agile> == true
        <is brave> == true
        <is clever> == true
        <is devious> == false
        <is energetic> == false
        <is famous> == false.

% Peter is basically like Mary except where a property is undefined
% for her, in which case he resembles John:

Peter:  <> == Idem
        <is> == <Mary John>.

% Susan is basically like John except where a property is undefined
% for him, in which case she resembles Mary:

Susan:  <> == Idem
        <is> == <John Mary>.

%------ some theorems -------------------

% Peter:<is agile> = true
%       <is brave> = true
%       <is clever> = true
%       <is devious> = false
%       <is energetic> = false
%       <is famous> = false
%       <is generous> = true
%       <is happy> = false
%       <is impatient> = undef.

% Susan:<is agile> = true
%       <is brave> = false
%       <is clever> = true
%       <is devious> = true
%       <is energetic> = false
%       <is famous> = false
%       <is generous> = true
%       <is happy> = false
%       <is impatient> = undef.

% % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % %

% SECOND METHOD, USING EXPLICIT FAILURE PATHS

Joan:   <> == "<not joan>"
        <not> == undef
        <is agile> == true
        <is brave> == false
        <is devious> == true
        <is energetic> == false
        <is generous> == true
        <is happy> == false.

Milt:   <> == "<not milt>"
        <not> == undef
        <is agile> == true
        <is brave> == true
        <is clever> == true
        <is devious> == false
        <is energetic> == false
        <is famous> == false.

% Sarah is basically like Milt except where a property is undefined
% for him, in which case she resembles Joan:

Sarah:  <> == Milt
        <not milt> == Joan:<>.

% David is basically like Joan except where a property is undefined
% for her, in which case he resembles Milt:

David:  <> == Joan
        <not joan> == Milt:<>.

%------ some theorems -------------------

% Sarah:<is agile> = true
%       <is brave> = true
%       <is clever> = true
%       <is devious> = false
%       <is energetic> = false
%       <is famous> = false
%       <is generous> = true
%       <is happy> = false
%       <is impatient> = undef.

% David:<is agile> = true
%       <is brave> = false
%       <is clever> = true
%       <is devious> = true
%       <is energetic> = false
%       <is famous> = false
%       <is generous> = true
%       <is happy> = false
%       <is impatient> = undef.

% % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % %

# hide  Idem Joan John Mary Milt.

# show  <is agile>
        <is brave>
        <is clever>
        <is devious>
        <is energetic>
        <is famous>
        <is generous>
        <is happy>
        <is impatient>.

% The next line is the Revision Control System Id: do not delete it.
% $Id: archive.dtr,v 1.1 1997/04/09 20:40:33 root Exp $