Tahoe Final Wordfile

8/22/2019 Tahoe Final Wordfile

1/29

The Design of an Expert System for Domain Knowledge Engineering

and Decision Making:

A Case Study in the Criminal Justice System

Owusu-Ansah Agyapong and Patrick O. Bobbie

Department of Sociology and Criminal JusticeDepartment of Computer & Information Systems

Florida A & M University

Tallahassee, Florida 32307, U.S.A.

([email protected])

The Design of an Expert System for Domain Knowledge Engineering and

Decision Making: A Case Study in the Juvenile Justice System

Owusu-Ansah Agyapong*

Patrick O. Bobbie**

Florida A&M University

* Department of Criminal Justice and Sociology

** Department of Computer Information Sciences

Tallahassee, Tallahassee FL 32307

[[email protected], [email protected]]

1. ABSTRACT

In this paper, we discuss a tool for el iciting domain knowledge (specification) of a decision support system.

In particular, we focus on a decision support software system (DSS) which employs domain knowledge of

recidivism in the juvenile justice system. Using the elicited domain knowledge, the DSS tool uses deductive

reasoning techniques to make inferences and provide suggestive courses of action to support the

investigatory functions of police, attorneys, or probation officials. The motivation for developing the system

is manifold: 1) the activities of the officials are repetitive and their procedures mostly manual; 2)


2/29








([email protected])

investigations usually result in large volume of biographical data; 3) the need to link several, related case

files; 4) officials seldom have concurrent access to case files causing delays in resolving cases in the

court system; among others. Developing a software system to support the investigation and decision making

of criminal cases is in itself a daunting task, which makes the system specification a critical input to the

development process. Hence, the correctness of the resultant domain knowledge-base and the underlying

deductive/support system depends on logically consistent and sound methods. In the paper, we describe the

rationale for developing the DSS system, why we focus on the criminal (juvenile) justice system, the

methodology for eliciting DSS domain knowledge, and a scenario of what we are implementing as a proof-

of-concept system. A series of elicitation sessions which epitomize the DSS system have been discussed in the

article.

2. INTRODUCTION & BACKGROUND

Research results indicate the need for wide application of computer-based techniques, e.g., databases, neuron

networks, spreadsheets, and expert systems to problems in the criminal justice system (CJS) [6, 10, 15].

However, computer-based methodologies have not been a focus or researched extensively, and specifically,

in the area of juvenile justice system (JJS). By the Juvenile Justice Reform Act of 1994 in the state of Florida,

the legislature established a governmental department of juvenile justice system to address state-wide youth

criminality or recidivism. The DSS tool described in this paper is designed to support and enhance criminal


3/29








([email protected])

justice officials activities in recidivism. Such a tool is deemed necessary for police actions and, in particular,

probation officers in the conduct of their investigatory functions.

The focus of JJS, under the pressure of political mandates, has been on detention which has resulted in

building more detention facilities. The escalating cost of juvenile detention and the fear of the youth

developing into adult criminals (rise of recidivism) have caused the need for preventive measures [12]. Thus,

prevention is being pushed in order to curtail the propensity of juvenile criminality. Desistency theory

supports the notion that criminality of the youth usually increases during the early years and declines through

the aging process [11, 14]. The theory is supported by research data which indicate that of the 147,491

juvenile cases in the state of Florida, in 1995, 55% were judicially handled [7]. The data further suggest that

the youth is more likely to recidivate or mature into adult criminals. Experts place recidivism rate in the state of

Florida at about 70%. Hence, the current emphasis, e.g., in the state of Florida, is to find effective means to

mitigate this problem. It has been recognized that the extent of recidivism, and the lack of effective

mechanisms presently, would require some form of modeling and automation in dealing with juvenile

criminality.

The recidivism problem is a complex one. Investigatory functions of the police, probation officers, the court

system, and the legal profession typically involve a large number of personnel who more often than not

produce recorded reports. The procedures of these investigators are largely manual, often involving


