7. Case-based (example-based) inferencing using DataLex

7.1 Example-based reasoning – overview

In addition to rule-based inferencing, DataLex also supports one very limited form of analogous reasoning (also known as ‘example-based’ or ‘case-based’ reasoning). This form of analogous reasoning is based on a method of measuring similarity of examples (and drawing conclusions from this) called PANNDA (Precedent Analysis by Nearest Neighbour Discriminant Analysis), developed by Alan Tyree and described in his book Expert Systems in Law, Prentice Hall, 1990. See also further explanation below.

The PANNDA inferencing component is included in this version of DataLex primarily to allow experiments to be carried out in (i) quasi-natural language representations of examples; (ii) the integration of rule-based and case-based reasoning, and (iii) the integration of case-based reasoning with hypertext and text retrieval. The inferencing methods used by PANNDA are, in this context, of secondary interest and not the main point of the exercise, although they are of interest in their own right.

7.2 Relationship between examples and rules in DataLex’s inferencing

PANNDA is implemented in DataLex as types of rules which are called EXAMPLEs. A set of EXAMPLEs is used, for example, to represent all of the cases on a particular legal question. This legal question will be represented as an attribute which is the conclusion of each EXAMPLE. When DataLex obtains the facts of a problem from the user, it compares the facts of the problem to the facts in the EXAMPLEs, and tries to find which is the ‘nearest case’.

When DataLex is trying to infer a value for an attribute and no further rules can be found to assist, it will look to see if the attribute is the subject of an example set. Example-based reasoning is therefore only used ‘when the rules run out’ (to use one well-known formulation).

This type of reasoning is most usefully used when there are a set of cases (or other types of examples) which do not seem to conform to any obviously discernible rule, but have various factors which recur from case to case (although with different values), and where no single case provides any binding authority.

7.3 Knowledge representation – EXAMPLEs

A set of cases is represented as a set of EXAMPLEs, where an EXAMPLE is a particular type of rule declaration.

An EXAMPLE commences with the keyword EXAMPLE, followed by the name of the EXAMPLE and the keyword PROVIDES. The first EXAMPLE in a set would normally be declared to be a GOAL, but there would normally be little point in declaring other EXAMPLEs to be GOALs. A knowledge-base containing only an EXAMPLE set would treat the first EXAMPLE as a GOAL.

The content of an EXAMPLE is normally an assignment (an expression which uses the ONLY IF keyword), such as:

EXAMPLE Armory v Delamirie [1722] EWHC KB J94 PROVIDES

   the finder wins ONLY IF
       the finder was not the occupier of the premises AND
       the chattel was not attached AND ..... [etc]

Each EXAMPLE in the set must have the same conclusion (the attribute preceding ONLY IF), or its negation. In the ‘finder's cases’ example above and below, the common conclusion is the attribute ‘the finder wins’ (or its negative form ‘the finder does not win’). The keywords ONLY IF therefore function in a rather different way in EXAMPLEs than in RULEs. An EXAMPLE could be considered as meaning something like ‘An EXAMPLE where the finder wins, Armory v Delamirie, IS the finder was not the occupier of the premises AND the chattel was not attached AND ..... [etc]’,

7.3.1 Automatic attributes and example names

It is important that each EXAMPLE be named sensibly. In most instances, the name of a case will be the name of an EXAMPLE (eg Armory v Delamirie [1722] EWHC KB J94).

This name is used to construct three automatic attributes of the form:

the situation is similar to example-name;

the situation is on all fours with example-name; and

example-name can be distinguished

These automatic attributes are used by PANNDA to generate reports.

7.3.2 Formal syntax for an EXAMPLE

The syntax for defining examples which form part of an example set is a restricted version of that used for rules:

[GOAL] EXAMPLE [RULE] name PROVIDES
[IF expression THEN] assignment

The expression component of either the IF guard or the assignment itself, should consist of a number of relative expressions separated by an AND operator. Each relative expression (normally just an attribute descriptor) should represent one significant facet of the example.

The OR connector should not be used – if you really have to, use AND/OR instead.

