Tahoe Final Wordfile

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 Justice Department of Computer & Information Systems Florida A & M University Tallahassee, Florida 32307, U.S.A. (bobbie@cis.famu.edu)
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 [owusuansah.agyapong@famu.edu, bobbie@famu.edu]
1. ABSTRACT
In this paper, we discuss a tool for eliciting 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)
The Design of an Expert System for Domain Knowledge Engineering and Decision Making: A Case Study in the Criminal Justice System
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 proofof-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
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
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 mo dels 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
(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
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 decisionmakers 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, specialprograms, Juvenile Alternative Services Program (JASP), community (e. g., bootcamps), or release.
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
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.
Elicitation of Software Requirements in Object-Oriented Format Main MENU 1. (U)pdate the knowledge-base 2. (A)dd to the knowledge-base 3. (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
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"
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 allows 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 knowledgebases. 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.
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
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 "felonyprevious-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 caserecorder 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.
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.
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 actiontype) to the next stage.
Adding Cases Update - Add Objects MENU 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." . What is the case-id? |: 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." . What is the case-id? |: case_54 . Describe the case. |: 'A 2d murder case.' Enter (list) all goals that the object is associated with. |: [ Adult-judicial-handling.]. Fig. 4 Add Cases - Cascaded Submenu
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
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. conceptualizing and capturing the interrelationships among cases in the KBS. establish the following propositions using the felony and misdemeanor relations.
Propositions aid in
By way of example, we
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.
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 nonsecured 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, if 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.
INTAKE CASES DISPOSED
NON-JUDICIAL HANDLING
NON-JUDICIAL JASP
JUDICIAL HANDLING
JUDICIAL JASP
DETENTION
COMMUNITY CONTROL
COMMITMENT 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.
Propositions: IC: JA: SC: FJ: MJ: AJ: FO: SO: RC1: RC2: RC3: MD: CS: CC: A case is handled/booked/referred is by the police A juvenile's attorney has reviewed the case A case is heard in the juvenile court (by the judge) A felonious case is recommended for a judicial-handling A misdemeanor case is recommended for a non-judicial-handling A case is moved to adult-adjudication stage A case is classified as first-offense A case is classified as second-or-multiple offense A case suggests a JASP treatment A case suggests bootcamp treatment A case is elevated to adult-offense A case is elevated to murder A conference-stage precedes adjudication CS before JC
Attributes:
JC: MS: FS:
The case requires judicial consideration A case is classified as murder A case is considered felonious
Axioms : CC |- CS -> JC SC |- IC ^ JA FO |- RC1 v MS v FS SO |- RC2 (1) (2) (3) (4)
Rules: (sample to be proved) SC, ~FJ ^ FO |- MJ -> RC1 FJ, CC, SO -> AJ |- RC2 v RC3 -> MD (Rule #1) (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
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 judicialstage, 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.
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 or operators). 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.
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 FJ, CC, SO -> AJ |- RC2 v RC3 -> MD (Rule1) (Rule2)
++++++++++++++++++++++++++++++++ 1. SC, ~FJ ^ FO |- MJ -> RC1 a: b: c: d: SC, ~FJ ^ FO |- ~MJ v RC1 SC, ~FJ , FO |- ~MJ, RC1 IC ^ JA, ~FJ, RC1 v MS v FS |- ~MJ, RC1 IC, JA, MJ, RC1 |- FJ, RC1 negate and reduce, using step W1 apply step W3 substitute axioms 2 and 3 apply step W4, then step W2 proved to be logically sound (only one of three possibilities)
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 communitybased ruling like JASP to the user (judge, attorney, etc.). Next, we proof Rule #2.
2. FJ, CC, SO -> AJ |- RC2 v RC3 -> MD a: b: c1:
apply step W1 apply step W3 apply step W4 apply step W2 proved unsound apply step W2 proved unsound
FJ, CC, (~SO v AJ) |- RC2 v (~RC3 v MD) FJ, CC, (~SO v AJ) |- RC2, ~RC3, MD FJ, CC, ~SO |- RC2, ~RC3, MD FJ, CC, RC3 |- RC2, MD, SO
c2:
FJ, CC, AJ |- RC2, ~RC3, MD FJ, CC, AJ, RC3 |- RC2, MD
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 proofstep 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 or proved, 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
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.
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 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. for
[9] Gillooly, C., "California Agency Works Net Magic with LAN," Network World, Vol. 9, No. 9, 1992, pp. 1315. [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.

Tahoe Final Wordfile

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Tahoe Final Wordfile

Uploaded by

Copyright:

Available Formats

The Design of an Expert System for Domain Knowledge Engineering and Decision Making: A Case Study in the Criminal

2. INTRODUCTION & BACKGROUND

3. METHODOLOGY 3.1 Sets of Case-Handlers, Case-Stages, and Case-Relations

3.2 Knowledge-base representation

4. CASE STUDY A Delinquency Case Flow

4.1 The Elicitation Subsystem

4.2 Add Propositions or Goals

Adding Goals or Factual Propositions Update - Add Propositions or Goals MENU

4.3 Add Cases

4.4 Add Attributes

4.5 Add Relations and Case-Handling Scenario

relation (case#78, felony, bootcamp). relation (case#7, misdemeanor, JASP).

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

INTAKE CASES DISPOSED

COMMITMENT TRANSTER TO ADULT COURT

Fig. 5 Delinquency Services Case Flow

JC: MS: FS:

Axioms : CC |- CS -> JC SC |- IC ^ JA FO |- RC1 v MS v FS SO |- RC2 (1) (2) (3) (4)

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

2. FJ, CC, SO -> AJ |- RC2 v RC3 -> MD a: b: c1:

FJ, CC, AJ |- RC2, ~RC3, MD FJ, CC, AJ, RC3 |- RC2, MD

FJ, CC, FJ, MD, RC3 |- RC2, MD

You might also like