4/29








([email protected])

numerous phone calls and recordings, and transcription of interviews into volumes of case records or files.

Some of the information often recorded/collected by the investigators include the age of the child, school

functioning, documented alcohol or drug use, documented criminal involvement by the child's family, child's

contact with environmental or chemical contaminants, and peer group of the child. Given the large volume of

data and variables, it usually takes, e.g., judges, attorneys, and probation officers weeks or months to review a

single criminal case before an action can be taken.

Studies have shown soaring crime rate and scarcity of beds for those incarcerated. The rise of the crime rate

has therefore focused public administrators'' attention in the justice system. Computer modeling for decision

making and analysis has proven to be of value to administrators who must make long term capital and public

decision regarding the disposition of the burgeoning of the (juvenile) prison population [6, 9, 13, 15].

The great need for automation in public decision making, bureaucracy, public accountability, effectiveness

and efficiency, and productivity concerns has made computer database management systems an imperative.

Moreover, effective and quality management of governmental municipalities is hinged upon automated or

computer-based models and data analysis. For example, the application of neuron networks in modeling

recidivism, which correctly differentiated recidivist from non-recidivists in 99 percent of cases, is reported in

[6]. In another setting, an expert system was applied to enhance clinical service activity [10]. In the research

reported in this paper, we are developing a suite of methodologies to build a domain knowledge-based system


5/29








([email protected])

(KBS) in support of decision making needs of JJS administrators and officials. The emphasis is on recidivist

activities in response to the current drive and focus in the JJS of Florida.

Formal methods for knowledge-based representation [1, 5]; checking omissions, inconsistencies, and

ambiguities [2, 3]; structuring and modeling [2]; and decomposing specification into "subspecs" to reduce

complexity [4] facilitate the development of prototypes for rapid and early demonstration of such software

systems. To this end, complementary methods from first-order logic, set theory, and relation theory are

integrated as a framework for eliciting the DSS domain knowledge. The synthesis approach to compiling the

DSS specs from the knowledge-base employs transitivity property of the underlying relations. By using an

executable specification language like PROLOG for implementation, either compiled or interpreted [8], the

resultant system is expected to be an inference system which would faithfully support JJS investigatory and

decision-making functions.

The rest of the paper is organized as follows. In section 3, we discuss the underlying methods and techniques

of the elicitation system. Section 4 is a demonstration of a series of elicitation sessions and interfaces of the

elicitation tool as viewed and used by the analyst and case-handling team. In Section 5, we conclude the

discussion of the methodologies by way of a case study of juvenile -case handling in the JJS. We focus on the

inference subsystem and its proof-procedure. The two together ensure the use of validated cases/arguments


6/29








([email protected])

and factual data established in the JJS knowledge-base for decision making. The figures in the paper are

examples of the elicitation sessions of the DSS. We then draw some conclusions to the paper.

3. METHODOLOGY

3.1 Sets of Case-Handlers, Case-Stages, and Case-Relations

In developing a decision-support software for most systems, it is important that the key persons involved in

the decision process be listed or identified in the system's knowledge-base. The JJS involves such decision-

makers as family members, probation officers, police, judges, attorneys, the juvenile delinquents, Health &

Rehabilitative Services (HRS) personnel, the school system, social workers, criminologists, psychologists,

among others. These individuals (or groups) make up the set of decision-makers whose complementary roles

help in arriving at a recommendation for each juvenile case.

Most JJS cases undergo various stages, beginning with the intake stage. Once a case review is initiated, it is

recommended for a conference stage, where a panel of review persons, usually from the community, considers

the case for the next stage. Other case-stages may include judicial-handling, non-judicial-handling, special-

programs, Juvenile Alternative Services Program (JASP), community (e. g., bootcamps), or release.


7/29








([email protected])

A typical juvenile justice case on a delinquent child goes through several stages during its processing. A

transition from one stage to another requires input and criteria needed by the decision-makers, e. g., judges.