The IF-THEN form should only be used where the attribute about which the example relates is non-boolean.

7.4 An example of a case representation by EXAMPLEs

The following is the knowledge representation for one case on the finding of chattels.

EXAMPLE Armory v Delamirie  [1722] EWHC KB J94  PROVIDES

   the finder wins ONLY IF

       the finder was not the occupier of the premises AND
       the chattel was not attached AND
       the non-finder was not the owner of the real estate AND
       the non-finder was not the owner of the chattel AND
       there was a bailment of the chattel AND
       there was not a term in a lease which mentioned found items AND
       there was not a master-servant relationship between the parties AND
       the chattel was not hidden AND
       there was not an attempt to find the true owner of the chattel AND
       there was prior knowledge of the existence of the chattel

7.5 Reports generated by DataLex EXAMPLE reasoning

An example of a simple Report generated by the FINDER KB follows.

Mr Sweep wins because the situation is similar to Hannah v Peel [1945] KB 509 and 
South Staffordshire Water Co v Sharman [1896] 2 QB 44 can be distinguished.

The situation is similar to Hannah v Peel [1945] KB 509  because: Mr Sweep was not 
the occupier of the premises; Mr Lud was the owner of the real estate; and 
there was not a bailment of the chattel.

South Staffordshire Water Co v Sharman [1896] 2 QB 44= can be distinguished 
because there was not a master-servant relationship between the parties.

7.6 Principles behind the case-based inferencing component

The underlying mechanism used to handle analogous reasoning is based on Alan Tyree's PANNDA (Precedent Analysis by Nearest Neighbour Discriminant Analysis) algorithm. the theory behind PANNDA is described in A Tyree Expert Systems in Law, Prentice-Hall, 1990. For further details of this approach see articles co-authored by Alan Tyree, and references to PANNDA and ‘the Finders’ cases’, in ‘The Datalex Project: History and Bibliography’ cited in Chapter 1. A key aspect of PANNDA is that each matching attribute is weighted on the basis of how poorly it divides the example set, as measured by its inverse variance.

7.6.1 PANNDA inferencing

When the system is about to attempt to infer a value for an attribute using an example set, it first finds all examples which relate to it (that is, all examples where the attribute appears as the target of an assignment). It then infers (or asks the user for) a value for all attributes used in the examples. Finally, it compares each example with the situation described by these attribute values and finds the nearest and furthest example. The furthest example is the one with the closest facts but giving a different result to the nearest one.

The target attribute is set to the same value as the nearest example. The similar or all-fours attribute for the nearest example is set to true. If the example is not on all fours, the distinguished attribute is also set for the furthest case. All of these attributes (including the target attribute itself) receive sensible explanatory associations (for how/reporting). Not all possible supporting attributes are used for explanations. Rather, only significant ones are reported (significant attributes are those which tend to, in themselves, divide the example set or in this instance have unusual values).

7.6.2 PANNDA's DataLex implementation

The main difference between earlier versions of PANNDA and this one is the use of the quasi-natural language knowledge representation.

The original PANNDA approach has also been extended in several minor respects:

• The original PANNDA algorithm dealt only in boolean facts and outcomes. There has never really been any good reason why the outcomes had to be boolean (they are not used in determining which case to follow or distinguish). Accordingly, this restriction has been dropped in the DataLex implementation.
• DataLex also supports non-boolean facts. The variance for each of these is calculated in the context of the present fact value. Accordingly, care should be taken with use of equality operators. These should only be used where the fact can only take one of a discrete number of values.
• It is not necessary that each example contains all of the attributes used in other examples. This feature can be used to generalise the effect of an example. The missing attributes become, in effect, wild. Such examples, are, of course, much easier to match. Again caution is called for.

7.7 Steps in developing an EXAMPLE set

1 Identify an attribute which cannot be determined in any obvious rule-based way, but for which there are a set of cases or other examples which give a value for that attribute as their conclusion. Treat that attribute as the conclusion attribute of the example set.