Such criteria influence the transitioning process to the next stage. The relationships between 'pairs' of stages

constitute a set of case-relations, which forms a critical component of the DSS. We represent case-relations

by such 'influencing' factors as severity or nature of crime (e.g., felony or misdemeanor), victim-involvement,

advocacy groups or public-political-pressure, community-sentiments, and the like.

3.2 Knowledge-base representation

The sets of decision-makers, case-relations, and case-stages are elicited and stored in a JJS KBS. Each case is

then described in details: handling, stages, influencing criteria or factors, decisions, and recommendations.

Once done, each case history in the KBS provides a situational information for future tracking/monitoring and

decision-making when a repeat-offense case comes to the JJS. We employ formalisms of first-order logic in

defining a syntactic framework ( la PROLOG): facts and rules, and a semantic framework: transitive reasoning

[16] in establishing the core KBS of the DSS.

To analyze a case, the user queries the DSS (along with some new facts, if any). The DSS in turn consults the

underlying KBS using deductive reasoning (forward-chaining / backward-chaining) to deduce conclusions


8/29








([email protected])

from the stored facts and rules. For example, a judge needs to decide what action to take on a juvenile case.

We assume the KBS holds information about a previous offense of the juvenile. Under the influence of

politically motivated pressure, the judge submits some new facts related to this pressure to the DSS. Using

this new info, and the established data in the KBS, the DSS then assists the judge in arriving at a reasonable,

objective decision. We focus on this simple example, to demonstrate the utility of the JJS DSS project which is

under development.

4. CASE STUDY A Delinquency Case Flow

4.1 The Elicitation Subsystem

The elicitation subsystem utilizes a menu-driven interface (see Fig. 1). The elicitation steps are described and

illustrated in the following figures. The figures depict the various computer screens (under development using

Tcl/Tk GUI and a PROLOG environment) as viewed by the domain knowledge analyst and the JJS case

decision-maker during the elicitation sessions. Each menu option in Fig. 1 is explained below.


9/29








([email protected])

Elicitation of Software Requirements in

Main MENU

1. (U)pdate the knowledge-base

2. (A)dd to the knowledge-base3. (S)ave the knowledge-base

4. (D)isplay the entire knowledge-base

5. (C)lear this knowledge-base

0. Exit

Enter # or letter followed by a "." >___

Fig. 1 Main Menu Interface

Object-Oriented Format

Update the Knowledge-base:

The Update option allows the case-recorder to enter data describing the juvenile. Additional options

(explained below in more details) under the Update option allow the elicitation of system information from

scratch, or the addition of new information to what is already in the knowledge-base.

Add to the Knowledge-base:

The Add option allows a case-handler to load the contents of a previously saved elicitation session into

memory. A directory listing of PROLOG knowledge-bases in the current directory is typically shown under the

"Add" option. The case-recorder may select or type the filename of a knowledge-base with or without a "pdb"


10/29








([email protected])

extension. When selected, the appropriate '.pdb' file is loaded and added to the active knowledge-base in

main memory.

Save the Knowledge-base:

The Save option al lows the case-recorder or user to save information in the current knowledge-base into a file.

The user may quit at mid-session, save, and resume the elicitation process later through the "Add" option.

The "Save" option also permits the merging of other independently related knowledge-bases, thus, making it

possible to merge the case-histories (or attributes) from previous cases with current cases. The "Save" and

"Add" options also allow the characteristics and behavior-patterns (from previous cases) of the juvenile to

persist across session boundaries in time.

The Update option of the main menu is the major component of the elicitation procedure. The remaining

options in the Main Menu, in Fig. 1., are used as support procedures for revising the resultant knowledge-

bases. Fig. 2 depicts the four main options (1 to 4) under the Update option; in addition are two other options

(5 and 6) for revising the "relationships" between various cases or a single case involving several juveniles. It

should be noted that option 2 (Add cases), in Fig. 2, also implements a cascaded sub-menu which is displayed