2 For each case, identify all the aspects of the case which appear to have some bearing on the outcome of the case (ie the value of the conclusion attribute). This is where legal expertise is involved. Define each of these aspects as a DataLex attribute.

3 Analyse all of the cases to establish (if possible) the value of each of the attributes identified for any of the cases.

4 Represent each case as an EXAMPLE, with values for as many of the attributes as are known for that case. It does not matter that values for some attributes are not known.

7.7.1 RULEs, EXAMPLEs and DOCUMENTS can interact

The values of attributes used in EXAMPLEs (eg ‘the finder was not the occupier of the premises’, as used in the example below), will be determined (in the first instance) by backward chaining to determine if there is a RULE with that attribute as conclusion. Where a RULE uses an attribute, backward chaining will invoke an EXAMPLE with that conclusion once all RULEs have been exhausted. The same applies where an attribute is used in a DOCUMENT rule.

If an attribute which is evaluated by an example set is intended to be a GOAL, it may be necessary to create a rule along the following lines.

GOAL RULE Determine whether the finder wins PROVIDES

DETERMINE the finder wins

7.7.2 Use of hypertext links with EXAMPLE rules

Hypertext links to sources can be used with EXAMPLE rules as with any other rules (as detailed in Chapter 5):

• Automatic links will be made to any properly described Australian legislation;
• Explicit links may be made from any other text using the LINK …. TO …. keywords;
• Embedded searches may be linked to any terms using the LINK …. TO …. keywords, such as to terms in keywords which have been interpreted by case law, like ‘bailment’ or ‘occupier’ (as in the Finder KB below).
• Automatic links to properly cited cases, as discussed below.

With EXAMPLE rules based on decisions in particular cases, it is particularly important that a full title and citation for the decision be included in the title of the EXAMPLE. This will then result in the automatic creation of a hypertext link to either (i) the text of the decision, if the decision is included in AustLII or another collaborating LII (eg NZLII, BAILII, HKLII, PacLII, SafLII, CanLII), or (ii) the LawCite citator, if the decision has a citation table there. The LawCite record for a decision can also be accessed from that decision.

Automatic links to cases means, as in the example Report given in 7.5 above, that the user can go to the cases cited in the Report, in order to asses whether they agree with the suggestions for following and distinguishing particular cases given in the Report. In making such a decision they can inspect not only the text of the suggested cases, but also the LawCite record for each of the suggested cases in order to determine whether there are subsequent cases that have a bearing on the suggested cases (and may have been decided after the knowledge-base was written). For discussion of the value of such facilities, see the article ‘Utilising AI in the Legal Assistance Sector – Testing a Role for Legal Information Institutes’ cited in Chapter 1.

Furthermore, links to these cases are available to provide assistance when the user is answering questions relevant to a case. In the Finder KB example, when the user is asked about the finder ‘Was he the occupier of the premises ?’, and responds ‘Why?’, the system replies ‘This will help determine whether or not the situation is similar to Armory v Delamirie [1722] EWHC KB J94.’, with a link to the LawCite citator entry.

7.7.3 Example – the ‘finder's cases’

The Finder KB can be accessed from the DataLex Communities page, or directly to its location at < http://austlii.community/foswiki/DataLex/FinderKB >. Note these aspects:

• Each EXAMPLE rule includes in its name a full citation to the case on which it is based.
• The ‘trespasser rule’ RULE is evaluated before the EXAMLE rules (it should include authority for the proposition it states, but is incomplete).

PERSON the finder
PERSON the non-finder

GOAL RULE the finder wins PROVIDES
DETERMINE the finder wins

RULE trespasser rule PROVIDES
IF the finder is a trespasser THEN the finder does not win

EXAMPLE Armory v Delamirie [1722] EWHC KB J94 PROVIDES
   the finder wins ONLY IF
       the finder was not the occupier of the premises AND
       the chattel was not attached AND
       the non-finder was not the owner of the real estate AND
       the non-finder was not the owner of the chattel AND
       there was a bailment of the chattel AND
       there was not a term in a lease which mentioned found items AND
       there was not a master-servant relationship between the parties AND
       the chattel was not hidden AND
       there was not an attempt to find the true owner of the chattel AND
       there was prior knowledge of the existence of the chattel

EXAMPLE Bridges v Hawkesworth (1851) 21 LJQB 75 PROVIDES
   the finder wins ONLY IF
       the finder was not the occupier of the premises AND
       the chattel was not attached AND
       the non-finder was the owner of the real estate AND
       the non-finder was not the owner of the chattel AND
       there was a bailment of the chattel AND
       there was not a term in a lease which mentioned found items AND
       there was not a master-servant relationship between the parties AND
       the chattel was not hidden AND
       there was an attempt to find the true owner of the chattel AND
       there was not prior knowledge of the existence of the chattel

EXAMPLE Elwes v Brigg Gas (1886) 33 Ch D 562 PROVIDES
   the finder does not win ONLY IF
       the finder was the occupier of the premises AND
       the chattel was attached AND
       the non-finder was the owner of the real estate AND
       the non-finder was not the owner of the chattel AND
       there was not a bailment of the chattel AND
       there was a term in a lease which mentioned found items AND
       there was not a master-servant relationship between the parties AND
       the chattel was hidden AND
       there was an attempt to find the true owner of the chattel AND
       there was not prior knowledge of the existence of the chattel

EXAMPLE Hannah v Peel [1945] KB 509 PROVIDES
   the finder wins ONLY IF
       the finder was not the occupier of the premises AND
       the chattel was not attached AND
       the non-finder was the owner of the real estate AND
       the non-finder was not the owner of the chattel AND
       there was not a bailment of the chattel AND
       there was not a term in a lease which mentioned found items AND
       there was not a master-servant relationship between the parties AND
       the chattel was hidden AND
       there was an attempt to find the true owner of the chattel AND
       there was not prior knowledge of the existence of the chattel

EXAMPLE Corporation of London v Yorkwin [1963] 1 WLR 982 PROVIDES
   the finder does not win ONLY IF
       the finder was the occupier of the premises AND
       the chattel was attached AND
       the non-finder was the owner of the real estate AND
       the non-finder was not the owner of the chattel AND
       there was a bailment of the chattel AND
       there was a term in a lease which mentioned found items AND
       there was not a master-servant relationship between the parties AND
       the chattel was hidden AND
       there was an attempt to find the true owner of the chattel AND
       there was not prior knowledge of the existence of the chattel

EXAMPLE Moffatt v Kazana [1969] 2 QB 152 PROVIDES
   the finder does not win ONLY IF
       the finder was the occupier of the premises AND
       the chattel was not attached AND
       the non-finder was not the owner of the real estate AND
       the non-finder was the owner of the chattel AND
       there was not a bailment of the chattel AND
       there was not a term in a lease which mentioned found items AND
       there was not a master-servant relationship between the parties AND
       the chattel was hidden AND
       there was an attempt to find the true owner of the chattel AND
       there was prior knowledge of the existence of the chattel

EXAMPLE South Staffordshire Water Co v Sharman [1896] 2 QB 44 PROVIDES
   the finder does not win ONLY IF
       the finder was not the occupier of the premises AND
       the chattel was attached AND
       the non-finder was the owner of the real estate AND
       the non-finder was not the owner of the chattel AND
       there was not a bailment of the chattel AND
       there was not a term in a lease which mentioned found items AND
       there was a master-servant relationship between the parties AND
       the chattel was hidden AND
       there was an attempt to find the true owner of the chattel AND
       there was not prior knowledge of the existence of the chattel

EXAMPLE Yorkwin v Appleyard [1963] 1 WLR 982 PROVIDES
   the finder does not win ONLY IF
       the finder was not the occupier of the premises AND
       the chattel was attached AND
       the non-finder was not the owner of the real estate AND
       the non-finder was not the owner of the chattel AND
       there was not a bailment of the chattel AND
       there was not a term in a lease which mentioned found items AND
       there was a master-servant relationship between the parties AND
       the chattel was hidden AND
       there was an attempt to find the true owner of the chattel AND
       there was not prior knowledge of the existence of the chattel