for further menu selections. The cascaded sub-menu essentially implements an underlying recursive structure

of the elicitation system.


11/29








([email protected])

4.2 Add Propositions or Goals

Propositions, or "goals," are a mechanism for defining factual relationships among cases and case-relations.

The format of a goal inquiry is a simple query which has a single atom or singly quoted sentence fragment

as its response. Fig. 3 illustrates two simple goal queries. The elicited goals are stored in an internal

knowledge-base, and numbered in the order elicited from the end-user.

Update Knowledge-Base

Update MENU

1. Add propositions or goals [assign system goals]

2. Add objects [establish objects] --

3. Add attributes [establish attributes]

4. Add relations [assign relations to new objects]

5. Re-relate objects [reassign relations]

6. Re-elicit [clear and redo current session]

0. Exit

Enter # followed by a "." >___

Fig. 2 Update Menu


12/29








([email protected])

The elicitation system requires each case in the knowledge-base to have an associated goal or a list of goals.

From Fig. 3, the first goal query establishes "case-id" as Goal #1, and the second query establishes "felony-

previous-recommendation" as Goal #2.

At the conceptual level, goals also characterize the juvenile behavior (or actions) and characteristics or

personality traits that aid in decision-making. In our system, theorems are considered as complex

propositions, or goals, and could entail complex descriptions of cases, or juveniles, in the DSS software

system. The "Add propositions or goals" option is for incremental construction of such theorems. The case-

recorder is only required to enter concise and meaningful descriptions of the major goals related to each case.

The goals are also viewed as the major decision-points which establish a basis for final recommendation of the

case-handler.


13/29








([email protected])

Adding Goals or Factual Propositions

Update - Add Propositions or Goals MENU

Enter a goal of the system. [or "0." to quit]

|: ' case-id '.

Enter a goal of the system. [or "0." to quit]

|: ' felony-previous-recommendation '.

Fig. 3 Add Props/Goals SubMenu Interface

4.3 Add Cases

The elicited cases constitute the foundational or basic elements of the knowledge-base. The "Add cases"

option in Fig. 2 offers a simplified framework for viewing the DSS software system as a collection of cases and

case-handling actions. A simple query is used to elicit case-id, description, and a set of goals related to the

case. By way of example, Fig. 4 depicts a simple scenario, or query session, during which cases and case data

are elicited.


14/29








([email protected])

When the "Add cases" session is completed, the resultant knowledge-base would typically contain each case

id, description, and a list of goals "influenced by" or related to the case. The cases themselves, however, are

passive and can not be "enacted" until they are bound by some contextual binary relation(s) (see Section 4.5

under "Add Relations" option). Enacting a case effects its processing and recommendation (or action-

type) to the next stage.


15/29








([email protected])

Adding Cases

Update - Add Objects MENU

Fig. 4 Add Cases - Cascaded Submenu

If you are done, enter "0.".

What is the case-id?

|: case_78.

Describe the case.

|: 'A felonious case.' .

Enter (list) all goals that the case is associated

with.

|: [bootcamp, political].

If you are done, enter "0." .


|: case_7.Describe the case.

|: 'A misdemeanor case.' .

Enter (list) all goals that the object is associated

with.

|: [JASP, victim].

If you are done, enter "0." .


|: case_54 .

Describe the case.

|: 'A 2d murder case.'

Enter (list) all goals that the object is associated

with.|: [ Adult-judicial-handling.].


16/29








([email protected])

4.4 Add Attributes

Attributes are descriptive and used to define cases. Attributes also facilitate the creation of association among

related cases. By our definition, an attribute, or property, could also be a case. Attributes of a case-type

establish case-case relationships due to possible interrelationships among cases. Thus, attributes can take

one of the following forms:

Case-type: is treated as cases and may possess further attributes of their own.

Character-type: defines the personality trait possessed by the juvenile under discourse.

Action-type: defines the "actions" that the juvenile performed in prior situations.

The "Add attributes" option provides a mechanism for recursively eliciting more refined information about

cases.

4.5 Add Relations and Case-Handling Scenario


17/29








([email protected])

The "Add relations" option allows the case-recording team to bind cases with contextual binary relations in

the internal knowledge-base [2]. Relational binding, or matching, is a mechanism for describing the roles and

interactions of the cases, or juveniles, as envisioned by the case-handler. The process of relating cases by

matching them against a set of relations can be tedious and time-consuming if there are more than a few cases

or juveniles involved in a single case. A search/backtracking or "pruning" procedure is used to avoid

redundancies and recursive (circuitous) matching of cases and the relations [1]. The transitive closure

property of the relations also allows automatic derivation of additional implicit associations, which effectively

eliminates potential explosion due to explicit pair-wise matching. The contextual (binary) relations are verbs, or

phrases, which describe the associations a case could have with other cases.

In the simple, basic format, the relationships are represented as propositions. Propositions aid in

conceptualizing and capturing the interrelationships among cases in the KBS. By way of example, we

establish the following propositions using thefelony and misdemeanor relations.

relation (case#78,felony , bootcamp).

relation (case#7, misdemeanor, JASP).

The first relation indicates that case#78, which was recommended for bootcamp (case-action), was felonious.

The second relation states that case#7, which was recommended for JASP (case-action), was a misdemeanor.


18/29








([email protected])

Suppose a case-handler, e.g., a judge, were to make a recommendation on a new case, case#54, by consulting

the DSS, a recommendation can be made based on the "relatedness" of the fact/rules of the prior two cases (#7

and #78) to the new case, #54. While the judge is consulting the DSS, a defense attorney for the client

(juvenile) could be using the same DSS KBS simultaneously to derive new facts which he/she could use to

sway or influence the judge's conclusion: i.e., from bootcamp to a recommendation to any secured or non-

secured facility based on prior, strong evidence (as stored in the KBS). Currently, such flexibility and

efficiency due to concurrent access to the KBS is lacking in the JJS information processing procedures.

5: A DELINQUENCY CASE-HANDLING Formal Methods for Decision-Making

In this section, we illustrate our approach to developing an inference systems for decision support in the JJS.

Figure 5 depicts a typical case flow in the JJS which was excerpted from the delinqency case and youth

disposition document [7]. The figure depicts cases that come into the JJS through various intake centers. The

cases are classified into two processes: non-judicial and judicial, after going through the detention centers.

The junvenile court system focuses on the two judicial processes, where judges decide, at their discretion

based on the seriousness of the crime and strength of evidence, i f cases must go to either one of the two JASP

programs, the community control, or commitment (e.g., bootcamp). A case can also be directed to the adult

court for the more serious or politically motivated cases.


19/29








([email protected])

INTAKE CASES

DISPOSED

NON-JUDICIAL

HANDLING

NON-JUDICIAL

JASP

JUDICIAL

JASP

COMMUNITY

CONTROL

COMMITMENT

DETENTION

JUDICIAL

HANDLING

TRANSTER TO

ADULT COURT

Fig. 5 Delinquency Services Case Flow

To illustrate, let the following propositions constitute a set of facts and rules, or specification, governing a

delinquency case which we have used as an example in Section 4.5.


20/29








([email protected])

Propositions:

IC: A case is handled/booked/referred is by thepolice

JA: A juvenile's attorney has reviewed the case

SC: A case is heard in the juvenile court (by thejudge)

FJ: A felonious case is recommended for ajudicial-handling

MJ: A misdemeanor case is recommended for a non-judicial-handling

AJ: A case is moved to adult-adjudication stage

FO: A case is classified as first-offense

SO: A case is classified as second-or-mul tipl e offense

RC1: A case suggests a JASP treatment

RC2: A case suggests bootcamp treatment

RC3: A case is elevated to adult-offense

MD: A case is elevated to murder

CS: A conference-stageprecedes adjudication

CC: CS before JC

Attributes:


21/29








([email protected])

JC: The case requires judicial consideration

MS: A case is classified as murder

FS: A case is considered felonious

Axioms:

CC |- CS -> JC (1)

SC |- IC ^ JA (2)

FO |- RC1 v MS v FS (3)

SO |- RC2 (4)

Rules: (sample to be proved)

SC, ~FJ FO |- MJ -> RC1 (Rule #1)

FJ, CC, SO -> AJ |- RC2 v RC3 -> MD (Rule #2)

The ^, v, ~, ->, |- are respectively the AND, OR, NOT, Implication, and Conclusion logical operators. The first

axiom stipulates that a case must go to a conference stage before it can be considered for judicial treatment.

The second axiom indicates that if a case is heard by a juvenile judge, then it must have been referred by the


22/29








([email protected])

police, assessed by delinquency case management counselors, and/or reviewed by the juvenile's attorney.

The third and fourth axioms simply assign attributes to a case. The two axioms also illustrate a method for

categorizing a case, with respect to its recommendation. Such categorization is often assumed in the JJS,

where certain offenses are said to fall under presumed classes of punishment.

The first rule places a claim that whenever a case is not felonious, but found to be a misdemeanor, perhaps it

could be recommended for JASP treatment. The second rule poses a question: if a case reaches a judicial-

stage, what action can be taken or what recommendation need to be made? This question calls for several

scenarios and depends on the seriousness of the offense. Suppose we endow the expert system with

sufficient knowledge, we expect a recommendation to be inferred with a high degree of confidence. If it is

further investigated and found to be a murder committed by the juvenile, could we (the judge or court) draw

some conclusion here? In the following, we prove the soundness (or unsoundness) of both rules to

demonstrate the utility of the inference subsystem of the DSS for decision-making or ruling.

Below is a theorem-proving (analysis) of the above specification. (Due to space limitation, only the above two

logical statements, or rules, would be used to illustrate the proof procedure.) In general, however, a complete

system specification would include hundreds of such axiomatic (or factual) and rule-based specification. We

adapt and extend (by introducing De Morgan's laws) Wang's [2] theorem-proving algorithm to illustrate the

proof procedure.


23/29








([email protected])

Extended Wang's Procedure

The algorithm takes well-formed-formulae (wff), like statements (1) and (2), connected by and's or commas.

W1. Convert all implications, (x -> y), in the wffs to the equivalent, (~x v y), except the conclusion operator.

Convert all negated implications using DeMorgan laws.

W2. Transpose all negated wffs (this action removes the ~ signs). E.g., (~x, y |- z) becomes (y |- z, x) and (~x, y

|- ~z) becomes (y, z |- x).

W3. Replace the and (^) operators in the wffs on the left-hand-side and the or (v) operators in the wffs on the

right-hand-side of the (|-) operator with a comma, respectively. E.g., (x y) |- (x v z) becomes (x,y) |- (x,z).

W4. If there is an or (v) operator in a wff on the left-hand-side and an and (^) binary operator in the wff on the

right-hand-side of the (|-) operator, decompose/split each such wff into two sub-wffs by distributing the

original propositions over the (|-) operator (this action drops out the and and the oroperators). For example,

(x v y) |- z becomes i) x |- z and ii) y |- z

x |- (y ^ z) becomes i) x |- y and ii) x |- z.


24/29








([email protected])

W5. Reapply steps W1 - W4 until each wff is reduced, i.e., the propositions in the wffs on both sides of the (|-)

operator are separated by only commas. Prove each reduced (or expanded) wff by showing that at least one

wff appears on both sides of the (|-) operator. E.g., x,y,z |- y, is proved; and x,y,z |- w, is not proved.

Proofs: (W1 - W5 are the steps of the algorithm)

We restate the JJS knowledge-base specification as follows

.

SC, ~FJ ^ FO |- MJ -> RC1 (Rule1)

FJ, CC, SO -> AJ |- RC2 v RC3 -> MD (Rule2)

++++++++++++++++++++++++++++++++

1. SC, ~FJ FO |- MJ -> RC1 negate and reduce, using step W1

a: SC, ~FJ FO |- ~MJ v RC1 apply step W3

b: SC, ~FJ , FO |- ~MJ, RC1 substitute axioms 2 and 3

c: IC JA, ~FJ, RC1 v MS v FS |- ~MJ, RC1 apply step W4, then step W2

d: IC, JA, MJ, RC1 |- FJ, RC1 proved to be logically sound

(only one of three possibilities)


25/29








([email protected])

Proving the logical soundness of Rule 1 indicates that if a case is booked, reviewed by the defense attorney,

heard in court and deemed a first offense, then it would pass as either a misdemeanor or a felony. Having

established this fact, the next step is to gather additional information about the case. But the proof procedure

also suggests that the case is clearly a first-offense (by having RC1 on both sides of the |- operator as the

basis of the proof). In this regards, and based on axiom 3, a first-offense case calls for a JASP treatment.

Thus, the DSS can facilitate in the analysis of the claim (as embodied in Rule #1), and suggest a community-

based ruling like JASP to the user (judge, attorney, etc.). Next, we proof Rule #2.

2. FJ, CC, SO -> AJ |- RC2 v RC3 -> MD apply step W1

a: FJ, CC, (~SO v AJ) |- RC2 v (~RC3 v MD) apply step W3

b: FJ, CC, (~SO v AJ) |- RC2, ~RC3, MD apply step W4

c1: FJ, CC, ~SO |- RC2, ~RC3, MD apply step W2

FJ, CC, RC3 |- RC2, MD, SO proved unsound

c2: FJ, CC, AJ |- RC2, ~RC3, MD apply step W2

FJ, CC, AJ, RC3 |- RC2, MD proved unsound


26/29








([email protected])

If we axiomatize that, AJ |- FJ v MD, thus, when a case is moved to adult adjudication, then it ought to be

either felonious or a misdemeanor. Under this circumstance, we modify the proof process and restate proof-

step c2 of Rule #2 above as (by substituting AJ |- FJ, MD on the left-hand-side):

c2': FJ, CC, FJ, MD, RC3 |- RC2, MD proved sound

Here, the proof procedure suggests that the case is possibly a murder and, therefore, the claim (embodied in

Rule #2) is logically correct. Where this assumption is replaced by one which is due to external factors, e.g., a

politically motivated pressure on the case, a similar conclusion can be arrived at. For example, in proof-step c2

(Rule #2), if we replace the RC3 by propositions MD or FJ because the public is politicizing the elevation of the

case to an 'adult' offense status, then a judge's ruling or an attorney's recommendation can be swayed in such

a direction. This will then make the proof-step also sound, as demonstrated under step c2'. However, because

an expert system's inference capability must be based on domain knowledge, or facts, external factors which

are based on political pressure, sentiments, and the like are not supported in our system.

For a rule (specification) to be sound orproved, it must have at least one proposition appearing on both sides

of the '|-' operator. Failure to proof the logical soundness of all sub-statements of any given statement, renders

the entire statement in question unsound. In the above analysis, proof-step 1d (for Rule #1) indicates a

proven or sound statement. Consequently, the specification (Rule #1) is said to be logically sound. Because


27/29








([email protected])

both statements c1 and c2, under Rule #2, are unsound, they suggest that a stronger ruling or recommendation

can't be fairly made. The additional information about the nature of the offense makes statement c2' (under

Rule #2) logically sound and supportive of any meaningful ruling or consideration.

6. CONCLUSION

A DSS for eliciting information pertaining to case-handling, case-actions, and case-stages of juvenile

criminality in a typical (e.g., the Florida) JJS, has been described. The menu-driven characteristic of the

elicitation system, coupled with the underlying propositional calculus, facilitates and simplifies the complexity

of the elicitation process. The resultant specification is viewed as a collection of associations of juvenile

cases, case histories, case-relations, and case-attributes. The associations, or relationships, in turn prescribe

the case-actions and case-stages. A major part of the elicitation system is implemented in PROLOG; with the

case-elicitation interface currently under development using Tcl/Tk tool. In this article, we have shown, by

way of examples, the inference or deductive capability of the DSS in support of decision-making on case

information in the DSS's knowledge-base. Such a capability is demonstrated through a proof-procedure,

which is essentially a theorem-proving system. The implementation of the system currently serves as a

testbed for modeling and prototyping a DSS for handling cases in a JJS.


28/29








([email protected])

REFERENCES

[1] Bobbie, P. O. and Papazoglou, M. P., "Clustering PROLOG Programs for Distributed Computations," The

Journal of Systems and Software, Amsterdam, North-Holland, U.S.A., Vol. 16, No. 3, 1991, pp. 205-218.

[2] Bobbie, P. O., "Automatic, Rapid Generation of Design Prototypes from Logic Specifications,"

International Journal of Software Engineering and Knowledge Engineering, Vol. 1, No. 4, 1991, pp. 331-350.

[3] Schneider, G. M., Martin, J., and Tsai, W. T., "An Experimental Study of Fault Detection in

User Requirements Documents,"ACM Transactions on Software Engineering and Methodology, Vol. 1., No.

2, 1992, pp. 188-204.

[4] Bobbie, P. O. and Urban J. E., "A Methodology for Understanding the complexities of Developing Large-

Scale Software Systems,"Journal of Data and Knowledge Engineering, Amsterdam, North-Holland, 1991.

[5] Borgida, A., Greenspan, S., and Mylopolous, J., "Knowledge Representation as the Basis for

Requirements Specifications," Computer, April 1985, pp. 82-90.

[6] Brodzinski, J. D., Crable, E. A., and Scherer R. F., "Using Artificial Intelligence to Model Juvenile

Recidivism Patterns," Computers in Humans Services, Vol. 10, No. 4, 1994, pp. 1-18.

[7] Bureau of Research and Data, Delinquency Case and Youth Disposition Flowcharts , Fiscal Year 1993/94

Statewide and DJJ Service Districts Report, Florida Department of Juvenile Justice, May 1995.

[8] Cooke, D., "A PROLOG Interpreter," Private Communication.


29/29








([email protected])

[9] Gillooly, C., "California Agency Works Net Magic with LAN,"Network World, Vol. 9, No. 9, 1992, pp. 13-

15.

[10] Goodman, H., Gingrich, W. J., and de Shazer, S., "BRIEFER: An Expert System for Clinical Practice,"

Computers in Human Services, Vol. 6, pp. 53-68.

[11] Jefferey, C. R., Criminology: An Interdisciplinary Science, Wardsworth Pub., St. Paul, MN, 1990.

[12] Juvenile Justice Advisory Board, 1994 Annual Report and Fact Book, Tallahassee, Florida, p. 168

[13] Shapira, M., "Computerized Decision Technology on Social Services: Decision Support System Improves

Decision Practice in Youth Probation Service,"International Journal of Sociology and Social Policy , Vol. 10,

No. 4-6, pp. 138-164.

[14] Siegel, L., Criminology, West Pub., Indianapolis, IN, 1995.

[15] Valasquez, J., "GAIN: A Logically-based Computer System which Successfully Supports Line Staff,"

Administration and Social Work, Vol. 16, No. 1, 1992, pp. 41-54.

[16] Bobbie, P. , Anger, F., Rodriguez, R., "Validating Relationships in Real-Time Software Object

Specifications: A Methodology," Proceedings of the First Software Engineering Research Forum, Tampa,

Florida, Nov. 7-9, 1991, pp. 75-87.

Date post:	08-Aug-2018
Category:	Documents
Upload:	suvir-misra
View:	222 times
Download:	0 times