<%BANNER%>

ETKnet

Permanent Link: http://ufdc.ufl.edu/UFE0021359/00001

Material Information

Title: ETKnet A Distributed Event- and Rule-Based System for Knowledge Sharing in a Collaborative Federation
Physical Description: 1 online resource (157 p.)
Language: english
Creator: Degwekar, Seema P
Publisher: University of Florida
Place of Publication: Gainesville, Fla.
Publication Date: 2007

Subjects

Subjects / Keywords: collaboration, distributed, event, heterogeneity, interoperation, knowledge, rule, web
Computer and Information Science and Engineering -- Dissertations, Academic -- UF
Genre: Computer Engineering thesis, Ph.D.
bibliography   ( marcgt )
theses   ( marcgt )
government publication (state, provincial, terriorial, dependent)   ( marcgt )
born-digital   ( sobekcm )
Electronic Thesis or Dissertation

Notes

Abstract: Enabling government organizations to solve complex global problems such as illegal immigration, border control, and terrorism or business organizations to maintain a globally competitive edge, requires these organizations to collaborate and share not only data and application system resources, but also knowledge that captures organizational and inter-organizational policies, constraints, regulations, processes and procedures. In our study, we focus on the research and development of a knowledge specification language and the techniques, algorithms, system and infrastructure for the sharing of knowledge among collaborating organizations. We represent knowledge using three types of rules: condition-action-alternative-action rules, logic-based derivation rules, or integrity constraints, and structures of these rules. We introduce an XML-based language that enables the specification and sharing of multi-faceted knowledge. Collaborating organizations can specify events of importance, data associated with those events, and rules and rule structures that should be triggered upon the occurrences of those events. We develop a distributed event- and rule-based system called ETKnet for event notification, event data transmission and aggregation, and processing of distributed rules, rule structures, triggers, automated application system operations and manual operations. Data associated with an event occurrence and generated by triggered rules, rule structures and automated/manual operations can thus be shared and used by collaborating organizations for their decision-making and problem-solving. Our approach to achieve the interoperation of heterogeneous rules is to translate rules and rule structures into program code and wrap them as web services for their uniform representation, discovery and invocation in a web service infrastructure. This dissertation presents the system architecture, the distributed event and rule processing strategy, algorithms used for the translation of heterogeneous rules and rule structures into web services, implementation details, and issues and solutions related to event data aggregation, conflicting rules, and cyclic rules.
General Note: In the series University of Florida Digital Collections.
General Note: Includes vita.
Bibliography: Includes bibliographical references.
Source of Description: Description based on online resource; title from PDF title page.
Source of Description: This bibliographic record is available under the Creative Commons CC0 public domain dedication. The University of Florida Libraries, as creator of this bibliographic record, has waived all rights to it worldwide under copyright law, including all related and neighboring rights, to the extent allowed by law.
Statement of Responsibility: by Seema P Degwekar.
Thesis: Thesis (Ph.D.)--University of Florida, 2007.
Local: Adviser: Su, Stanley Y.
Local: Co-adviser: Lam, Herman.

Record Information

Source Institution: UFRGP
Rights Management: Applicable rights reserved.
Classification: lcc - LD1780 2007
System ID: UFE0021359:00001

Permanent Link: http://ufdc.ufl.edu/UFE0021359/00001

Material Information

Title: ETKnet A Distributed Event- and Rule-Based System for Knowledge Sharing in a Collaborative Federation
Physical Description: 1 online resource (157 p.)
Language: english
Creator: Degwekar, Seema P
Publisher: University of Florida
Place of Publication: Gainesville, Fla.
Publication Date: 2007

Subjects

Subjects / Keywords: collaboration, distributed, event, heterogeneity, interoperation, knowledge, rule, web
Computer and Information Science and Engineering -- Dissertations, Academic -- UF
Genre: Computer Engineering thesis, Ph.D.
bibliography   ( marcgt )
theses   ( marcgt )
government publication (state, provincial, terriorial, dependent)   ( marcgt )
born-digital   ( sobekcm )
Electronic Thesis or Dissertation

Notes

Abstract: Enabling government organizations to solve complex global problems such as illegal immigration, border control, and terrorism or business organizations to maintain a globally competitive edge, requires these organizations to collaborate and share not only data and application system resources, but also knowledge that captures organizational and inter-organizational policies, constraints, regulations, processes and procedures. In our study, we focus on the research and development of a knowledge specification language and the techniques, algorithms, system and infrastructure for the sharing of knowledge among collaborating organizations. We represent knowledge using three types of rules: condition-action-alternative-action rules, logic-based derivation rules, or integrity constraints, and structures of these rules. We introduce an XML-based language that enables the specification and sharing of multi-faceted knowledge. Collaborating organizations can specify events of importance, data associated with those events, and rules and rule structures that should be triggered upon the occurrences of those events. We develop a distributed event- and rule-based system called ETKnet for event notification, event data transmission and aggregation, and processing of distributed rules, rule structures, triggers, automated application system operations and manual operations. Data associated with an event occurrence and generated by triggered rules, rule structures and automated/manual operations can thus be shared and used by collaborating organizations for their decision-making and problem-solving. Our approach to achieve the interoperation of heterogeneous rules is to translate rules and rule structures into program code and wrap them as web services for their uniform representation, discovery and invocation in a web service infrastructure. This dissertation presents the system architecture, the distributed event and rule processing strategy, algorithms used for the translation of heterogeneous rules and rule structures into web services, implementation details, and issues and solutions related to event data aggregation, conflicting rules, and cyclic rules.
General Note: In the series University of Florida Digital Collections.
General Note: Includes vita.
Bibliography: Includes bibliographical references.
Source of Description: Description based on online resource; title from PDF title page.
Source of Description: This bibliographic record is available under the Creative Commons CC0 public domain dedication. The University of Florida Libraries, as creator of this bibliographic record, has waived all rights to it worldwide under copyright law, including all related and neighboring rights, to the extent allowed by law.
Statement of Responsibility: by Seema P Degwekar.
Thesis: Thesis (Ph.D.)--University of Florida, 2007.
Local: Adviser: Su, Stanley Y.
Local: Co-adviser: Lam, Herman.

Record Information

Source Institution: UFRGP
Rights Management: Applicable rights reserved.
Classification: lcc - LD1780 2007
System ID: UFE0021359:00001


This item has the following downloads:


Full Text





ETKnet: A DISTRIBUTED EVENT- AND RULE-BASED SYSTEM FOR KNOWLEDGE
SHARING IN A COLLABORATIVE FEDERATION






















By

SEEMA DEGWEKAR


A DISSERTATION PRESENTED TO THE GRADUATE SCHOOL
OF THE UNIVERSITY OF FLORIDA IN PARTIAL FULFILLMENT
OF THE REQUIREMENTS FOR THE DEGREE OF
DOCTOR OF PHILOSOPHY

UNIVERSITY OF FLORIDA

2007




































O 2007 Seema Degwekar

































To my husband and best friend, Nikhil









ACKNOWLEDGMENTS

During my years of graduate study here, I have received support from many people in

many different ways. First of all, I would like to thank my advisor, Dr. Stanley Y. W. Su, who

has been a perfect mentor. I feel extremely fortunate to be advised by him. Through his

association, I have not only picked up valuable technical expertise, but also important personality

traits such as determination, perseverance, and focus on the task-at-hand. He has shown infinite

patience with me, for which I will be eternally grateful.

I would also like to thank Dr. Herman Lam, Dr. Stephen Thebaut, Dr. Christopher

Jermaine, and Dr. Howard Beck for being a part of my PhD committee.

On the personal front, I thank my husband, Nikhil, without whose support, I would have

never completed this very important step in my life. He has always been there, whenever and

wherever I needed him. I am very grateful for my parents, Lata and Pradeep, and my brother,

Sachin who have supported me in all possible ways. I would also like to thank my mother-in-

law, Smita, and my sister-in-law, Swati for their encouragement and appreciation.

Big thanks go to all my colleagues in the Database Center. Special thanks to Subi,

Shantanu, and Abhijit for the many lunches, coffees, stimulating conversations, and great advice!

I would also like to acknowledge Gillican, Laukik, Padma, Xuelian, Alexandra, Jayendra,

Jungmin, Sanghyun, Florin, Alejandro, Mark, Jeff, Mingxi, Oguzhan, Reasey, Brian, Manas, and

Manna for making the lab a great place to work.

I would like to thank Alina, Andres, Raazia, Padma, and Sameep for their enthusiasm and

efforts with ASCIE. I would especially like to thank Pedro, James, and Alok for helping me

kick-start the organization. I would also like to thank the CISE administration and staff for all the

help they have given to me as well as to all students. Very special and heartfelt thanks go to Amy









for her constant support, and great involvement in student affairs. We are very lucky to have

such a wonderful graduate advisor.

I would also like to acknowledge Debra Anderson, Maud, and all the other great folks at

the International Center for helping us international students with all sorts of things. Finally, I

would like to thank all of my friends and family who have always cheered me on.












TABLE OF CONTENTS


page

ACKNOWLEDGMENT S .............. ...............4.....


LI ST OF T ABLE S ............ ...... .__ ...............9....


LIST OF FIGURES .............. ...............10....


AB S TRAC T ............._. .......... ..............._ 1 1..


CHAPTER


1 INTRODUCTION .............. ...............13....


2 RELATED WORK ..........._..._ ...............19.......__......


Rule M arkup Languages ..........._...._ ................ ...............19.....
Simple Rule Markup Language (SRML) .............. ...............19....
Business Rules Markup Language (BRML) .............. ...............19....
Rule Markup Language (RuleML) ................. ...............20................
Extensible Rule Markup Language (XRML) ................ ...............20........... ...
Other Markup Languages ................. ...............20................
Event- and Rule-Based Systems ................. ...............21................
Event-based Systems .............. ...............21....
Rule-based Systems ................. ...............21.................
Rule Interoperability ................. ...............23.......... ......
E-DEVICE ................. ........ .... ............ .............2
Service-Oriented Business Rules System ................. ...............24................
Rule Interchange Format .............. ...............25....

3 KNOWLEDGE SPECIFICATION LANGUAGE .............. ...............27....


Integrity Constraints .............. ...............28....
Derivation Rules ................. ...............3.. 1..............
Action-oriented Rules ................. ...............32.................
R ule Structure ...................... ... ... .. .. ... ..................3

Examples of Rules and Rule Structures from Two Application Domains ................... ..........3 5
EU-Rent Car Rental Company ........................ .. ...... ....................3
Example Rules and Rule Structure from the EU-Rent Rule Set .................. ...............37
Example Rule 1 .............. ...............37....
Example Rule 2 .............. ...............37....
Example Rule 3 .............. ...............39....
Example Rule Structure .............. ...............40....
National Plant Diagnostic Network ........._.............. ....__ .. .. ..._.._. .. ..........4
Example Rules and Rule Structure from NPDN Plant Diagnostic Laboratories ............43
Example Rule 1 .............. ...............43....












Example Rule 2 .............. ...............44....
Example Rule 3 .............. ...............45....
Example Rule Structure .............. ...............46....

4 HETERO GENEOUS RULES AS WEB SERVICE S .....__....___ ..............._.......4


Creating a W eb Service .............. ...............49....
Algorithms for Different Rule Types .............. ...............50....
Integrity Constraints .............. ...............50....
Derivation Rules ............. ...... ._ ...............51..
CAA Rules ............ _. ..... ...............52...
Rule Structure .............. ...............53....


5 SYSTEM ARCHITECTURE AND RULE PROCESSING............... ...............6


System A rchitecture............... ...... .... .. .. ......... .............6
Event-triggered Processing of Rules and Rule Structures in the EU-Rent Domain ...............68
Decomposition of Rule Structure .................. .............. ... ...............7
Event-triggered Processing of Rules and Rule Structure in the NPDN Domain ................... .72
Distributed Rule and Rule Structure Processing in the NPDN domain............... ................73

6 RE SEARCH IS SUE S .............. ...............78....


Event Data Aggregation ................... ........ .............7
Event Data Inconsistencies and Contradictions ................. ...............80........... ...
Avoiding Cyclic Rule Execution ................. ...............82................


7 SUMMARY, CONTRIBUTIONS, AND FURTHER RESEARCH ................. ............... ....94


APPENDIX


A XML Schema documents ................. ...............97................


RuleBase.xsd .............. ...............97....
Rule Struc.xsd ........._... ...... ._ ._ ...............106.
EventData.xsd ................. ...............108._.._._ ......
Events.x sd ............... ..............10

Operations.xsd ................. ...............110......... ......

B EVENTS AND RULES IN THE EU-RENT DOMAIN ................. ............................113


Description of entities used ................. ...............113......... .....
EU-Rent Rules ................. ...............114................
Events and Triggers ................ ...............128................


C EVENTS AND RULES IN THE NPDN DOMAIN ................. ...............134.............


LIST OF REFERENCE S ................ ..............15. 1......... ....












BIOGRAPHICAL SKETCH ........._.... ....._.. ...............157.....










LIST OF TABLES


Table page
6-1 Build time and run time overhead of the cyclic rule avoidance strategy............._._.. ........90

B-1 Average time to create and execute rules and rule structures in the EU-Rent domain....132

C-1 Average time to create and execute rules and rule structures in the NPDN domain.......150











LIST OF FIGURES

Fiare page
3-1 Example rule structures................ ..............4

4-1 Algorithm for web service synthesis............... ...............5

4-2 Algorithm for integrity constraint rules .............. ...............56....

4-3 Algorithm for derivation rules .............. ...............57....

4-4 Algorithm for condition-action-alternative_action rules ................. ........................58

4-5 Algorithm for rule structures .............. ...............60....

5-1 ETKnet system architecture ........._._.._......_.. ...............75....

5-2 Event and rule processing in the EU-Rent domain ....._____ .... ... ..__ ...........__....76

5-3 Event and rule processing in the NPDN domain .............. ...............77....

6-1 Algorithm to aggregate event data and identify conflicts ................. ................ ...._.91

6-2 Algorithm to find possible cyclic paths on registration of an event .............. .................92

6-3 Algorithm to compute the rule expression for a possibly cyclic rule .............. ................93

6-4 Algorithm to update possible cyclic paths on addition of a global rule..............................93









Abstract of Dissertation Presented to the Graduate School
of the University of Florida in Partial Fulfillment of the
Requirements for the Degree of Doctor of Philosophy

ETKnet: A DISTRIBUTED EVENT- AND RULE-BASED SYSTEM FOR KNOWLEDGE
SHARING IN A COLLABORATIVE FEDERATION

By

Seema Degwekar

August 2007

Chair: Stanley Y. W. Su
Cochair: Herman Lam
Major: Computer Engineering

Enabling government organizations to solve complex global problems such as illegal

immigration, border control, and terrorism or business organizations to maintain a globally

competitive edge, requires these organizations to collaborate and share not only data and

application system resources, but also knowledge that captures organizational and inter-

organizational policies, constraints, regulations, processes and procedures. In our study, we focus

on the research and development of a knowledge specification language and the techniques,

algorithms, system and infrastructure for the sharing of knowledge among collaborating

organizations.

We represent knowledge using three types of rules: condition-action-alternative-action

rules, logic-based derivation rules, or integrity constraints, and structures of these rules. We

introduce an XML-based language that enables the specification and sharing of multi-faceted

knowledge. Collaborating organizations can specify events of importance, data associated with

those events, and rules and rule structures that should be triggered upon the occurrences of those

events. We develop a distributed event- and rule-based system called ETKnet for event

notification, event data transmission and aggregation, and processing of distributed rules, rule










structures, triggers, automated application system operations and manual operations. Data

associated with an event occurrence and generated by triggered rules, rule structures and

automated/manual operations can thus be shared and used by collaborating organizations for

their decision-making and problem-solving. Our approach to achieve the interoperation of

heterogeneous rules is to translate rules and rule structures into program code and wrap them as

web services for their uniform representation, discovery and invocation in a web service

infrastructure.

This dissertation presents the system architecture, the distributed event and rule processing

strategy, algorithms used for the translation of heterogeneous rules and rule structures into web

services, implementation details, and issues and solutions related to event data aggregation,

conflicting rules, and cyclic rules.









CHAPTER 1
INTRODUCTION

Recent breakthroughs in technology have served to bring the world closer together. While

easy communication and accessibility solve many fundamental problems for the world

community, they also give rise to new complex ones. Some of these problems have potentially

serious consequences. For example, government organizations face complex problems such as

drug trafficking, terrorism, illegal immigration, and disease detection and control. Other

problems likely hamper global economic progress. For example, most business organizations are

facing the challenges of increasing productivity and profit while reducing costs, developing

synergy among different departments of an organization or among collaborating organizations,

and recognizing and planning for future assets in an ever changing world. In order for business

organizations to compete in the global economy and for government organizations to tackle

complex problems, they must collaborate and share their data, application system operations

(automated or manual), as well as knowledge specifications that express their policies,

constraints, regulations, processes and procedures [18, 32, 65]. Research has shown that

knowledge acquisition and learning can greatly benefit from interaction and collaboration with

others that share similar interests [76].

The basic technology of sharing distributed, heterogeneous data has been extensively

studied. Many recent efforts that address schema matching [22, 27], data privacy [1, 80], and

schema mapping [52, 79] are important for achieving meaningful sharing of data. However, an

effective means of sharing human and organizational knowledge among collaborating

organizations is still lacking.

Organizations that share data, knowledge and application operations form a collaborative

federation. Each organization in such a federation typically has its own file system or database










management system to manage its data. It may also have a knowledge-based system to store and

process its organizational knowledge. One approach to achieve data, knowledge and operation

sharing is to build a distributed system on top of the existing systems of the collaborating

organizations for accessing distributed data, knowledge and operation resources. However, direct

access to an organization's systems and data or knowledge resources may not be possible due to

security reasons and the autonomous nature of these organizations. Instead, we propose that each

collaborating organization publish/export only the data, knowledge specifications and application

operations that it is willing to share. We provide a distributed system capable of processing these

shareable resources.

At any given point in time, an organization will not be interested in getting all the

shareable data of other collaborating organizations. Usually, it will be interested in getting only

the specific data associated with the occurrence of an event (e.g., a delay of the delivery date of a

product, a police arrest of an illegal immigrant, a terrorist attack, etc.) and the data that are

generated by the execution of relevant knowledge specifications that are triggered by the event

occurrence. In this work, we focus on eventlr-tr~i,71'.eIeer data, knowledge and operation sharing

among collaborating organizations.

To achieve effective event-triggered data and knowledge sharing, we need to answer three

important questions: "How do we represent knowledge?", "What mechanism can we use to

achieve sharing?" and "How do we achieve the interoperability of heterogeneous knowledge

specifications?"

Knowledge can be broadly classified as tacit or explicit [51]. Explicit knowledge can be

expressed in language and can therefore be codified and recorded, whereas tacit knowledge

cannot be expressed in language and is usually transmitted through socialization processes [47].










A community's knowledge is obtainable from multiple sources like documents, processes,

conceptual models, etc. [9]. In this work, we are interested in representing the explicit knowledge

embedded in an organization's policies, constraints, regulations, procedures and processes. This

knowledge can be specified by different types of rules [44, 62]. As such, this knowledge is multi-

faceted. There are three common types of knowledge rules used in existing rule-based systems

[3 8, 5 8]. Condition-action or event-condition-acti on (ECA) rules [78] are the most common type

of rules used in event-based systems [13, 16] and production rule systems [55, 12]. Experts'

opinions expressed in forms of deductive rules are employed for decision-support [71]. In

addition, constraint rules are used to enforce data integrity in most database systems [70]. The

above three types of rules may be structured (hereafter referred to as rule structure) to express a

rule execution order that models an organizational or inter-organizational process or operational

procedure. By developing a high-level, declarative knowledge specification language for

describing these three popular types of knowledge rules and rule structures, we can provide a

powerful means to capture the different facets of knowledge to be shared by collaborating

organizations.

We now address the type of system needed to process distributed, heterogeneous rules and

rule structures. As we mentioned earlier, collaborating organizations are usually interested in

obtaining only those data that are pertinent to the occurrence of an event of common interest

(i.e., event data) and in processing only those knowledge rules that are applicable to the event

data. An event is any incident of significance to collaborating organizations (e.g. an arrest, a

terrorist incidence, the detection of a disease, a special state of a database, a signal from a sensor,

etc.) that occurs at a particular point in time. Each organization of a federation can define and

share its events of interest, along with data generated by these events. It can also specify rules









that should be processed upon the occurrence of an event defined by either the organization itself

or by another collaborating organization. When an event occurs at an organization's site, data

associated with the event occurrence (i.e., event data) are sent to organizations that have

applicable knowledge rules and rule structures. A rule or rule structure is applicable to an event

if the set of data items to be processed by the rule or rule structure is a subset of the event data.

The processing of these rules may add to or modify the initial event data, and/or activate

shareable application operations that add to or modify the event data. The results of rule

processing are sent to the site that posted the event occurrence, which then merges the data

collected from different organizations to produce a new version of event data and sends it out

again to sites that have applicable rules. This process of event data transmission and rule

processing continues until all relevant rules have been applied. The last version of the event data

contains all the data that are relevant to the event occurrence. It can be used by collaborating

organizations for additional problem-solving and decision-support. Thus, an event- and rule-

based system that facilitates event subscription, event notification, delivery of event data, and

processing and interoperation of applicable knowledge rules and rule structures would be ideal

for any collaborative federation and is the focus of our research.

Now we come to the question of how to process heterogeneous rules and make them

interoperable. One approach is to use three types of rule engines to process the corresponding

three different types of rules and find some way to make these engines interoperable. We believe

this will result in a very complex and inefficient system. Another approach taken in [8] is to

choose one knowledge repre sentati on (e.g., event-conditi on-acti on rule) and convert the other

two types of rules into the chosen one so that they can all be processed by a single rule engine.

Since the semantics of these rule types are different, one problem with this approach is that it is









not always possible to convert one type of rule into another type without some loss of meaning.

Also, most existing rule engines interpret rules at runtime resulting in an inefficient and

unscalable rule system. A third more promising approach taken in [43, 57] is to provide a web

service interface to heterogeneous rule engines, thereby providing a uniform access API. In [57],

rule execution is carried out by individual engines interpretively. Support for rule structures is

lacking and it is also not clear how one rule engine can make use of the results generated by

another. In our work, we use a compilation approach by translating different types of rules and

rule structures at rule definition time into code and wrapping this code as web services for their

uniform registration, discovery and invocation in a web service infrastructure.

The contributions of this research are to:

1. Develop a an XML-based knowledge specification language for organizations to specify
their knowledge in terms of three types of rules and rule structures,

2. Develop algorithms for converting different types of rules and rule structures to web services
and a strategy for processing rules and rule structures to demonstrate the interoperation of
heterogeneous knowledge rules,

3. Research on techniques for managing dynamic event data and processing distributed
knowledge rules, merging event data documents, handling event data inconsistencies and
preventing cyclic execution of rules, and

4. Develop a distributed event- and rule-based system to achieve inter-organizational sharing of
event data, knowledge and application operations.

As mentioned before, the proposed technology and system has applications in e-business,

homeland security and other such collaborative efforts. Specifically, we will present two

applications to demonstrate the need and use of the proposed work: one in the e-business domain

by using the EU-rent car rental company example published by the Business Rules Group [38],

and the other in the homeland security domain by using the National Plant Diagnostic Network

(NPDN) System [49].










The rest of this dissertation is organized as follows. Chapter 2 presents earlier efforts in

this area. Chapter 3 describes the syntax of the three types of rules and rule structure, and also

presents our knowledge specification language, along with examples of rules and rule structures

from the abovementioned applications. Chapter 4 presents algorithms for converting

heterogeneous rules and rule structure to web services. Chapter 5 presents the architecture of our

event- and rule-based system, the implementation framework and technologies used. Chapter 6

describes research issues pertaining to event data aggregation, event data inconsistencies, and

cyclic rule execution. Finally, Chapter 7 summarizes our contributions and presents ideas for

further research.









CHAPTER 2
RELATED WORK

Rule Markup Languages

Several recent efforts are concerned with developing a rule markup language for business

applications. The main aim of these languages is to capture rule syntax in an XML form. Some

common approaches are outlined below:

Simple Rule Markup Language (SRML)

SRML [21], proposed by ILOG in 2001, addresses the problem of sharing rules across

applications with different Java rule engines. They realize that there are several commercial Java

rule engines on the market such as ILOG JRules [33], JESS [24], OPS/J [54], etc. each with their

own feature sets. Each of these rule engines has their own set of Java APIs, and their own

proprietary rule language. This prohibits applications from sharing rules across rule engines, and

as a result, ties such applications to a specific platform.

Their proposed solution is to provide an XML representation for Java rule engines. They

mainly provide the syntax to describe forward-chaining condition-action rules. Constraints and

deductive rules can potentially be specified by converting them to condition-action rules.

However, the language does not provide explicit mechanisms to represent these other types of

rules.

Business Rules Markup Language (BRML)

BRML [20] was developed in connection with IBM' s Business Rules for E-Commerce

Proj ect. It aims to provide a common representation for exchanging rules between heterogeneous

rule systems. It concentrates on heterogeneous expert systems only, and thus has support only for

the representation of deductive rules.









Rule Markup Language (RuleML)

By far the most popular and advanced markup language available today, RuleML [30]

aims to capture all three types of business rules in a standardized format. The RuleML initiative

began in 2000. Since then, the language is continuously evolving. The aim is to represent both

forward-chaining and backward-chaining rules for deduction and other transformations. The

syntax for deductive rules has been pretty much Einalized, and we adopt some syntactic

constructs in our own knowledge specification language. However, the effort to extend RuleML

to include constraint and event-conditi on-action rule specifications is still in an early

developmental stage.

Extensible Rule Markup Language (XRML)

The eXtensible Rule Markup Language (XRML) [40] aims to represent and process rules

implicitly embedded in web pages. Towards that end, it defines a Rule Identifieation Language

which allows a user to specify rules, a Rule Structure Language which converts these rules into a

formal structure usable by an expert system, and a Rule Triggering Language, which defines the

conditions under which these rules will be triggered. These conditions relate to events in our

terminology. The user can thus make use of special tags to augment unstructured information.

This can then be processed by a software agent to derive rules embedded in the web page. The

aim here is to support knowledge sharing between a human being and a software agent.

Currently, XRML supports deductive rules only. Also, they focus on knowledge sharing within a

single organization.

Other Markup Languages

Besides the ones mentioned above, there are many other efforts such as

*the Semantic Web Rule Language (SWRL) [3 1], which aims to extend the set of the Web
Ontology Language (OWL) [45] axioms to include Horn-like (deductive) rules,










* the Rule Language in OWL (ROWL) [25], which allows the specification of deductive
rules in OWL and provides the facility for translating these rules into Java Expert System
Shell (JESS) rules, and

* the Agent-Obj ect-Relationship Markup Language (AORML) [74], which represents the
behavior of business entities (business processes, events, agents, claims, etc.) by means of
reaction (or ECA) rules.

All of the above languages and systems support only one or two of the rule types we are

interested in. As far as we know, RuleML is the only effort that aims to represent all three types

of rules. However, the language is yet to be Einalized.

Event- and Rule-Based Systems

Event-based Systems

Several distributed event notifieation/service systems such as DREAM [13], Siena [16],

Herald [14], Scribe [59], Yeast [39] and the work reported in [23] provide features similar to our

distributed event infrastructure. These systems focus on scalability issues of event data, event

subscription, efficient event notification, event filtering, and event history processing. However,

most of them do not couple event notification with rule processing. DREAM and Yeast achieve

this, but only use the event-conditi on-action (ECA) rules.

Rule-based Systems

There are many rule-based systems that process rules specified in a single rule

representation. For example, the Web-based knowledge management system reported in [15]

uses derivation rules to assist product designers in conceptual designs of products. Each rule

specifies the conditions) under which a design attribute is satisfied. In [77], a general-purpose

knowledge acquisition tool called COCKATOO uses formal grammar augmented with constraint

specifications to specify structured and declarative knowledge. There are many so-called active

database systems, which use ECA rules as surveyed in [78].









With the exception of a few rule processing systems designed for processing rules in a

distributed environment, most of the knowledge-based management systems are centralized: i.e.,

they use a single rule processing engine to process specific type of rules. Some examples of

distributed rule management systems are given below.

In [35], a distributed rule processing mechanism for multi-database systems is presented.

The work deals with the processing of simple and composite event expressions and the

decomposition of event expressions to create sub-rules for processing on multi-databases. In

[28], the authors present a distributed active database system that has a central shared knowledge

repository and an ECA rule base. They also present the technique for processing ECA rules in a

distributed environment. ECA rules are decomposed into sub-rules and then these sub-rules are

distributed to different sites for processing against distributed databases. The authors address the

issue of how to evaluate rules correctly considering the order of distributed rule executions. In

[3], the authors discuss the behavior of active rules in multi-database systems. An event service

generates event managers to detect, produce and notify distributed events, while a rule service

generates rule managers with specific rule engines for executing reactive rules. They propose

Hyve execution policies for processing multiple rules. In [36], the concept and the technique for

coordinating peer databases using ECA rules are presented. Peer databases are stand-alone,

independently developed databases that are linked to each other through acquaintances. They

each contain local data, a set of mapping tables and expressions, and a set of ECA rules, which

are used to exchange data among them. The set of acquaintances and peers constitutes a dynamic

peer-to-peer network in which acquaintances are continuously established and abolished. The

paper describes techniques for specifying data exchange policies on-the-fly based on constraints

imposed on the way peers exchange and share data. It provides on-the-fly specification of data









exchange policies by building coordination ECA rules at acquaintance time. In [53], a system

called KRAFT deals with the access of heterogeneous data from multiple, distributed, and

heterogeneous data sources. An integration schema provides a common representation across the

distributed system. Distributed database queries are processed to retrieve data instances.

However, to make these instances meaningful, KRAFT attaches context information with these

instances. The context information is expressed in the form of constraints, which describe how

each data instance should be interpreted and used.

There are three main differences between our system and those mentioned above. First, in

these systems, event notification is not linked with the processing of heterogeneous, distributed

rules. Second, they deal with the processing of only one type of rules, whereas, our system deals

with the processing of multiple types of rules and rule structures. Third, they decompose rules

into sub-rules and transmit them to multiple sites for processing against distributed data, whereas

we transmit event data, which is limited in quantity as compared with stored databases, to those

sites that contain applicable rules.

Rule Interoperability

The following three systems aim to achieve heterogeneous rule interoperability in different

ways. The first one designates one of the three types of rules as the standard, and converts the

other two into the standard representation. The second and the third propose providing a

standardized interface to three types of rule engines.

E-DEVICE

E-DEVICE [8] proposes an active knowledge based system to support the processing of all

three types of rules. The core system is an active OODB system that has support for events and

ECA rules. Derivation rules and integrity constraints are mapped into ECA rules and processed

by a single rule engine. The events monitor the insertion, update, or deletion of an obj ect, an










obj ect attribute, or an intra-obj ect pattern. The condition clause is an inter-obj ect pattern, which

consists of the conjunction of one or more intra-obj ect patterns. The action clauses are either

insertion, deletion, or update of an obj ect or obj ect attribute. The implemented system (at the

time of writing) does not support the translation of integrity constraints into ECA rules. The

operations allowed in action clauses are limited to database operations instead of application

system operations.

Service-Oriented Business Rules System

The system presented in [57] addresses the lack of flexibility and reusability of business

rules across distributed rule engines. The authors propose a service-oriented business rules

system that manages and deploys business rules to different business rule engines. Their

distributed system consists of several nodes, which can belong to one or more of the following

three types: Rules Broker Node, Deployment Node, and Coordination Node. Each Rules Broker

node hosts one or more Business Rules Brokers, which can have several different rule engines

plugged in. The broker is used to direct the rule processing to the appropriate engine and uses the

web service interface as a communication mechanism between different types of engines. A rule

is first implemented in the appropriate rule engine. The interface to this rule is generated as a

web service and is deployed at one or more deployment nodes. The coordination node is

responsible for coordinating the deployment of a set of rules among multiple available rules

broker nodes. This node uses a two-phase commit protocol to ensure that all participating rules

broker nodes have received the correct set of rules. This same system has also been used to

demonstrate rule integration in BPEL [56]. Here, the authors focus on the integration of business

rules with web service composition. A process workflow is augmented with pre- and post-

activity rules that encapsulate business logic. Different from this work, rule execution in our

system is governed not only by explicit triggers that link events to rules and rule structures, but









also by implicit triggers determined by examining whether the input data to a rule or rule

structure are a subset of the event data. Implicit triggers give our system the forward-chaining

like behavior which is not present in the referenced system. Furthermore, rule execution in the

referenced system is carried out by individual engines interpretively, whereas we use a

compilation approach. Support for rule structures is lacking and it is also not clear how one rule

engine can make use of the results generated by another.

Rule Interchange Format

W3C has established a Rule Interchange Format working group [10] to produce a

framework or language to translate rules between different systems. The purpose of this group is

to enable rule interoperability by allowing rules specified in one format to be processed by a

different rule engine. At the time of this writing, the RIF Core has been developed. From the RIF

Core Design document [10], "RIF Core corresponds to the language of definite Horn rules with

equality (and with a standard first-order semantics). Syntactically, however, RIF Core has a

number of extensions to support features such as obj ects and frames, URIs as identifiers for

concepts, and XML Schema data types. These features make RIF a Web league. However,

RIF is designed to enable interoperability among rule languages in general, and its uses are not

limited to the Web. The semantics of RIF has provisions for future extensions towards dialects

that support pure FOL, dialects that support negation as failure (NAF), business (or production)

rules, reactive rules, and other features. Eventually, it is hoped that RIF dialects will cover a

number of important paradigms in rule-based specification and programming. Our main target

paradigms include production rules, logic programming, FOL-based rules, reactive rules, and

normative rules (integrity constraints)."

It is worthwhile to point out some key differences between our system and those

mentioned above. E-DEVICE is an event-based system, but it does not use a compilation










approach for rule processing. Instead, it converts different types of rules into ECA. Also, its

application domain is a single organization with an OODB instead of a collaborative federation.

The service-oriented business rules system is not an event-based system. It assumes the existence

of a knowledge base, against which user queries are issued, and aims to answer such queries by

applying all relevant business rules. It provides a web service interface to communicate with

different engines; however the actual processing of the rules is done by a rule engine, which uses

an interpretive approach. There is no rule structure or workflow-like construct for modeling

business processes. The Rule Interchange Format effort is a fairly new one. At the time of this

writing, the core design of the language known as "Condition language" has been identified. This

can be extended to derivation rules, reactive rules, as well as integrity constraints, which are

future deliverables.

After surveying the existing efforts and systems that are related to our work, we have

arrived at the following two conclusions.

* To our knowledge, there is no system that uses a combination of different rule types to
specify individuals/organizations' knowledge in a structured manner.

* The interoperation among distributed, heterogeneous rules in a collaborative federation has
not been investigated.









CHAPTER 3
KNOWLEDGE SPECIFICATION LANGUAGE

Rules and rule structures specified in an XML format are used for two purposes:

translation to the corresponding web services for rule processing, and transmission among

collaborating organizations for knowledge exchange. Each organization uses a GUI tool to

define a set of rules and rule structures that form a local rule base to be shared with other

organizations. Each rule has the following characteristics: a name, a description, an optional

state (which can be either active or suspended, the default being active), and a sharing attribute

to indicate whether the rule is local to the defining organization or global, i.e. shared across the

federation.

The root element RuleBase represents the local rulebase. RuleBase has one or more child

elements, Rule, which represent individual rules. The Rule constructs that define a RuleBase are

shown in the Backus-Naur Form (BNF) syntax below. The elements hItCons, Implies, and

CAARule represent an integrity constraint rule, a derivation rule and a condition-action-

alternative_action rule respectively. They are described in detail in the following sections.

We adopt BNF syntax notations to describe the language for clarity and conciseness. The

actual XML schema is included in Appendix A. The schema for describing the rule structure,

events, event data as well as operations is also included in Appendix A. The notation A ::= B,

where both A and B are non-terminal symbols, is used to denote that the XML element B is a

direct descendant of the XML element A; i.e., A is described by the following schema

. The notation A ::= t, where A is a non-terminal symbol and t is a terminal symbol,

is used to denote that the value of A is restricted to the terminal t. Square brackets denote an

optional element; i.e., an element which can appear either zero or one time. Curly brackets

denote an element that can appear zero or more times. Boldface font is used to distinguish










terminal symbols from non-terminal symbols. The terminal symbol letter is used to represent

uppercase (A-Z) and lowercase (a-z) letters of the alphabet, digit is used to represent decimal

digits 0-9, and the symbol space is used to indicate any whitespace (a single space, a tab, a line

feed, etc.).

RuleBase ::= Rule {Rule}
Rule ::= RuleName RuleDescription [RuleState] Sharing IntCons|
RuleName RuleDescription [RuleState] Sharing Implies|
RuleName RuleDescription [RuleState] Sharing CAARule
RuleName ::= letter {letter |digit Ispace}
RuleDescription ::= letter {letter |digit Ispace}
Sharing ::= local |global
RuleState ::= active |suspended

Integrity Constraints

An integrity constraint [70] ensures that changes made to the database do not result in a

loss of data consistency. In the context of this effort, it is used to verify the consistency of event

data. For constraint specification, we adopt some syntactic constructs of our earlier work on a

Constraint Specification Language [64], which was patterned after the Obj ect Constraint

Language [75]. Since we use an object-oriented data model to represent event data, constraints

can be specified on an obj ect or on one or more of its attributes. Constraints can be classified into

two types: attribute constraint and inter-attribute constraint. Thus, the IntCons element

representing the integrity constraint has the following syntax. The element AttCons represents an

attribute constraint and InterAttCons represents an inter-attribute constraint.

IntCons ::= AttCons |InterAttCons

An attribute constraint is of the form

x a n, or x 7{Cnl,n2, ---,na

where x is an obj ect or object attribute, n is a value from x' s domain, 8 is one of the six

arithmetic comparison operators {>,>=,<,<=,=,f }, y is one of the enumeration operators {in, not










in), and {nl,n2, ---,Ha represents a set of enumerated values from x' s domain. Thus, an attribute

constraint specifies the allowed or valid constant values of an obj ect or obj ect attribute.

Examples of attribute constraints are: a 10O, b in {2, 5, 9}, where a and b are object attributes.

The BNF syntax of an attribute constraint is shown below.

AttCons ::= Dataltem RelOp Value |Dataltem EnumOp Value {Value}
Dataltem ::= Name Type
Name ::= letter {letter |digit Ispace}
Type ::= String |double |float |int |boolean |java.io.File
|java.util.Date | java.util.HashMap | npdn.Sample |
npdn.Shipment| npdn.ResponsePlan | npdn.Result |
eurent.Branch eurent.Car eurent.Rental |
eurent.Customer| eurent.Group
Value ::= {letter |digit} digit {digit} {digit}
RelOp ::= gt |It |ge |le Ieg ne
EnumOp ::= in |not in

The obj ect or obj ect attribute is represented by the element Dataltem, which consists of a

name and a type. Since we generate web services from such constraint specification

programmatically, the precise name and type information are needed by the programming

language used to implement the web service. Also, the type information is specific to the

programming language Java in our implementation, but it can be easily changed or extended for

any other programming language. Furthermore, any additional types introduced by the

application domain also need to be specified here. In the above BNF, we have included the type

specifications for the NPDN and the EU-rent domains. Element RelOp stands for arithmetic

comparison operators, element EnumOp for the enumeration operator, and Vahue for constant

values.

An inter-attribute constraint is of the form

fi(xl,x2, ---, Xb) e 2(y1, 2, ---fc), Of

IfP1 a P2 a ... a Pd then l ga Q2 a ... a c,










where fi(xl,x2, ---, Xb) and f271, y2, ---fc) are mathematical formulas relating the objects or object

attributes xl,x2, ---, Xb, and y y2, ---fc, respectively. P1, P2, ..., Pd and Q;, Q2, ---, ce are predicate

expressions of the form fi(x ,x2, ---, Xb) ef2(1, y2, ---fdc) Onnected by the logical operator a,
which is a member of the set (AD O ~ R. Examplesof ifnter-attributep cnonsraints are:p ab =c, If


(a 10 and b 15) then (c=5), where a, b and c are obj ect attributes.

Based on the above definition, we categorize the inter-attribute constraints into two sub-

types. Constraints specified using the first form described above are called formula constraints

and those specified using the second form are called condition constraints.

Their BNF syntaxes are shown below.

InterAttCons ::= FormulaCons |CondCons
FormulaCons ::= Expr RelOp Expr
Expr ::= Term {MathOp Term}
Expr MathOp Expr {MathOp Expr}
Term ::= Dataltem |Value |Operation
MathOp ::= + |- | / |*
Operation ::= OperationName {Dataltem} [Returns]
OperationName ::= letter {letter |digit Ispace}
Returns ::= Dataltem {Dataltem}
CondCons ::= IfExpr ThenExpr
IfExpr ::= [Not] BooleanExpr {LogicalOp BooleanExpr}
[Not] IfExpr LogicalOp IfExpr {LogicalOp IfExpr}
ThenExpr ::= [Not] BooleanExpr {LogicalOp BooleanExpr}
[Not] ThenExpr LogicalOp ThenExpr {LogicalOp
ThenExpr }
BooleanExpr ::= [Not] PredicateExpr |[Not] Term
PredicateExpr ::= Expr RelOp Expr
LogicalOp : := AND| OR

The formula constraints are represented by the element FornaulaCons, whereas the

condition constraints are represented by the element CondCons. Each of these XML elements

makes use of building blocks like the elements Expr for an expression, IfExpr, for the if

construct, and ThenExpr for the then construct. The Expr construct is composed of one or more

Term elements linked by mathematical operators. A Term can be a single data item, a constant










value, or an operation. An operation represents a function that operates on zero or more

parameters yielding zero or more output data items. An IfExpr element is composed of one or

more Boolean expressions, represented by BooleanExpr, which in turn can be either a predicate

expression (an expression that links two Expr elements by a comparison operator), or a single

term.

Derivation Rules

Logic-based derivation rules [71], also known as inference rules or deductive rules,

assess a given premise to come to some conclusion. They can be expressed as


P Q or P => Q!

the semantics of which are: If P is evaluated to true based on the contents of the event data, then

Q should be made true (i.e., data expressed by Q should be added to the event data). P is the

body of the implication, and Q is the head or conclusion. Both P and Q are Boolean expressions

of the form

T1 a T2 a ... a Tm,


where each r,, (1
the logical operator, AND or OR. We allow arbitrary nesting of the logical operators in P and as

such do not restrict P to conform to either conjunctive or disjunctive normal form, instead we

rely on grouping or nesting constructs (parentheses), which allow the creator of the rule to

specify his/her semantics precisely. We restrict the logical operator in Q to be and, for clear

interpretation of the conclusion. If or semantics are desired as shown in the following rule R

R: p => ql Vq2 V ... Vq,,,










The single rule R can be rewritten as multiple rules r y... r,2, with each r, (1
same premise p as the original rule, and q, as the conclusion. The derivation rule syntax is shown

below:

Implies ::= Body Head
Body : := IfExpr
Head ::= Atom {AndOp Atom}
Atom ::= Dataltem RelOp Dataltem |Dataltem RelOp Value
AndOp : := AND

It is derived in part from RuleML [30]. The implication is represented by the element

Implies. Implies consists of the Head and Body elements. The Head element contains one or

more Atom elements linked by the AND operator. Each of these atoms specifies a new or derived

value for the indicated obj ect or object attribute. The Body element is represented by the element

IfExpr. Premises in our language can contain executable functions in addition to variables.

Action-oriented Rules

Action-oriented rules are typically found in active database systems [78]. They are known

as event-condition-acti on (ECA) rules or j ust event-action rules [44]. When an event specified by

the event clause occurs, the ECA rule checks for the truth value of the condition clause, and

executes the action clause if the condition expression is true. The general format of the rule is

thus

On E if C then execute A

If we separate the event (E) from the condition-action (CA) part, we see that the CA part is

in fact the action-oriented rule. The event is used to indicate when to perform the action-oriented

rule. Also, an action-oriented rule may specify what actions are to be taken when the condition

expression evaluates to false. We can model this concept as two complimentary if-then rules

CIA, and C2B










where C2 is the complement of C1, and A and B are action clauses. Another way would be

to model them as a single condition-action-alternative_acti on (CAA) [41] rule. Thus, the

semantics of the CAA rule are as shown below. We use this form of the action-oriented rule in

our work.

If C then A else B

Since we are interested in developing a distributed event- and rule-based system, the

separation of the event specification and the action-oriented rule specification is important. It

allows events and action-oriented rules to be defined by different organizations. Events can be

flexibly linked to action-oriented rules by triggers, which can be defined by the same or other

organizations. It also allows an organization to link an event with not only a CAA rule, but any

other type of rules or a rule structure. Thus an event occurrence can invoke an integrity

constraint check, a derivation of new data, an execution of a CAA rule, and/or an execution of a

rule structure. We show the syntax of a conditi on -acti on- alternative_acti on rule b el ow.

CAARule ::= [Condition] Action [AlternativeAction]
Condition ::= [Guard] CondExpr
Guard ::= PredicateExpr {PredicateExpr}
CondExpr : := IfExpr
Action ::= Operation {Operation}
AlternativeAction ::= Operation {Operation}

The condition clause is represented by the Condition element, the action clause by the

Action element and the alternative-action clause by the AlternativeAction element. Each of these

elements uses the building blocks like IfExpr, Expr, Term, etc. mentioned earlier. An action-

oriented rule may want an action to be executed unconditionally. This is why the Condition

element is optional. Also, there may be no defined alternative action for a particular rule. Thus,

the AlternativeAction element is also optional.










The condition expression consists of two parts an optional guard clause and the

condition clause. If the guard evaluates to false, the execution of the rule is skipped, thereby

serving as a means of conditionally deactivating the rule. If not, the condition is evaluated to

determine whether to perform the action or the alternative action, which are represented by

Action and AlternativeAction elements, respectively. These elements are described by one or

more operations.

Rule Structure

When a specific event occurs, an organization may have a number of applicable rules that

need to be executed in a specified order. It is very natural to model a process or an operating

procedure by specifying the structural relationship between individual rules. We capture this

relationship by means of a rule structure [41].

In an organizational process, a rule r may be required to execute before another rule s, thus

establishing a direct link between r and s. Similarly, a rule r may be required to execute before

multiple ruleS Sl, S2, ... Sn, In>1, which can then be processed in parallel. In this case, r is

connected to sl, s2, ... so, in a split construct. A rule s may be required to wait for all of a given

set of ruleS T], T2, ... r,2, n>1 to finish before it can start its own execution. In this case, T], T2, --- rn

are connected to s in an and-join construct. Also, s may be required to wait for not all but a

subset of the ruleS T], T2, ... r,2, n>1 to finish execution. This establishes an or-join relationship

between T], T2, --- 772 and s. In each type of relationship, the rule(s) that governs(govern) the

execution of other rules is(are) termed predecessorss, and the rule(s) that executes(execute) after

the predecessors) is(are) termed successor(s).

A rule structure can now be defined as a directed graph a ithr different tyipes of rules as

nodes that are connected by link, split, and-join, and or-join constructs.










Some example rule structures are shown in Figure 3-1. R1, R2, ... R8 are individual rules

which could belong to any of the three types discussed above.

The syntax of a rule structure is given below.

RuleStruc ::= Name RuleStrucDescription [RuleStrucState] Sharing
RuleSubStruc {RuleSubStruc}
RuleStrucDescription ::= letter {letter |digit Ispace}
RuleStrucState ::= active |suspended
Sharing ::= local |global
RuleSubStruc ::= Link |Split |AndJoin |OrJoin
Link ::= Predecessor Successor
Split ::= Predecessor Successors
AndJoin ::= Predecessors Successor
OrJoin ::= Num Predecessors Successor
Predecessor ::= RuleName
Predecessors ::= RuleName RuleName {RuleName}
Successor ::= RuleName
Successors ::= RuleName RuleName {RuleName}
RuleName ::= letter {letter |digit Ispace}
Name ::= letter {letter |digit Ispace}
Num ::= digit {digit}

It is represented by the RuleStruc element. A complicated rule structure can be broken

down into substructures, each of which represents a single type of relationship between two or

more rules. We represent such sub structures using the RuleSubStruc element. Each type of

relationship is represented by XML elements with the respective name. The predecessors and

successors are represented by the following elements: Predecessor (rule r in a link or split),

Predecessors (rules r y, r2, -.. r, 7 in a j oin), Successor (rule s in a link or j oin), and Successors

(ruleS Sl, S2, ..., Sn in a Split). Num indicates the number of predecessor rules to be executed in an

or-join before the successor rule can be invoked.

Examples of Rules and Rule Structures from Two Application Domains

We now give some selected examples of rules and rule structures defined for two

application domains: e-business (EU-Rent car rental company) and Agricultural Homeland

Security (the National Plant Diagnostic Network).










EU-Rent Car Rental Company

The GUIDE Business Rules Proj ect [3 8] was organized in November 1993 to "formalize

an approach for identifying and articulating the rules which define the structure and control the

operation of an enterprise." To illustrate their techniques, the proj ect came up with a case study

of a fictitious car rental company EU-Rent, which is owned by EU-Corporation. EU-Rent is one

of the three businesses that EU-Corporation operates; the other two are EU-Fly airlines, and EU-

Stay hotels. EU-Rent has 1000 branches in towns in several countries. At each branch cars,

classified by car group, are available for rental. Each branch has a manager and booking clerks

who handle rentals.

The car rental company has to handle rental reservations, rental returns, car servicing,

maintain customer relations, promote customer loyalty, and deal with car purchase and sale.

These tasks form the core of the company and it is therefore very essential that they be managed

in a very consistent and efficient manner. EU-Rent has captured key aspects of each task in the

form of business rules. Such rules are broadly similar across branches; however, each branch

also has its own local set of policies that generate its own local set of business rules. Each branch

may wish to share some data and knowledge specifications with the other branches to achieve

better management of the company as a whole. Thus each branch is a collaborating site in the

collaborative federation of the EU-Rent company.

We realize that the above is not a real-world inter-organizational setting, yet it suffices to

serve our purpose due to the following reasons. First, the rule set has been independently

constructed and published for academic use by a well-known group. Second, each of the rules in

the rule set belongs to one of the three different rule types processed by our system. Third, as can

be seen from the rule set, managing the activities of a branch requires the interoperation of










different rule types captured in a rule structure. We now give some example rules and a rule

structure from the rule set and their conversion to our knowledge specification language.

Example Rules and Rule Structure from the EU-Rent Rule Set

Example Rule 1

Rule: Reservations may be accepted only up to the capacity of the pick-up branch on the pick-up

day.

Name: capacityCheck

Type: Integrity Constraint Rule

Representation in Knowledge Specification Language: We include only the main XML element

of interest "IntCons" in the following.







B ranch. numRe servati on s
int



1e



Branch. capacity
int







Example Rule 2

Rule: To j oin the loyalty incentive scheme, a customer must have made 4 rentals within a year.










Name: eligibleForLoyaltyScheme


Type: Derivation Rule

Representation in Knowledge Specification Language: We include only the main XML element

of interest "Implies" in the following.









Customer.numYearlyRental s
int



ge


4









Customer.eligible
b ool ean

eq
tre













Example Rule 3

Rule: After all assignments within a group have been made, 10% of the group quota for the

branch (or all remaining cars in the group, whichever number is lower) must be reserved for the

next day's walk-in rentals. Surplus capacity may be used for upgrades.

Name: reserveForWalkIn

Type: Condition-Acti on-AlternativeAction Rule

Representation in Knowledge Specification Language: We include only the main XML element

of interest "CAARule" in the following.










Group .numRem aini ngC ars
int



gt


0. 1

*


Group.quota
int




















re serveGroupByQuota

Group. grouplD
int


Group. quota
int





re serveGroupByRem Cars

Group. grouplD
int


Group .numRem aini ngC ars
int





Example Rule Structure

Rule Structure: Each paid rental in the (loyalty incentive) scheme (including the 4 qualifying

rentals) earns points that may be used to buy 'free rentals.' The basic rental cost of a free rental

can be bought with points. Extras, such as insurance, fuel and taxes must be paid by cash or

credit card. A free rental must be booked at least fourteen days before the pick-up date. Free

rentals do not earn points.

Name: RS1

Representation in Knowledge Specification Language: This is a rule structure that can be used to

assign "free rentals". Descriptions of the component rules can be found in Appendix B. It first










checks eligibility using the derivation rule "eligibleForLoyaltyScheme". Then, it makes sure that

only the basic cost of the rental is bought with points and extras are paid for by using a CAA

Rule "freeRental". Next, it calculates the free rental points earned using the derivation rule

"freeRentalPoints", and verifies advance booking using the integrity constraint

"checkAdvBooking". Rule "eligibleForLoyaltyScheme" is executed first and after that rule

"freeRental" is executed, followed by rules "freeRentalPoints", and "checkAdvBooking" in

parallel. We include the main XML element of interest "RuleStruc" in the following.


Free Rental Rule Structure
Procedure to give a free rental
AC TIVE
< Shari ng>gl ob al



el igibl eF orLoyalty Schem e


fre eRental




freeRental


fre eRentalP oi nts
checkAdvB ooking





National Plant Diagnostic Network

The United States Department of Agriculture, Cooperative State Research, Education and

Extension Service (USDA, CSREES) launched a multi-year national proj ect in May 2002 to

build the National Plant Diagnostic Network (NPDN) [49]. This was done with a view to









strengthen the homeland security protection for the nation's food and agriculture by facilitating

quick and accurate detection of disease and pest outbreaks in crops. Such outbreaks can occur

naturally as foreign pathogens are introduced into the United States through mechanisms ranging

from accidental importation to air-borne introduction by currents that traverse entire continents

[63, 72]. They can also occur intentionally through deliberate introduction, as an act of

bioterrorism [69]. In this nation-wide effort, the University of Florida was selected as the

southern regional center of NPDN and is responsible for building a Southern Plant Diagnostic

Network (SPDN) [61]. SPDN consists of a regional center system at the University of Florida

and 12 state systems (counting Florida) and Puerto Rico connected to the regional center system

through the Internet. The functions of the SPDN Regional Center are: to establish a network for

the detection and diagnosis of plant health problems, extend and support sound public policies,

implement environmentally sound prevention and management strategies, and provide leadership

and training. Data collected from the region is sent to NPDN at Purdue University in Indiana.

We intend to use this real-world example to demonstrate the applicability and usefulness of our

system .

One of the plant diseases being monitored by USDA is Asian soybean rust [34], which is

an aggressive fungal disease that can potentially reduce soybean yield by as much as 80 percent.

Another disease is Sudden Oak Death, which is a disease capable of causing a range of

symptoms from leaf spots to plant death on many woody hosts [68]. Plant growers and others

(first detectors) may submit samples to an NPDN lab to be diagnosed. The lab runs preliminary

diagnostic tests. If the results are positive, the lab staff seeks the help of a central authority

designated for confirmation of the disease. We have obtained the diagnostic procedures from

NPDN for the above two diseases. An analysis of these procedures reveals the existence of the










three types of knowledge rules and rule structure. We present some examples rules and rule

structure from these procedures along with their representations in our knowledge specification

language below. The derivation rule and the CAA rule have been obtained from [50], and the

integrity constraint is obtained from the NPDN required Hields list [29]. The rules obtained from

[50] are described in Appendix C. The derivation rule mentioned here, is included as part of

another CAA rule in the appendix to preserve the structure of the operating procedures as

outlined by NPDN.

Example Rules and Rule Structure from NPDN Plant Diagnostic Laboratories

Example Rule 1

Rule: The suspect sample is reclassified from "suspect" to "presumptive positive" if it has been

viewed by a diagnostician.

Name: NPDNR1

Type: Derivation Rule

Representation in Knowledge Specifieation Language: We include only the main XML element

of interest "Implies" in the following.









Sample. examined
b ool ean



eq


tre



















Sample. classifieation
String

eq
Presumptive Positive




Example Rule 2

Rule: The valid/allowed values for the data item "Pest-Genus-Confirmation" are "Confirmed",

"Suspected", "Inconclusive", "Not Detected".

Name: NPDNR2

Type: Integrity Constraint Rule

Representation in Knowledge Specifieation Language: We include only the main XML element

of interest "IntCons" in the following.




P estGenu sConfirm ati on
String

in
C
S
J
N












Example Rule 3

Rule: Triage Lab staff, NPDN Regional Hub Lab staff and APHIS-PPQ Confirming Diagnosis

Designate may conduct live web-based distance diagnosis examination of sample and

microscope mounts, if Triage Lab has this distance diagnosis capability. Or the diagnostician can

take a digital image and email to the other two diagnosticians if web cam is not available

Name: NPDNR3

Type: Condition-Acti on-AlternativeAction Rule

Representation in Knowledge Specification Language: We include only the main XML element

of interest "CAARule" in the following.










di stance di agnosi s_cap ability
b ool ean



eq


true









C onductWebBasedi Dagno si s











npdn. Sample.*"
npdn. Sample





EmailPi cture


samplerimage
j ava.io.File






Example Rule Structure

Rule Structure: If an NPDN Regional Hub or Expert Lab receives a presumptive positive sample,

Expert Lab Staff acknowledges sample receipt to Triage Lab. NPDN Regional Hub or Expert

Lab staff examines presumptive positive sample. NPDN Regional Hub or Expert Lab staff may

contact Local expert, for additional input, but does not disclose state of origin. This is performed

by the CAA rule "NHLR1". Local Expert may examine sample. Local Expert may make

preliminary diagnosis in collaboration with NPDN Regional Hub or Expert Lab staff. Local

Expert contacts NPDN Regional Hub or Expert Lab Diagnostician with conclusions/results. This

is performed by the CAA rule "NHLR2". NPDN Regional Hub or Expert Lab Diagnostician

contacts NPDN Regional Director and APHIS-PPQ-Confirming Diagnosis Designate with

preliminary conclusions/results. NPDN Regional Hub or Expert Lab staff contacts own SPRO

and APHIS-PPQ SPHD to inform them that a presumptive positive sample is housed in NPDN

Regional Hub or Expert Lab until shipment to APHIS-PPQ Confirming Designate or until it is

destroyed following diagnosis. The state of origin is not disclosed to NPDN Regional Hub or

Expert Lab's state SPRO or SPHD. NPDN Regional Hub or Expert Lab staff contacts its own










Campus Safety Officer to inform of presumptive positive sample in the lab. State of origin is not

disclosed. This is performed by CAA rule "NHLR3". If APHIS-PPQ Confirming Diagnosis

Designate requests NPDN Regional Hub or Expert lab to send sample for confirmation, then

NPDN Regional Hub or Expert Lab contacts APHIS-PPQ Confirming Diagnosis Designate and

Triage lab indicating that they are sending the presumptive positive sample to APHIS-PPQ

Confirming Diagnosis Designate Lab including shipment date, method, tracking number and

sample number. This is performed by CAA rule "NHLR4".

Representation in Knowledge Specification Language: Rule NHLR1 is executed first, followed

by rules NHLR2 and NHLR3 in parallel. After both NHLR2 and NHLR3 finish execution, rule

NHLR4 is executed. We include the main XML element of interest "RuleStruc" in the following.


NPDN Regional Hub Lab Procedure
Procedure followed by the NPDN Regional Hub
Lab
AC TIVE
< Shari ng>gl ob al



NHLR 1


NHLR2
NHLR3






NHLR2
NHLR3



NHLR4











R1




R4


R1

L


L2


AND-JOIN
LINK
OR-JOIN
SPLIT


R6 O[1]
R8


Figure 3-1. Example rule structures









CHAPTER 4
HETEROGENEOUS RULES AS WEB SERVICES

In Chapter 1, we mentioned our idea of translating different types of rules and rule

structures at rule definition time into code and wrapping this code as web services for their

uniform registration, discovery and invocation in a web service infrastructure. In this chapter, we

present the algorithms for automatically converting the three types of rules and rule structures to

web services.

Creating a Web Service

The W3C group defines web services as follows.

A web service is a software application identified by a uniform resource identifier (URI),

whose interfaces and binding are capable of being defined, described and discovered by XIM'

artifacts and supports direct interactions nI ithr other software applications using XIM based

messages via Internet-ba;sed protocols. [60].

Since the introduction of the web services concept, the software industry has provided

many tools to wrap application code as a web service. Software developers can thus focus on

developing the application code instead of worrying about conformity with the web service

protocols laid out by W3C [1l]. Therefore, the most significant task in creating a web service is

the development of application code to be exposed as a web service.

Figure 4-1 gives an overview of the algorithm for web service synthesis. It takes as input a

rule specification in XML that conforms to the knowledge specification language presented in

Chapter 3. The algorithm identifies the type of the rule and invokes appropriate handler methods

to create the source code for the rule (steps 3-5). This code is generated as an interface (or

header) file and an implementation (or source) file. The implementation file contains the

translation of the rule to code. Each rule is represented as a web service with one operation, the









characteristics of which depend on the rule type. A web service operation translates to a method

in a programming language. The specification of input and output parameters of the operation is

represented by the method's signature. In the following, we use the terms method and operation

interchangeably.

For successful compilation and deployment of a web service, we need to create the

appropriate WSDL document. This is done with the help of configuration Eiles, the exact type

and nature of which depend on the application framework used (steps 6-8). To facilitate the

discovery of a web service using UDDI, we also publish the web service to a private UDDI

registry (step 9).

Algorithms for Different Rule Types

In the following sections we describe the algorithms used to create the web services for

each of the three rule types. The basic idea in the algorithms is to create the code (using the Java

programming language) that captures the intent of the rule. Thus, we build the interface and

implementation Eiles line by line. We use the pseudo code statement write "A2 to indicate that

program statement A should be written out to either the interface or the implementation Eile, as

specified. When navigating through the XML rule document specified, we use the construct

elenal elem2 to refer to the XML child element elem2 of the XML element elenal. We use the

term method to refer to the web service operation generated for the specific rule type, and the

term algorithm to refer to the algorithm for creating the method.

Integrity Constraints

Each integrity constraint rule is represented as a web service with the operation/method

check(...). The algorithm determines the type of the constraint and generates the appropriate

program statements for check, details of which are given in Figure 4-2. The method check(...)

examines the supplied input data and returns a Boolean value which is true if the specified










constraint is satisfied and false otherwise. Specific cases to handle comparison operators,

enumeration operators, formula constraints and condition constraints are shown in the algorithm.

All data items referenced in the constraint rule constitute the input to check(...).

If the constraint type is an attribute constraint, the rule code checks if the relationship

specified by the comparison or the enumeration operator holds. If the constraint is an inter-

attribute constraint of the formula constraint subtype, the algorithm first generates code for the

expressions on the left hand side and the right hand side as IExprCode and rExprCode,

respectively. The method check(...) then determines if the IExprCode is related to rExprCode as

specified by op, where op is the comparison operator used. For a condition constraint, the

algorithm generates code for the if-part and the then-part as if~artCode and thenPartCode,

respectively. The method check(...) then determines if if~artCode is true. If so, it determines if

thenPartCode also holds true.

Derivation Rules

Each derivation rule is translated to a web service with the operation/method implies(...).

This method examines the input data to determine if the body of the implication is true. If so, it

returns the new data specified in the head of the implication. Figure 4-3 shows the algorithm for

creating the method.

The input parameters to the method implies(...) are the data items required by the body of

the implication and the data items referenced in the "value" part of the head. The body contains

one or more Boolean expressions linked by logical operators and and or. The getBody Val(...)

function translates the implication body into program statements. Each Boolean expression in the

implication body makes use of the function getExprCode(...) from Figure 4-2 to generate the

code for the expression. The head of the implication contains one or more Atom elements linked

by the and operator. Each of these elements contains a derived data item and the corresponding










value. This value can be a constant value or another data item. The function getHeada(...)

constructs a hashmap named head'yal, which contains the new data as a (name, value) pair

indexed by name. If the body evaluates to true, the output contains each pair in head'yal,

otherwise it is null.

CAA Rules

Each CAA rule is translated to a web service with the operation/method perform(...). If the

guard clause evaluates to true, this method examines the input data to see if the condition is

satisfied. If so, the operations specified in the action clause are executed, and the output of those

operations is returned, otherwise the operations specified in the alternative_action clause are

executed and the output of those operations is returned. Figure 4-4 gives the algorithm for

creating the method perform(...).

The input parameters to the rule are the data items referenced in the condition clause, and

the data items specified as input to the operations in the action and altemnative~action clauses.

The output data from the operations in the action clause are added to the hashmap actionData,

and the output data from the operations in the alternative_action clause are added to the hashmap

altActionData. Both these maps contain (name, value) pairs, indexed by name. The function

getConditionCode(...) translates the condition clause to program statements. Similarly, the

functions getActionCode(...) and getAltActionCode(...) translate the action and altemnative~action

clauses to code, respectively. The output of the method perform(...) is a hashmap named map,

which contains the result of the operations performed by the rule. At runtime, either the action or

the altemnative~action clause is executed, and map contains the corresponding output.

The function getActionCode(...) is shown in some detail in Figure 4-4B.

getAltActionCode(...) is very similar and is not shown separately. An action (or

alternative_action) clause consists of a list of operations to be executed. The function translates










each operation to program statements of the form output = operation name (input), or operation

name (input) depending upon whether the operation contains return parameters or not. In case

the operation returns multiple data items, we create an output class that captures all of these data

items as the class' data members. All such program statements are stored in the array actionyal

(or altAction Val), which is returned.

Rule Structure

A rule structure links rules together in a directed acyclic graph as explained in Chapter 3. It

is defined and published as a web service just like any other rule. We require the following

condition to be met to guarantee that the generated web service for a rule structure will be

executable.

Each of the rules in a rule structure must have already been defined and published' as a

web service before the rule structure is defined.

Each rule structure is represented as a web service with the operation/method execute(...).

Figure 4-5 shows the algorithm for creating execute(...). This method takes in all the input data

items required by all the rules in the structure, and returns the output data items produced by all

these rules. The obj ective of the method is to invoke the rules in the order specified by the

structure. To facilitate this, it creates invoker thread's for each rule in the structure. The algorithm

to create such an invoker thread (createlnvoker Thread(. ..)) is also shown in the figure.

The algorithm rsHand'ler(...) breaks down the given rule structure into substructures.

Details of how a given rule structure is partitioned into substructures and how such partitioning

aids rule structure execution will be presented in Chapter 5. Each substructure contains a link, a

split, an and-join, or an or-join relationship between two or more rules. The algorithm generates

invoker threads for every distinct rule in the substructure. Depending on the substructure type,

one of the four handler functions is called. Each of these handler functions is responsible for










generating code that will cause the rule execution in the manner specified by the corresponding

substructure type. The method execute(...) is then constructed by putting together code generated

by each of the handler routines. The method execute(...) maintains an array toBeExecuted to

keep track of those rules that have yet to begin execution.

linkHandler(...) generates program statements to ensure that a successor rule r2 is executed

only after the predecessor rule r y has finished execution as follows. First, the code creates an

invoker thread obj ect for rl. If this is a newly created thread, rl is included in toBeExecuted, if

not already put in, and starts the thread for r y. Once this rule has finished execution, it copies the

output items from rl to the rule structure's member variables, and removes rl from

toBeExecuted. It creates an invoker thread for r2, and puts it in toBeExecuted if this is a newly

created thread. Once r y finishes execution, T2 is allowed to proceed. Once r2 has finished

execution, it is removed from toBeExecuted, and its output copied to member variables.

Similarly, splitHandler(...) generates code to invoke the successor rules only after the

predecessor rule has been executed, andloinHandler(...) generates code to execute the successor

rule only after all the predecessor rules have been executed, and orJoinHandler(...) generates

code to execute the successor rule only after the specified number of predecessor rules have been

executed. The algorithms for splitHandler and orJoinHandler are included in Figure 4-5.









Algorithm 1 createWebService


(1) rules = getRules(ruleBa;se);
(2) for each rule r do
(3) if (r is an integrity constraint) icHandler(r); end if
(4) else if (r is a derivation rule) drHandler(r); end if
(5) else if (r is a CAA rule) caaHandler(r); end if
(6) createConfigFiles(r);
(7) compile(r);
(8) deploy(r);
(9) publisher);
(10) end for


Figure 4-1. Algorithm for web service synthesis












(1) paraml~ames = null, paramTypes = null; stmts = null;
(2) if constraint c is an attribute constraint do
(3) d= c -Dataltem;
(4) add d -Name and d Type to paramNamnes and paramTypes respectively
(5) op = c -getNextChild();
(6) if op is a comparison operator
(7) add "if d Name op c -Value return true;" to stmts
(8) end if
(9) if op is the enumeration operator in
(10) values = get~ralues(c);
(1 1) add "if d Name in values return true;" to stmts
(12) end if
(13) if op is the enumeration operator not in
(14) values = get~ralues(c);
(15) add "if -(d Name) in values return true;" to stmts
(16) end if
(17) else if constraint c is an inter-attribute constraint do
(18) dataltemList = getInputData(c);
(19) for each Dataltem d in dataltemList do
(20) add d Name and d Type to paramnNames and paramTypes respectively
(21) end for
(22) if c is a formula constraint do
(23) IExprCode = getExprCode(c Expr);
(24) op = c -RelOp;
(25) rExprCode = getExprCode(c Expr);
(26) add "if (lExprCode op rExprCode) return true;" to stmts
(27) end if
(28) else if c is a condition constraint do
(29) if;PartCode = getlfExprCode(c IfPart);
(30) thenPartCode = getThenExprCode(c ThenPart);
(31) add "if (ifPartCode = true and thenPartCode = true) return true;" to stmts
(32) end else
(33) end else
(34) create Servi celnterfaceFil e(paramnNames, paramnTypes);
(35) createServicelmplementationFile(pa~ramNams paramTypes, stmts);

Functi on: create Servi celmpl ementati onFile(paramNames, paramTypes. stmts)

(1) for each stmt s in stmts do
(2) write s to file
(3) end for
(4) write "return true;" to file

Figure 4-2. Algorithm for integrity constraint rules


Algorithm 2 icaandler










Algorithm 3 draandler


(1) paramNames = null, paramTypes = null;
(2) body = implies -Body;
(3) head = implies -Head;
(4) dataltemList = getInputData(body, head);
(5) for each Dataltem d in dataltemList do
(6) add d Name and d Type to paramNames and paramTypes respectively.
(7) end for
(8) bodyyal = getBodyCode(body);
(9) head~al = getHeadCode(head);
(10) create Servi celnterfaceFil e(paramnNames, param Types);
(11) createServicelmplementationFile(pa~ramNams paramTypes, bodyyal, head~al);

Function: netHeadCode(head)

(1) head~al = null;
(2) atomList = getAtoms(head);
(3) for each Atom a in atomList do
(4) dataltem = a Dataltem;
(5) value = a -getNextChild();
(6) add the pair (dataltem, value) to head~al
(7) end for
(8) return head~al;

Functi on: create Servi celmpl ementati onFile(paramNames, paramTyp es, b odv~ral. head~ral)

(1) write "map = null;" to file
(2) write "if (bodyVal) then"
(3) for each pair (dataltem, value) in headyal do
(4) write "map.put(dataltem, value);" to file
(5) end for
(6) write "end-if" to file
(7) write "return map;" to file


Figure 4-3. Algorithm for derivation rules










Algorithm 4 caaaandler


(1) paramNames = null, paramTypes = null, action2ap = null, altAction2ap = null;
(2) actionData = null, altActionData = null;
(3) condition = caarule -Condition;
(4) condExpr = condition CondExpr;
(5) action = caarule -Action;
(6) altAction = caarule -Alternative Action;
(7) dataltemList = getInputData(condition, action, altAction);
(8) for each Dataltem d in dataltemList do
(9) add d Name and d Type to paramNames and paramTypes respectively
(10) end for
(11) dataltemList = getInputData(action, altAction)
(12) for each Dataltem d in dataltemList do
(13) add d Name and d Type to paramNames and paramTypes respectively.
(14) end for
(15) dataltemList = getOutputD ata(action);
(16) for each Dataltem d in dataltemList do
(17) add d Name and d Type to actionData
(18) end for
(19) dataltemList = getOutputData(altAction) ;
(20) for each Dataltem d in dataltemList do
(21) add d Name and d Type to altActionData
(22) end for
(23) condition yal = getC ondCode(condition);
(24) actionyal = getActionCode(action);
(25) altAction~al = getAltActionCode(altAction);
(26) create Servi celnterfaceFil e(paramnNames, param Types);
(27) createServicelmplementationFile(pa~ramNams paramTypes, conditional,
(28) actionyal, altActionyal, actionData, altActionData);


Figure 4-4. Algorithm for condition-acti on-alternative_acti on rules. A) Description of the
overall algorithm





































Functi on: create Servi celmpl ementati onFile paramNames, paramTyp es, conditi onVal.
action~ral, altActionVal, actionData, altActionData),


Function: netActi onCodelaction)


(1)
(2)
(3)
(4)
(5)
(6)
(7)
(8)
(9)
(10)
(11)
(12)
(13)
(14)
(15)
(16)
(17)
(18)
(19)
(20)
(21)
(22)
(23)
(24)


action Val = null;
operationList = getO perati on s(action);
for each operation o in operationList do
namne = o OperationName; dataltemList = getInputData(o); return
create the parameter list from dataltemList
if return == null
add "name(parameter list);" to actionyal
end if
else
returnData = all data items in return Dataltem
if returnData contains only one data item
add "returnData = name(parameter list);" to actionyal
end if
else
outputCla~ss = createOutputClass(name+ "Output");
for each Dataltem d in returnData do
include d as a member of the output class;
end for
add "outputDatalnstance = instanceOf(outputClass);" to actionyal
add "outputDatalnstance = name(parameter list);" to actionyal
end else
end else
end for
return action~ral;


o -Return;


(1)
(2)
(3)
(4)
(5)
(6)
(7)
(8)
(9)
(10)
(11)
(12)


write "map = null;" to file
write "if ("+condition Val+") then"
write action Val to file
for each pair (dataltem, value) in actionData do
write "map.put(dataltem, value);" to file
end for
write "else" to file
write altAction Val to file
for each pair (dataltem, value) in altActionData do
write "map.put(dataltem, value);" to file
end for
write "return map" to file


Figure 4-4. Algorithm for condition-acti on-alternative_acti on rules. B) Description of
supplementary functions












(1) ruleStrucList = getRule Sub Struc(ruleStruc);
(2) ss Val = null;
(3) distinctRules = get distinct rules referred in ruleStruc
(4) for each rule r in distinctRules do
(5) createCallerRoutine(r)
(6) end for
(7) for each RuleSub Struc rss in ruleStrucList do
(8) if rss is a Link ssYal += linktHandler(rss -Link); end if
(9) if rss is a Split ssYal += splitHandler(rss -Split); end if
(10) if rss is an ANDJoin ssYal += andJoinHandler(rss- ANDJoin); end if
(1 1) if rss is an ORJoin ssYal += orJoinHandler(rss ORJoin); end if
(12) end for
(13) createServicelnterfaceFile();
(14) create Servi celmpl em entati onF ile(ss yal);


Function: createlnvokerThread (Rule r)

(1) write "call"+r.namne+" extends Thread", thus creating a caller class for the rule
(2) dataltemList = getInputAndOututpu(r);
(3) for each Dataltem d in dataltemList do
(4) declare a corresponding public data member with same name and type
(5) end for
(6) write "public void run()" to file
(7) prepare for rule web service call and write it out to the file
(8) write code to call the rule web service to the file
(9) for each Dataltem d generated by the web service do
(10) copy d's the value to the corresponding data member of the class
(11) end for

Function: splitHandler(Split s)

(1) pred = s Predecessor;
(2) succList = s -Successors;
(3) splityal += "callPred = invoker thread to call pred;"
(4) splityal += "for each Rule succ in succList do";
(5) splityal += "callSucc = invoker thread to call \//L L,`;
(6) splityal += "end for";


Figure 4-5. Algorithm for rule structures. A) Description of the overall algorithm and the
functions for creating a caller routine and handling the 'split' relationship


Algorithm 5 rsaandler










(7) splityal = "if callPred.state


NEW and callPred not in toBeExecuted"'


(8) splityal += "add callPred to toBeExecuted;";
(9) splitYal += Start callPred;";
(10) splityal += "end if ';
(1 1) splityal += "if callPred.state == TERMINATED and callPred in toBeExecuted"'
(12) splityal += "remove callPred from toBeExecuted;";
(13) splityal += "copy output of rule to member variables;"
(14) splityal += "end if ';
(15) splityal += "for each Rule succ in succList do";
(16) splityal += "if callSucc.state == NEW and callSucc not in toBeExecuted"';
(17) splityal += add callSucc to toBeExecuted;"
(18) splityal += end if ';
(19) splityal += "if callPred.state == TERMINATED and callSucc.state == NEW";
(20) splitYal += Start mu/ L,`;
(21) splityal += end if ';
(22) splityal += "if callSucc.state == TERMINATED and callSucc in toBeExecuted"'
(23) splityal += "remove callSucc from toBeExecuted;";
(24) splitl~al += "copy output of rule to member variables;"
(25) splitYal += "end if ';
(26) splityal += end for";
(27) return splityal;

Function: orJoinHandler(ORJoin o)

(1) predList = o -Predecessors;
(2) succ = o -Successor;
(3) orJoinyal = "for each Rule pred in predList do"
(4) orJoinyal += "callPred = invoker thread to call pred; "
(5) or~loinVal = "if callPredmstate == NEW and callPred not in to~eExecurted'
(6) orJoinYal += "add callPred to toBeExecuted;";
(7) orJoin yal += Start callPred;";
(8) orJoinYal += "end if ';
(9) orJoinYal += "if callPred.state == TERMINATED and callPred in toBeExecuted"'
(10) orJoinYal += "remove callPred from toBeExecuted;";
(1 1) orJoinYal += "copy output of rule to member variables;"
(12) orJoinYal += "end if ';
(13) orJoinYal += "end for";
(14) orJoinYal += "num = o -Num; count = 0;"
(15) orJoinyal = "for each Rule pred in predList do"
(16) orJoin Val+= "if callPred.state == TERMINATED"
(17) orJoinYal += "count++;";
(18) orJoinYal += "end if'
(19) orJoinYal += "end for"

Figure 4-5. Algorithm for rule structures. B) Description of the function for handling the OR
join relationship










(20)
(21)
(22)
(23)
(24)
(25)
(26)
(27)
(28)
(29)
(30)


orJoinYal+
orJoinYal +
or~oinY~=
orJoinYal+
or~oinY~=
orJoinYal+
orJoinYal +
or~oinY~=
orJoinYal+


"callSucc = invoker thread for \/ituL,`
"if callSucc.state == NEW and callSucc not in toBeExecuted"'
"add callSucc to toBeExecuted;"
"end if '
"if callSucc.state == NEW and count >= num"
"Start ca/Itu~I L,
"end if '
"if callSucc.state == TERMINATED and callSucc in toBeExecuted"'
"remove callSucc from toBeExecuted;";
"copy output of rule to member variables;"
"end if ';


(31) return orJoinYal;

Functi on: create Servi celmpl ementati on(s sVal)

(1) write "toBeExecuted == null" to file;
(2) write "do" to fie
(3) for each path execution p in ssyal
(4) write pto Ble
(5) end for
(6) write "while toBeExecuted is not empty" to file


Figure 4-5. Algorithm for rule structures. C) Description of the function to generate the web
service implementation Eile









CHAPTER 5
SYSTEM ARCHITECTURE AND RULE PROCESSING

In this chapter, we describe our system architecture and implementation framework. We

use example scenarios from the two application domains described in Chapter 3 to explain the

event-triggered processing of distributed rules, rule structures and application operations.

System Architecture

The distributed event- and rule-based system called ETKnet has a peer-to-peer server

architecture (Figure 5-1). All collaborating organizations have identical subsystems installed at

their sites. Each site creates and manages its own events, rules, rules structures, triggers and

operations, but their specifications are registered at the host site of a collaborative federation.

The host maintains a repository of these specifications.

The rule server component at each site stores and manages the web services generated for

the rules and rule structures defined at that site. These web services are registered at the web

service registry (WSRegistry) of the host site. The event server component is responsible for

storing information about events defined at that particular site and information about event

subscribers. A collaborating site can specify a trigger linking a distributed event to a rule or a

rule structure, thus becoming an explicit subscriber of that event. This information is stored by

the event server in a local database. Triggers can be automatically and dynamically generated by

the system if the event data schema associated with an event occurrence is a superset of the input

data schema of a rule or rule structure. In this case, the site that has the rule or rule structure

becomes an implicit subscriber of the event. Both explicit and implicit subscribers will be

notified upon the occurrence of an event. Distributed rules and rule structures are invoked and

processed by replicas of the rule server. These rules and rule structures may invoke automated

system operations and manual operations of collaborating sites. An event server at any site can










serve as the coordinator for a particular knowledge sharing session initiated by an event

occurrence at that site. It handles the integration and organization of the dynamic event data

associated with the event occurrence.

In a collaborative federation, since events, rules, triggers and operations can be defined by

different collaborating organizations, terminology becomes an important issue. Specific terms

used by an organization in its event, rule, trigger and operation specifications and in metadata

descriptions can be quite different from those used by another organization. People searching for

registered events and web services need some form of common ontology to resolve these

discrepancies. It would be beneficial to define an ontology for a particular application domain in

a collaborative federation. Thus, the host site in the system architecture also incorporates an

ontology database to contain the terms used in event, rule, trigger and operation specifications, in

event data and in metadata of these information and knowledge resources, and their mappings to

concepts and concept associations defined in the domain ontology. The architecture also includes

an ontology manager to resolve discrepancies and identify similarities between the specified

terms, and to facilitate search. These components are included to give the reader a complete

picture of the collaborative system. It should be noted that the design and implementation of such

an ontology database manager is beyond the scope of this work.

The user interface tools at the host and the collaborating sites aid users in the definition

and maintenance of events, rules, rule structures, triggers and operations. These tools use the

local security and access control policies to ensure that only authorized users get access to the

system. These tools also provide the facility for creating and maintaining the domain ontology.

However, their design and implementation is not one of this author' s contributions. They have









been implemented by one of the members in the group working on application of the event and

rule processing ideas in the NPDN domain.

We have implemented the algorithms presented in Chapter 4 for converting knowledge

rules and rule structures to web services in Java, with the Sun Java System Application Server

Platform Edition 9.0 [66] as our application server. The event and rule servers have been

implemented using the Enterprise JavaBeans 2. 1 framework [46]. To facilitate easy and efficient

lookup, we publish the deployed web services to our private UDDI registry. This registry makes

use of the Apache jUDDI proj ect [73] to communicate with MySQL Server 5.0 [48] that stores

the web service information. The My SQL database is also used by the event server to store the

event and trigger information. We use a private registry instead of a publicly available UDDI-

based registry for two reasons. By eliminating clutter typically found in a business registry, we

speed-up registry look up. Also, a private registry provides security, as it is available only to the

organizations participating in a collaborative federation.

The Sun Application Server provides many tools which facilitate the easy development of

a web service. The bulk of the work is in generating the rule-specific source code. In addition,

the following configuration files are needed to deploy the web service: config.xml, web.xml, sun-

web.xml, and jaxrpc-ri.xml. The createConfigFiles function (Figure 4-1) uses the information

from the service interface file to generate these configuration files. The web service is then

compiled using the wscompile tool of the application server. This generates the WSDL

description file and the service is then deployed using the wsdeploy tool of the application server.

Once the service is deployed, it is published at the host site using the UDDI4J [67] API.

The general event and rule processing strategy is as follows. When an event occurs at a

collaborating site, the event data are first captured in an XML document. The site of occurrence










now becomes the coordinating site (or coordinator) for this particular event processing scenario.

The coordinator needs to determine the sites that contain applicable rules and/or rule structures

(i.e., applicable sites) so that event data can be sent to them. Applicable sites are of two types.

The first is those sites that have defined explicit triggers linking the event to one or more rules

and/or rule structures. The second type is those sites that do not define explicit triggers, but do

have rules and/or rule structures whose input data items are a subset of the event data items (i.e.,

applicable rules and/or rule structures). Such rules and/or rule structures can contribute to the

event data and thus should be processed. Our system generates implicit triggers for the second

type of applicable sites, details of which are described later.

To determine the applicable sites, the coordinator queries the host event server passing the

event data as the query input. The host site first examines the explicit triggers to determine the

first type of applicable sites. For the remaining sites in the federation, the host site examines the

published rule information to determine if any site contains applicable rules and/or rule

structures. Once the coordinator receives this site information, it sends the XML document

containing the event data to these sites' event servers. These event servers pass the event data to

their corresponding local rule servers. Each local rule server carries out a three-step process. In

the first step, it examines the explicit triggers and records the rule and rule structures that need to

be processed. In the next step, it examines the event data and determines the rules and/or rule

structures whose input is a subset of the event data. These rules and/or rule structures are also

recorded. In the last step, it examines the recorded rules to see if any of them will be executed as

part of a rule structure. A rule structure is specified by a decision-maker, and captures the

required order of execution for the rules that participate in the structure. Thus, any applicable

rule that is already part of an applicable rule structure, if processed individually, will result in the










same rule being processed twice. Also, the processing of individual rules may not honor the

order of execution. Thus, applicable rules that will be processed as part of an applicable rule

structure are removed, and the remaining applicable rules and/or rule structures are processed.

The processing of these applicable rules and rule structures may add data to or update the

data in the event data document. They may also activate automated or manual operations that add

or modify the event data document. Each applicable site returns its possibly updated event data

document to the coordinator. The coordinator then merges all the event data documents to create

a new version of the event data document to be sent out to applicable sites in the next round.

During the data merging process, the coordinator identifies and separates event data information

into old and new. It also detects inconsistencies and determines if any cyclic rules will be

processed in the next round. Details of event data aggregation, detecting inconsistencies and

avoiding cyclic rule execution will be presented in Chapter 6. At the beginning of every round of

event data transmission and rule processing, the coordinator asks the host site for the applicable

sites and sends the new version of event data document to them. There is one difference,

however, in determining applicable sites as well as applicable rules and rule structures in the

second and subsequent rounds. To determine whether a particular rule or rule structure is

applicable in a round other than the first one, we also employ the condition that at least one of

the rule's or rule structure's input data items must have been added/modified in the previous

round. This is to prevent the processing of the same set of rules and rule structures on the same

event data.

Once no more applicable sites can be determined, the process of event data transmission

and rule processing terminates. All sites involved in this process would have received the final









event data document that contains all the data that are relevant to an event occurrence. The data

can be used by these organizations for further decision-support and problem-solving.

Event-triggered Processing of Rules and Rule Structures in the EU-Rent Domain

In this section, we use an example scenario of the EU-Rent application domain to explain

how the general event and rule processing strategy described above can be applied. We shall also

explain how a rule structure is decomposed and processed. The complete set of events, rules, and

rule structures derived from the EU-Rent rule set is included in Appendix B.

We have used our knowledge specification language to define EU-Rent' s rules and rule

structures, convert them to code, and register them as web services. The total number of rules we

obtained from [38] is 46, 29 of which are CAA rules, 13 of which are integrity constraint rules

and 4 of which are derivation rules. There were also 9 rule structures discernible from the rule

set. Each of these rules and rule structures took about 6-7 seconds to be converted, compiled,

deployed and published as a web service on a Windows XP machine with an Intel Pentium 4

processor and 1 GB RAM. The maj or component of the total time required for web service

creation is in the compilation, deployment, and publication activities. The time taken to generate

the appropriate service interface, implementation and configuration files has little impact on the

total time. As a result, the web service creation time is more or less independent of the rule type.

To demonstrate the event-triggered processing of distributed rules and rule structures, we

use the following scenario (Figure 5-2). A customer approaches a local branch Branch1 with the

request for a car rental. Branch1 is unable to satisfy his/her request. It posts an event Reservation

Request and the event data in XML format is sent to all subscribing branches. The event data

contains information about the customer and the type of car desired. Assume that Branch2,

Branch5 and Branch8 are branches that have the applicable rule structure shown in detail for










Branch5. As all the EU-Rent branches have similar rules, a similar rule structure is defined at

each one. Details of the rules that are used in the rule structure are given in Appendix B.

The rule structure checks if the driver of the car satisfies some required constraints by

means of the rule driverCheck. In parallel, a check is made to ensure that the branch will not

exceed its capacity by approving the request through the rule capacityCheck. If no group or

model is specified, a default group of 'A' is considered due to the derivation rule

noGroupAndl\dodelSpecified. A suitable car is determined based on the group or model through

the CAA rule a;ssignCarOn~odelOrGroup If a custom er i s in the company' s loyalty incentive

scheme, or a suitable car cannot be found, an upgrade is given through the CAA rule

give Upgrade. If even then, a suitable car cannot be found, availability of a car from the next

day's reserved quota is determined, suitability of a bumped upgrade or a downgrade is

considered, or availability of a car scheduled to be returned earlier on the pick-up day is

determined.

The event data file contains new data resulting from the application of these rules at

Branch2. This data is returned to Branch1 (the coordinating site of the event). Branch1 receives

the updated event data from Branch2, Branch5, and Branch8 (not shown). Branch1 then merges

this data and sends out the new version of the event data to all branches (not shown) because

there may be rules and rules structures that are applicable to the new version of event data. In our

scenario, we assume that there are no new applicable rules. Branch1 can then apply a local rule

to select the branch among the three which preferably has the requested make and model

available and is also the closest. Also, all other branches receive the Einal version of the event

data, which can be used for their local decision-support and problem-solving. The implemented

prototype system runs on multiple computers.










Decomposition of Rule Structure

We use the same scenario to present the technique used to decompose a rule structure into

substructures for processing. A rule structure is a directed graph, in which rules (nodes) can be

interconnected by link, split, and-join and or-join constructs (edges). An XML document

however, organizes its constituent elements in a tree structure. Each of the four rule structure

constructs, if considered independently, can be represented using a tree (by means of the

predecessor-successor relationships), but the combination of these constructs that forms a

particular rule structure may not always be a tree (Figure 5-2). It is worth noting that, if we break

a rule structure into substructures, where each represents a single structural relationship between

two or more rules, each substructure is a tree, and can now be represented by using XML. This

does result in the same rule being referred at a maximum of two times, first when describing the

relationship where this rule is a successor, and the next when describing the relationship where

this rule is a predecessor. Rules that have no predecessors or successors still appear only once in

the representation.

The directed edges of a rule structure specify the order of execution of the constituent

rules. This order is reflected in how the XML elements representing each substructure are

ordered in the rule structure document. For a given rule structure, substructures are generated as

we move from the top to the bottom of the graph. At any level, we follow a left to right ordering,

thus if sub structure S1 is to the left of sub structure S2, S1 will be generated first. Taking the rule

structure from Figure 5-2 as an example, the first sub structure to be generated would be for the

link construct with getBranch as the predecessor rule and capacityCheck as the successor rule.

The second sub structure generated would be for the and-join with driverCheck and

capacityCheck as the predecessor rules and noGroupAndl\~odelSpecified as the successor rule.

After two link structures linking noGroupAndl\~odelSpecified with a;ssignCarOn2\odelOrGroup,










and a;ssignCarOn2\~odelOrGroup with giveUpgrade, the final substructure would be the split

construct with giveUpgrade as the predecessor rule and allocateNextDay, bumpedUpgrade,

downgrade, a;ssignScheduledCar as the successor rules. The above scenario takes about a total of

3 seconds for the requesting branch to send out its event data fie to remote branches and for the

remote branches to invoke the applicable rules and send the updated event data fie back to the

requesting branch.

If we revisit the algorithm for converting a rule structure to a web service (Figure 4-6), we

see that substructures are processed in the order specified in the rule structure document, which

reflects the actual order of the rule structure. The program statements for each substructure are

generated by the respective handler routines. Each routine checks if the toBeExecuted array

contains the predecessor rule(s). This check is important since the predecessor rule(s) for a

particular substructure might be the successor rule(s) of an earlier substructure, and thus may

already be either executed or at least in the pipeline. This check in combination with the proper

ordering of the substructures ensures that rules are always processed in the correct order during

the actual execution of the rule structure.

Decomposing a complicated rule structure into simpler substructures also facilitates the

maintenance of the structure. Inserting a new relationship into an existing rule structure

document requires only creating the appropriate substructure and inserting it into the correct

position in the document. Similarly, deleting and modifying a structural relationship need to

address only the substructure that represents that relationship, without affecting other parts of the

rule structure document.









Event-triggered Processing of Rules and Rule Structure in the NPDN Domain

In this section, we provide more details about the NPDN application domain and use an

example scenario from this domain to describe how the general event and rule processing

strategy is applied.

The key organizations in the NPDN environment and their functions [50] are given below:

* NPDN Triage Lab: The state facility designated to receive and examine suspect samples.
This lab is often associated with the state Land Grant University, but in some states is part
of the state department of agriculture.

* NPDN Regional Hub Lab: The key coordinating lab for an NPDN region. Currently, these
labs are located at the California Department of Food and Agriculture (WPDN), Kansas
State University Department of Plant Pathology (GPDN), Cornell University Department
of Plant Pathology (NEPDN), Michigan State University Department of Plant Pathology
(NCPDN), and University of Florida Department of Plant Pathology (SPDN). These labs
provide coordination, training, funding, and surge capacity support to the NPDN triage
labs within their region and occasionally to other regions.

* APHIS-PPQ: Animal and Plant Health Inspection Service, Plant Protection and
Quarantine. Administered by the USDA.

* SPRO: State Plant Re ulator Official. Hi hest rankin state plant re ulator official.
The SPRO is employed by the state department of agriculture.

* SPHD: APHIS-PPQ State Plant Health Director. Hi hest ranking federal plant re ulator
official in a state.

* APHIS-PPQ-NIS: National Identification Service. The USDA-authorized lab for
diagnosing plant diseases (fungal and viral).

* APHIS-PPO-CPHST: Center for Plant Health, Science and Technology. The USDA-
authorized lab for conducting DNA diagnosis (PCR) and bacterial diagnosis of plant
diseases.

* APHIS-PPO Confirming Diagnosis Designate: The person authorized to make a
confirming diagnosis for a high risk pest. This diagnosis must withstand legal scrutiny if
challenged in court. This lab may be one of the APHIS-PPQ labs (NIS or CPHST) in
Beltsville, MD or may be one that has been approved or provisionally approved by
APHIS-PPQ or APHIS-CPHST.

Our study of the procedures used in this domain for diagnosis of plant samples has

revealed the need for the NPDN organizations to communicate with each other effectively and in









a timely manner. We provide the solution approach of capturing the procedures as rules and rule

structures to be triggered by suitable events. The complete set of events, rules, rule structures,

triggers and operations along with their descriptions, the data items they need or provide, as

obtained from the NPDN SOP draft [50] are included in Appendix C.

Distributed Rule and Rule Structure Processing in the NPDN domain

We have used our knowledge specification language to define the NPDN domain's rules

and rule structures, convert them to code, and register them as web services. The total number of

rules we obtained from [40] is 27, all of which are CAA rules. We have identified 10 different

events and 5 rule structures. The time taken to publish the rules and rules structures as web

services is similar to that in the EU-Rent domain.

As mentioned earlier, collaborating sites can also share automated application system

operations and manual operations. System operations are defined by collaborating organizations

and published as web services for use in rules and application systems. Manual operations are

manual tasks performed by people of these organizations. Each manual operation is defined in

terms of who should be notified and instructed to perform the operation, what means of

notification should be used (e.g., by email, short message to a cell phone, and/or instruction

displayed on a monitor) and what data should be provided to the system when the task has been

carried out. When a manual operation is activated by a rule, the system would notify the

appropriate person using the specified means of notification, and instruct the person to 1)

perform the manual operation, 2) inform the system when the operation has been carried out, and

3) input the data produced by the operation. Both automated and manual operations can be

referenced in and activated by rules.

We use a scenario (Figure 5-3) to demonstrate the distributed event and rule processing

technique in the NPDN domain. The scenario begins with the NPDN Triage Lab receiving a









suspect sample from the State Department of Agriculture, APHIS-PPQ, or university staff. The

NPDN Triage Lab staff that receives the sample posts a "Suspect Sample Received" event which

has information about the sample, such as the genus of the host plant, the date the sample was

collected, etc. This event data is encapsulated in an XML document and processed by the rule

structure shown in the figure. The Triage Lab conducts its own preliminary diagnosis, changes

the classification from "suspect" to "presumptive positive" (Rule NTLR1 in the figure). It notifies

appropriate personnel such as the APHIS-PPQ CDD, the NPDN Regional Hub Lab, the state of

origin SPHD and SPRO, and ships portions of the sample to the NPDN Regional Hub Lab and

the APHIS-PPQ CDD (Rules NTLR2-NTLR4 in the figure). This results in the event

"Presumptive Positive Sample Received," which has applicable rule structures at the APHIS-

PPQ CDD and the NPDN Regional Hub Lab. The NPDN Regional Hub Lab may also employ a

local expert to help with the diagnosis process, in addition to conducting its own diagnosis

(Rules NHLR1, and NHLR2 in the figure). In addition, it is also responsible for contacting some

key personnel like the NPDN Regional Director (Rule NHLR3 in the figure). Optionally, it may

send the sample to the APHIS-PPQ CDD (Rule NHLR4 in the figure). The APHIS-PPQ CDD

conducts the confirming diagnosis and contacts the NPDN Triage Lab as well as the SPHD with

these results (Rules ACDDR1-ACDDR3 in the figure). This will result in the event "Results

Received" to occur at the NPDN Triage Lab (not shown in the figure). The initial event data

contain only some portion of the sample information. As diagnosis proceeds along the different

organization, more and more information about the sample is obtained. The final diagnosis

results represent a new piece of information which contains the confirmed host and pest

information about the sample.









The rule structure at the NPDN Triage Lab takes about a total of 14 seconds to execute.

The rule structures at the APHIS Lab takes about a total of 101 seconds to execute and the one at

the NPDN Regional Hub Lab takes about a total of 149 seconds. This discrepancy is mainly due

to the varied number of automated and manual operations. The actual time required for the

manual operations was not measured, as it will vary greatly in every situation; however the time

required to send the notification to the concerned individual was measured.

HOST
CS1

UI Tool 1M ODB
EventServer ++~ DB

OMS
/ RuleServer 1 UI Tool
EventServer


RuleServer 1M WSRegistry \ *~


CSn
Local Connection \'
- Remote Connection EetSre + D
CS Collaborating Site
DB Database
UI Tool User Interface Tool 1I RuleServer 1 UI Tool
WS registry Web Service Registry
OMS Ontology Management System
ODB Ontology Database

Figure 5-1. ETKnet system architecture







































Figure 5-2. Event and rule processing in the EU-Rent domain



































I


NPDN Triane Lab
Event: Suspect Sample Received (npdn.Sample Sample.*)

NTR

NTLR2



NTLR3 NTLR4


APHIS-PPQ CDD
Event: Presumptive Positive Sample Received
(npdn.Sample Sample.*, npdn.Shipment
Shipment.*")

ACDR

ACDDR2


ACDDR3


NPDN Renional Hub Lab
Event: Presumptive Positive Sample Received
(npdn.Sample Sample.*)


NHLR1


NHLR2 NHLR3


NHLR4


Figure 5-3. Event and rule processing in the NPDN domain









CHAPTER 6
RESEARCH ISSUES

Event Data Aggregation

The site of an event occurrence is termed as the coordinating site or coordinator for the

event occurrence. During successive rounds of event and rule processing, the event data are

wrapped in an XML document (termed as the parent document) and sent to explicit and implicit

subscriber sites. Each collaborating site may add to or modify the event data items. These data

items are returned to the coordinator as updated event data documents (child documents). The

coordinator is responsible for aggregating the parent and child documents before starting the next

round of processing.

At the end of each round of processing, the coordinator compares the contents of the parent

document with the child documents as follows. For each entity occurrence in the parent

document, it creates an event data structure to store that entity instance's attributes and values. It

then systematically goes through each of the child documents. For each child entity instance that

has a corresponding parent entity instance, the coordinator updates the parent instance with the

updated values shown in the child instance and adds to the event data structure the new attributes

and values obtained from the child instance. Any new entity instance in a child document that is

not in the parent document is also added to the event data structure. When all child documents

have been examined, the event data structure contains the most current states of all the entities in

the parent and child documents. Its contents are written into an XML document. If there are

explicit triggers that link an event to rules and/or rule structures, or if there are rules or rule

structures that refer to the updated event data or new event data in their input data specifications

and all of the rule or rule structure input is a subset of the event data, a new round of event and

rule processing would start by sending the XML document to the applicable sites. This process










of event notification, event data transmission and aggregation, and rule and rule structure

processing terminates when no site has a rule or rule structure applicable to the last version of

event data.

Event data aggregation is achieved by viewing the event data document as the union of two

disj oint sets, E, and D,, for round i. E, is the portion of the event data file sent in round (i-1) that

was not updated, if i >1. If i = 0, E, is empty. D, is the portion of the event data file which

includes updates and/or additions from round (i-1), if i > 1. If i = 0, D, is the initial event data

that was made available from the event occurrence. Algorithm 1, presented in Figure 6-1

explains this process in greater detail. In Figure 6-1, n, is the number of applicable sites in round

i of event processing. Below we give a correctness proof for the algorithm.

Claim: Algorithm 1 ensures that for every round i, i > 0, D, contains the data items that were

added or updated in round i-1 and E, contains those data items that were not (i.e. old

data) .

Let Gas denote the set of updates from site s in round i

Let As denote the set of additions from site s in round i

Let de denote the data item being considered from site s

Proofi (By induction)

Basis step: For round 0: Eo = O, Do = initial event data

This is correct since all data provided as a result of the event posting is considered new. At this

point there is no old data.

Induction step: Assume E,-; and D,-2 are correctly defined

For round i: E, = E,-; U D,-1, D, = O

For every data item ds, there are three possible cases,










(1) d, is unchanged from the previous round, and thus is part of the old data. Since d, was present
in the previous round, d, C E,-1 U D,-1, and hence d, C E,.

(2) ds was present in the previous round, but it' s value has now been updated, i.e. d, C Gas.
Algorithm 1 removes d, from E, and adds it to D,. This is correct since d, now has an updated
value.

(3) d, is a new data item, not present in the previous round, i.e. d, C As. Algorithm 1 adds d, to
D,, which is correct, since d, is a data item that was added. Also, de -C E,

Conclusion: Thus, repeating steps 1-3 for every data item ds will ensure that all the

updated/added data items are stored in D,, and those that were not are stored in E,. Hence proved.

Event Data Inconsistencies and Contradictions

Rules and rule structures capture the knowledge of collaborating organizations. This

knowledge reflects the opinions and experience of policy makers and experts in the

organizations. In the real world, it is very possible for experts' opinions to differ. When these

differing opinions are processed as knowledge rules, inconsistencies and/or contradictions may

anise.

Knowledge rules (converted to web services) process the data items in the event data

document and as a result may generate new data items (additions) or update the existing data

items (updates). The event data documents of collaborating sites are returned to the coordinator.

When the coordinator aggregates all the event data documents, it may find that inconsistent data

values are given to an attribute of the same entity. A special case of inconsistency arises when

the attribute is of the Boolean type and contradictory truth values are returned. From here on, we

shall use the term conflict to mean either an inconsistency or a contradiction.

When a conflict is detected, we propose to resolve it in the following manner.

Collaborating organizations can decide to adopt a global resolution rule to determine the value of

a particular data item in case of a conflict (e.g., by taking the minimum, maximum or average of

conflicting values). However, if there is no such global resolution rule for a data item, one










approach is to require all sites to attach their identities with the values they produce and the

coordinator to transmit event data with site ids in the next round of event and rule processing.

When a collaborating site receives conflicting values tagged with site ids, it can adopt a local

resolution policy to decide which site it trusts the most and adopt the value supplied by that site.

In the absence of both global and local resolution policies, rules and sites that generated the

conflict values can be recorded and appropriate organizations can be informed to resolve the

conflict by eliminating or modifying some rule(s). The algorithm shown in Figure 6-1 describes

the detection and the resolution mechanism employed by the coordinator.

Let (E, + D,) be the event data file sent out in round i. Us denotes the updates sent to the

coordinator by site s for round i, and As denotes the additions sent to the coordinator by site s

for round i. Let n, be the number of sites that were applicable for round i. Let u" and as denote the

value of an update or addition respectively tagged with the source site s. Let 0 denote the empty

set. Let UC be the set of conflicting data items due to updates and let AC be the set of conflicting

data items due to additions.

The algorithm looks at each data item sent in from a site s, and determines if there is a

conflict for that data item, by checking if it was already updated by some other site s '. If so, it

applies the global resolution policy if one exists, and replaces the conflicting value with the

resolved one. If not, it tags a particular value of the data item with its source and includes it in

the event data document to be sent out. As each data item for a particular site is examined once,

the algorithm has a complexity of the order O(mzn,,, where m, is the number of applicable sites

for a particular round i, and n, is the number of data items present in the event data document

returned by site m. So, on average, the complexity can be assumed to be O(m'n), where m', and









n' are the mean values for a particular event processing scenario. Below we give a correctness

proof for the algorithm.

Claim: Algorithm 1 identifies a conflict iff it is present

Let Gas denote the set of updates from site s in round i

Let UC denote the set of conflicting data items due to updates

Let As denote the set of additions from site s in round i

Let AC denote the set of conflicting data items due to additions

Let d, denote the data item being considered from site s

Proofi For every data item d, considered in the aggregation phase,

(1) if d, C Gas and d, C D,, the algorithm compares the value of d,, denoted by d,.v with the one
stored in D,, denoted by d,(D,). v. If these values are not equal, a conflict due to update is
registered, and d, is added to UC.

(2) if d, C As and d, C D,, the algorithm compares the value of d, with the one stored in Di. If
these values are not equal, a conflict due to addition is registered, and d, is added to AC.

So, the algorithm identifies a conflict only in case of multiple values being present for the same

data item, and thus detects a true conflict. Hence proved.

Avoiding Cyclic Rule Execution

Distributed knowledge rules and rule structures are independently and dynamically defined

by collaborating organizations. During event and rule processing, each applicable collaborating

site processes the relevant rules and returns the data items produced by these rules. This may

trigger some other rules in the next round of processing. It is possible that a set of distributed

rules may get locked into a cycle.

This issue, more commonly known as the "termination problem" for active rules has been

widely studied [7, 19, 37, 42]. All of the work in this area addresses the issue of static

determination of rule termination. The maj ority of these works use the concept of a triggering










graph [17]. In [2], a basic static rule termination algorithm is described. This analysis does not

consider the possible deactivation of a rule's condition. Works such as [5, 42] do take into

account this consideration. Also, in most cases, the rule set is globally known or a global rule set

is assumed to be available for rule termination analysis [6]. The work in [19] does not assume the

knowledge of a global rule set. However, all of these methods address static termination analysis.

In our event- and rule-based system (ETKnet), knowledge rules are dynamic. Thus, the "global"

rule set is constantly changing. Multiple rules can be defined, updated, suspended or reactivated.

Thus, the above approaches become inapplicable.

The existing approaches consider termination of active rules in the active database

paradigm. In this environment, active rules update a database relation on occurrence of a

triggering event. These rules are usually expressed as ECA rules. The condition expression is a

query on the current database state, and is true if the answer relation is non-empty. In ETKnet,

we do not directly operate on a global database, however, the current event data document can be

viewed as the current "database state". Since the above approaches aim to determine termination

at build-time, they cannot consider the run-time values of data items. Thus, a build-time

algorithm must always assume that the action in the triggered rule will get executed, and hence

new data will be introduced as a result of the action. However, at run-time, a rule condition may

not be satisfied, causing no execution of the action specified in the rule, making the above

assumption false. As a result, in the ETKnet environment, use of static termination analysis can

accurately determine termination, but not non-termination. For the above reasons, we resort to a

run-time approach to guarantee termination of rule processing.

We derive some concepts for rule termination from the theory on deadlock detection and

deadlock avoidance in modern operating systems. Let us consider the concept of detection and









recovery first. This approach allows a cycle to occur, detects it, and then deactivates some rule(s)

to break the cycle. This is an acceptable approach to handle deadlocks since the deadlocked

processes are stalled until the deadlock is broken. For distributed rule processing, however, if the

rules locked in a cyclic processing are allowed to continue processing, the data values they

produce may activate other rules, causing some non-idempotent operations to occur. Recovery

from such a scenario is not always possible. As there is no guarantee that every cycle is self-

contained and does not affect other rules, this approach is not desirable for rule termination.

Rule termination can best be guaranteed by avoiding cycles altogether. Our avoidance

strategy combines pre-computing possible rule cycles that can occur for every event with rule

monitoring at runtime by the coordinating site. Thus, the coordinating site can make a runtime

decision on whether or not a cycle exists. We explain the definition time process and runtime

process below.

All shared distributed knowledge rules are registered at the host site. Thus, the host site has

full knowledge of the input and output specifications of each rule. When an event is registered at

the host site, it determines the applicable rules based on the initial event data specification and

each applicable rule's input data specifications (i.e., only attributes of entities referenced but not

their data value conditions). It then simulates the processing of that event. Starting with the set of

rules that are applicable to the event data, the host site examines the output of these rules to

determine those rules that will possibly become applicable in the next round of event processing.

It keeps track of all executed rules in each round of event processing. For example, let us assume

that during the processing of a particular event E, rules R1, R2, R3 will be executed in the first

round, rules R4, R5, R6, R7, R8, R9, will be executed in the second, and rules R10, R11, R12 in

the third round. The host will record the following information:










R1, R2, R3 R4, R5, R6, R7, R8, R9 R10, R11, R12 .... (1)

where the -symbol is used to denote the next round of rule processing. If, during a round

of event processing, the host site determines that a rule Rc, that was executed in the previous

round is applicable again in this round, it treats this as the beginning of a possible cycle. Rc is

thus marked as a "cyclic rule". For each Rc, the host site looks at all rules executed in the

previous round to determine the set that can provide any item iRc (an input item to Rc) as their

output. Let us call this set, R,, to denote the rules that can possibly trigger the execution of Rc.

Each rule in this set is recorded, and all such rules are Boolean "OR"ed together. This

information thus has the following form:


V r2 .... (2)



where each r, (1
For example, assume that in the third round of processing the same event E, R1 (with four

input items a, b, c and d) is made applicable again due to the fact that rule R4 updates data item

a, R7 updates data items a, b, and c, and R9 updates data items a and b. The expression

R4 VR7 VR9 .... (3)

will be recorded for rule R1.

As Rc was executed once earlier, an update on any one of its input items in a round of

processing will result in the rule being applicable for the next round. Using the above example,

execution of any of the rules R4, R7, and R9 will cause at least one of R1's input data items to be

updated, thus making R1 applicable for processing in the next round. The host stores information

about all cyclic rules until it determines that no new rules can be executed in the next round of

processing. It is possible that multiple cycles for a single rule exist. In such cases, the host will









calculate the rule expression for Rc for the current round, and use this to update any previous rule

expressions computed for Rc. This rule termination information is stored for every registered

event. The algorithm for the above process is described in Figure 6-2. The process to compute

the rule expression is described in Figure 6-3. The function in Figure 6-3 iterates over all rules

over all input items i in r,. Step 4 in the function examines each output item of r, to check if i is

contained in r,.output, and also examines each rule in Rexp to check that r, is not already

included in Rexp. This step takes a total of (r+n) time, where r is the total number of rules in

Rexp, which is at most the total number of defined rules, and n is the number of output items in

r,. Assuming each rule has n input and output items, the complexity of the function

computeCyclicExpression is of the order O(rn(r+n)). This is the most expensive calculation in

Algorithm 2. The algorithm iterates over all rules in R,, which in the worst case be all of the

defined global rules. This is repeated until there are applicable rules that have not been

examined. In the worst case, each iteration of the while loop just adds a single rule, and all

defined rules are applicable to the event, making the worst-case complexity of the order

O rn(r~) 3

Claim: In round i, The rule expression expr computed for a possibly cyclic rule rc using function

1 is necessary and sufficient to predict whether or not the rule will be re-executed in round



Let r, denote the possibly cyclic rule being considered

Let i,, denote a single input data item for rc

Proofi After processing a given round i, the sets E, and D, contain all the old and new/updated

data items respectively. Event data items are never deleted, they are only added or they move

between E, and D,. When determining whether r, will be re-executed in i+1, we know that r, has










already been executed in some previous round p, p < i. Thus, all of the input data items ic are

already present in (E, U D,). An update on any input data item ic will make rc applicable for

processing in round i+1. Examining only the previous round is sufficient as the rules executed in

all rounds q, q < i either do not contribute to rc's input, or have already derived a different rule

expression for r,. Function 1 examines each rule executed in round i and Boolean "OR"s all

those rules Rexp that contribute to rc's input. Thus, if any rule r, r C R, is executed, the rule

expression becomes true and rule r, becomes applicable in round i+ 1. Similarly, if the rule

expression is determined to be true, it implies that at least one r, r C R, has been executed. As

the rule expression captures exactly this and only this property of determining when any input

item ic is updated, the rule expression is necessary and sufficient to predict whether or not the

rule will be re-executed in round i 1.

When a new global rule R., is added, it is registered at the host site. The host must

determine what events can cause this rule to be processed, and accordingly update the rule

processing path, similar to that shown in (1), and any information for cyclic rules, similar to that

shown in (2). To achieve this, the host first determines if any event can directly provide the input

for R,,w, and records this information. Next, for each input item, iRnew, the host determines the

rules that can provide this input item and Boolean "OR"s them together. Let us denote the set of

rules that can provide input item iRnew to be R,. Finally, such expressions from each input item are

Boolean "AND"ed together to get the expression, which if true, can cause rule R,,, to be

processed, and has the following form:


A ( V rz) .... (4)
i=1 j=1










where 1
provide item i as input to Rome, A1 is the Boolean AND operator, and Vis the Boolean OR

operator.

Once the host computes the above expression, it examines all processing paths stored for

every event, and checks if this rule expression satisfies any of them. If so, the processing of this

event may likely include Rme. Once all such affected events are determined, the host goes

through the algorithm shown in Figure 6-2 again to determine the processing and cyclic paths for

each event. The algorithm for the above process is shown in Figure 6-4. The most expensive step

in Algorithm 3 is step 22, where Algorithm 2 is invoked for every affected event. In the worst

case, all of the e events can be affected by a rule, and hence the complexity of the algorithm is of

the order O(er~n(r+n)), where e is the number of registered events.

At runtime, when an event occurs at a collaborating site, this site, now called the

coordinator, downloads the cyclic path information for the event from the host site. Every

applicable collaborating site needs to return the rules that were executed in a given round of

event and rule processing back to the coordinator. The coordinator then examines the rules that

were actually executed and compares it with the cyclic path information to determine if the next

round of event and rule processing will lead to a rule cycle. If so, the site where the cyclic rule

will be executed is asked to deactivate the rule. For example, assume that the event E with the

possible rule processing scenario mentioned in (1) occurred and R1 and R3 were executed in

round 1. In round 2, assume that only R5 was executed. With this information, the coordinator

determines that the expression shown in (3) is not satisfied. If, on the other hand, during the

processing of round 2, rule R4 was also executed, the coordinator would know that R1 will be









executed in the third round causing a cycle. Thus, R1 is deactivated for that particular round to

avoid the cycle.

Claim: Any rule processing initiated for a given event terminates.

Proofi For a given event, there are three processing scenarios:

(1) The host determines that the rules processed for this event can never get locked into a cycle.
Thus, event processing eventually terminates.

(2) The host determines possible cyclic paths of execution. In every round, the coordinator for an
event examines these possibly cyclic paths and determines whether or not a particular rule
will be executed in the following round. If a cyclic rule is predicted to execute in the
following round, it is deactivated for that round. Thus, cycles are avoided and event
processing eventually terminates.

(3) During event processing, one or more new global rules that can cause cycles are introduced
into the system. Whenever rules are defined at a collaborating site, they are inactive until
registered with the host site. During registration, the host site computes the possible cyclic
paths as explained in Algorithm 3. Thus, when the host registration is completed, possible
cyclic paths for this rule have been updated. The rule now becomes active and can take part
in the event processing. The coordinator requests cyclic path information at the beginning of
each round of event processing. Thus, in the next round after the rule registration, the
coordinator receives the updated possible cyclic paths. The new rule can be executed at most
once before the coordinator becomes aware of the possible cyclic paths. From now on, this
becomes similar to case 2, and event processing eventually terminates.

The above approach is better than static termination analysis methods because it takes into

consideration the fact that rules are dynamically introduced and updated, and also takes runtime

data values into account when determining likely rule cycles. However, the general problem of

rule termination is undecidable [4], and so the best we can do is to take a conservative approach

and treat every second occurrence of a rule in a given event processing scenario as the beginning

of a cycle. Since correctness is more important than performance, the proposed algorithms

represent a useful step towards achieving rule termination. As the performance data (Table 6-1)

shows, a huge percentage of the build time process is spent in pre-computing possible cyclic

paths, even as high as over 90%. However, the run time overhead is less than 1% at all times.

This is acceptable since the build-time performance drop is a one-time occurrence.









It is possible to have self-terminating rule cycles, which are not handled by our approach.

To understand this, consider the situation where we have the following rule cycle, R1- R2-

R3- R1. It is possible that after a few rounds, the output item produced by R3 does not satisfy

the input condition of rule R1, and hence it is no longer executed, i.e. the cycle has been broken.

It is unreasonable to expect that the system should predict such self-terminating cycles. A better

approach would be to enable operation-level sharing and powerful looping constructs, so that a

desired "self-terminating cycle" or "program loop" can be described. This is, however, beyond

the scope of this work.

Table 6-1. Build time and run time overhead of the cyclic rule avoidance strategy
Number of rules (% cyclic) Build time overhead (total) ms Run time overhead (total) ms
10 (10) 121 (155) 16 (4890)
10 (50) 153 (165) 15 (4828)
10 (90) 189 (196) 15 (4745)
20 (10) 123 (159) 21 (5170)
20 (50) 171 (212) 15 (5216)
20 (90) 212 (250) 18 (5240)
50 (10) 137 (178) 15 (11941)
50 (90) 541 (593) 15 (11648)
100 (10) 212 (237) 15 (22268)
100 (50) 674 (744) 18 (22030)
100 (90) 1514 (2229) 17 (22733)
250 (10) 125 (515) 15 (56371)
250 (50) 139 (3498) 29 (56804)
250 (90) 139 (8583) 40 (57300)









Algorithm 1 aggregateAndIdentifyConflicts


(1)
(2)
(3)
(4)
(5)
(6)
(7)
(8)
(9)
(10)
(11)
(12)
(13)
(14)
(15)
(16)
(17)
(18)
(19)
(20)
(21)
(22)
(23)
(24)
(25)
(2 6)
(27)
(28)
(29)
(30)
(31)
(32)
(33)
(34)
(3 5)
(36)
(37)
(38)


Eo = O, Do = initial event data, U= @, A = O
i = 1
do {
U = @, A = Q;
determine applicable sites and send event data for rule processing
E, = Ez -; U D,, D, = O, UC = @, AC = Q;
for s from 1 to n,
if Us / 4
for each d, C Us
if (d, C D, A d,.v / d, (D,).v ) UC = UC + d,;
end if
if(d, -C D,) D, = D, U d,;


E, = E, ds;





AC =AC+ d,;

D, = D, U d,;


end if
end for
end if
if As /
for each d, C As
if (d, C D, A d,.v / d, (D,).v )
end if
if (d, -C D,)
end if
end for
end if
end for
D, = D, ( UC U AC);
for each uC~ UC


if (globaltres_policy(u)
else
end for
for each aC AC
if (globaltres_policy(a) I
else
end for
U = U U Uz ;
A =AU A2S;
i++;
}while(UUA / Q);


:tre)


=D, U resolve(u);
D, U us


= D, U resolve~a);
D, U as


true) D,
D,


Figure 6-1. Algorithm to aggregate event data and identify conflicts









Algorithm 2 findCyclicPaths


(1) D = set of event data, ND = @, Re = O, Ro = O
(2) R,= all rules r s.t. r.input CD
(3) initialize path to a blank string;
(4) for each r C R,
(5) Re Re U r;
(6) Ro = Ro U r;
(7) ND = ND U r.output
(8) end for
(9) for each r C Ro
(10) add rto path
(11) end for
(12) add path separator (-) to path;
(13) R,= Q;
(14) i 1;
(15) do
(16) R, = 4;
(17) R, = all rules r s.t. r.input C (D U ND) and r.input not all in D
(1 8) D = ND U D, ND = O
(19) for each r C R,
(20) ifr r Re
(21) computeCyclicExpression(r, R,-1);
(22) else
(23) Re = Re U r;
(24) R, = R, U r;
(25) ND = ND U r.output;
(26) end else
(27) end for
(28) i++;
(29) for each r C R,
(3 0) add r to path
(31) end for
(32) add path separator (-) to path;
(33) while R, / O

Figure 6-2. Algorithm to find possible cyclic paths on registration of an event









Function: computeCyclicExpression(r,, R )voud

(1) Rexpr ~
(2) for each iC~ r,.input
(3) for each rule r, C RprevRownd
(4) if iC~ r,.output A r, -C Rev,,
(5) Rxr=Rx; p
(6) end if
(7) end for
(8) end for
(9) initialize expr to a blank string;
(10) for each rule rC Rexpr
(11) add r to expr using the Boolean OR operator;
(12) end for
(13) store expr for cyclic rule rc;


Figure 6-3. Algorithm to compute the rule expression for a possibly cyclic rule

Algorithm 3 updateCyclicPathsForRule

(1) rs,,, = newly added global rule;
(2) R = set of defined global rules;
(3) for each input item i ~r ,, i npult
(4) R, = O;
(5) for each rule rC~R
(6) if iC~ r.output R, = R, U r;
(7) end if
(8) end for
(9) exprR, = Boolean OR expression linking rules in R,;
(10) end for
(11) exprR,w,, = Boolean AND expression linking all exprR,;
(12) E = set of defined events;
(13) AE = Q;
(14) for each event e CE
(15) if rnes..input C e.data AE = AE U e;
(16) else
(17) path = execution path for this event;
(18) if exprR,w,, is satisfied by path AE = AE U e;
(19) end else
(20) end for
(21) for each event e C AE
(22) invoke algorithm findCyclicPaths for e;
(23) end for


Figure 6-4. Algorithm to update possible cyclic paths on addition of a global rule









CHAPTER 7
SUMMARY, CONTRIBUTIONS, AND FURTHER RESEARCH

In this dissertation, we have presented the basic problem of resource sharing among

collaborating organizations. Complex problems faced by government organizations and business

enterprises can be more effectively solved if organizations that form a collaborative federation

are given the following facilities, system and infrastructure to effectively and efficiently define

and share not only data, but also knowledge and application operations:

* A knowledge specification language and user interface tools for defining events of
common interests, knowledge rules to capture organizational and inter-organizational
policies, regulations and constraints, rule structures to model processes and operational
procedures, triggers to link distributed events with rules and rule structures, and sharable
application operations (automated and manual) to perform the needed tasks.

* A distributed, event- and rule-based system capable of delivering and aggregating data
associated with event occurrences, and triggering the processing of applicable knowledge
rules, rule structures, and application system operations (automated and manual).

* A web service-based infrastructure to achieve the uniform processing and interoperation of
knowledge rules of different types and application (automated and manual) operations.

In this dissertation, we have presented our idea of managing dynamic event data and

sharing multi-faceted knowledge and application operations among collaborating organizations.

Different aspects of knowledge are specified in three different types of rules and rule structures.

When an event of interest to a federation occurs, the initial event data serve as input to applicable

rules and rule structures. These rules and rules structures may add to or modify the event data,

and activate application operations, which may also add to or modify the event data. The new

event data may make some other rules and rule structures applicable. Thus, multiple rounds of

event data transmission and aggregation, and rule and rule structure processing would be carried

out by the system until all the collaborating organizations have processed their applicable rules

and rule structures and received all the data that are relevant to the event occurrence. Techniques

and algorithms for the distributed processing and interoperation of events, rules, rule structures,










triggers and application operations for supporting decision-making and problem-solving are the

main focuses of this research.

The approach taken for achieving their interoperation is to translate rules and rule

structures into code and wrap them as web services for their discovery, invocation and

interoperation in a web service infrastructure. A knowledge specification language, and the

architecture and implementation of an event- and rule-based system have been described. We

have also discussed the research issues of event data aggregation, detecting event data

inconsistencies, and avoiding cyclic rule execution and presented our solution approaches for

them .

The specific contributions of this work are as follows:

* We have developed an XML-based knowledge specification language for organizations to
specify their knowledge in terms of three types of rules and rule structures. As yet, there
exists no standard markup language which allows the specification of all three types of
knowledge rules. Our knowledge specification language integrates the syntax of each
different rule type and is a step towards achieving a markup language capable of capturing
multifaceted knowledge.

* We have developed algorithms for converting different types of rules to web services and
the strategy for processing a rule structure to demonstrate the interoperation of
heterogeneous rules. Instead of using three different types of rule engines to process the
corresponding type of rule, we convert rules to code and wrap them as web services. This
is a compilation approach which is more efficient than the interpretive rule engine
approach. Also, conversion to a web service exposes each rule in a uniform manner
making it more open to interoperability.

* We have researched techniques for managing dynamic event data and processing
distributed knowledge rules, rule structures and application operations. Any collaborating
site can be a potential event provider. Each site should thus have the capability of
coordinating a particular event occurrence. This is achieved by developing a peer-to-peer
server system rather than a client-server system. We have developed a distributed event-
and rule-based system to achieve inter-organizational event data and knowledge and
operation sharing. Business or knowledge rules exposed as web services lend themselves
easily to sharing.

* We have developed and implemented algorithms for aggregating distributed event data,
avoiding non-terminating processing of cyclic rules as well as techniques for handling
inconsistent and contradictory data introduced by different organizations.










*We have applied the knowledge specification language, the distributed, event- and rule-
based system and the web service infrastructure in two application domains (e-business
and agriculture homeland security) to demonstrate their utilities to achieve resource
sharing among collaborating organizations.

Through this R&D work, we have laid the foundation of a distributed knowledge sharing

system. Further work needs to be carried out to make the system deployable in real world

environments. For example, when different organizations interact, there is always the issue of

semantic heterogeneity in the language terms used to define data, events, rules and operations.

Thus, there needs to be an ontology and an ontology management system to reason over the

underlying concepts of these terms, and resolve their semantic discrepancies. Also, our rule

language captures a very basic form of the CAA rules. The action and alternative action clauses

can be made more expressive, thereby extending the rule language's capabilities to capture more

complex structures of operations found in workflows. An event occurrence marks the beginning

of a new transactrtrtion.rt~r~rtrt~ It triggers the processing of rules, rule structures and application

operations. The applicability of ACID properties of transaction in this event-triggered rule

processing environment needs to be examined, and techniques of transaction management need

to be investigated. Trust and security management in a collaborative environment is also an

important topic of further research.











APPENDIX A
XML SCHEMA DOCUMENTS

RuleBase.xsd




targetNamespace= "http://www.dbcenter.ciseuleurls elementFormDefault= qualified"
attributeFormDefault= "unqualified">
















=" String"/>
="double"/>
="float"/>
="int"/>
="boolean"/>
="j ava.io.File"/>
="j ava.util.Date"/>
="j ava.util.HashMap "/>
= "npdn. Sample"/>
="npdn. Shipment"/>
= "npdn.ResponsePlan"/>
="npdn.Result"/>
="eurent.Branch "/>
="eurent. Car"/>
="eurent.Rental"/>
="eurent. Group"/>
="eurent. Customer"/>
























































































































































































































































































































































































































































































RuleStrue.xsd



xmlns:rulestruc="http ://www.dbcenter.cise.ufl .edu/rulestruc"
xmlns:xs="http://www.w3 .org/200 1/XMLSchema" elementFormDefault="'qualified"
attributeFormDefault= "unqualified">





































































































































EventData.xsd


xmlns:xsd="http://www.w3 .org/200 1/XMLSchema"
xmlns:eventdata="http://www.dbcenter. cise.ufl .edu/eventdata" elementFormDefault="'qualified"
attributeFormDefault= "unqualified">








































Events.xsd


xmlns:xs="http://www.w3 .org/200 1/XMLSchema"
targetNamespace="http://www.dbcenter.cisufed/vn" elementFormDefault="'qualified"
attributeFormDefault= "unqualified">





























































Operations.xsd


xmlns:0perations= "http://www.dbcenter.cis~f~d/prtos
xmlns:rulebase="http:.//www.dbcenter. cise.ufl.edu/rules"
xmlns:xs="http://www.w3 .org/200 1/XMLSchema" elementFormDefault="'qualified"
attributeFormDefault= "unqualified">
schemaLocation= "RuleB ase.xsd"/>


















































































APPENDIX B
EVENTS AND RULES IN THE EU-RENT DOMAIN

Description of entities used


Customer:
* custlD of type integer
* licenseExpiry of type date
* insured of type boolean
* blacklisted of type Boolean
* age of type integer
* rented of type boolean
* points of type integer
* oneYearLicenseHeld of type Boolean
* nunzRented of type integer
* nunzReservations of type integer
* nunzYearlyRentals of type integer
* eligible of type Boolean
* pointsYear of type integer

Car:
* carlD of type integer
* rented of type boolean
* nzechanicalCondition of type string
* entissionsLevel2~et of type boolean
* owningBranch of type integer
* assigned of type boolean
* scheduled of type boolean
* model of type string
* group of type string
* reserved of type boolean
* serviceDate of type date
* service2~ileage of type float
* thi1 r'r.\ bombsII\\; rviceDat e of type date
* needsService of type boolean
* scheduledDate of type date
* mileage of type float
* year of type integer
* toBeSold of type boolean


Rental :
* rentallD of type integer
* driverlD of type integer
* group of type string
* model of type string
* startDate of type date
* endDate of type date
* nunzCars of type integer
* mode of type string
* driverNa~ne of type string
* creditCardNanze of type string
* driverSigned of type boolean
* addDriversSigned of type boolean
* extendedEndDate of type date
* driverOK of type boolean
* carOK of type boolean
* guarantee of type boolean
* dropOf~f~ranch of type integer
* extension of type boolean
* mileage of type float
* one Way of type boolean
* Jiee of type boolean
* bookDate of type date

Group:
* grouplD of type string
* quota of type integer
* nunzRentainingCalrs of type integer

Branch:
* branchlD of type integer
* nunzReservations of type integer
* capacity of type integer


Note: messages are sent via email, text message on the receiver's cell phone, and displayed on
the screen when a user logs in.










The EU-Rent rules used to derive the ETKnet rules and operations are also included.

EU-Rent Rules

EU-Rent Rule: Each driver authorized to drive the car during a rental must be over 25 and have
held a license for at least one year.
EU-Rent Rule: Each driver authorized to drive the car during a rental must have a valid driver's
license.
EU-Rent Rule: Each driver authorized to drive the car during a rental must be insured to the
level required by the law of each country that may be visited during the rental.
EU-Rent Rule: If the customer requesting the rental has been blacklisted, the rental must be
refused.
EU-Rent Rule: The driver who signs the rental agreement must not currently have an EU-Rent
car on rental.

The rules shown above can be implemented by the following constraint rule.

Name: driverCheck
if(Rental.driverlD = = Cusomter.custlD)
then (Customer.1icenseExpiry >= currentDate AND Customer.oneYearLicenseHeld ==
true AND Customer.insured == true AND Customer.blackLi sted == false AND
Customer.age > 25 AND
Customer.rented == false)
Type: Integrity Constraint

EU-Rent Rule: Rented cars must meet local legal requirements for mechanical condition and
emissions for each country that may be visited during the rental.
Name: mechanicalConditionAndEmissionCheck
if(Car.rented = = true)
then (Car.mechanicalCondition == 'Satisfactory' AND Car.emissionsLevelMet == true)
Type: Integrity Constraint

EU-Rent Rule: If a rental request does not specify a particular car group or model, the default is
group A (the lowest-cost group).
Name: noGroupAndModel Specified
if (Rental.group == null AND Rental.model == null)
then (Rental.group = 'A')
Type: Derivation Rule

EU-Rent Rule: Reservations may be accepted only up to the capacity of the pick-up branch on
the pickup day.
Name: capacityCheck
Branch.numReservations <= Branch.capacity
Type: Integrity Constraint

EU-Rent Rule: A customer may have multiple future reservations, but may have only one car at
any time.










Name: noMultipleCars
if(Customer.numReservations > 1)
then (Customer.numRented == 1)
Type: Integrity Constraint

EU-Rent Rule: Only cars that are physically present in EU-Rent branches may be assigned.

The rule shown above can be implemented as the following four constraint rules

Name: checkOwningBranch
Car.owningBranch == Branch.branchlD
Type: Integrity Constraint

Name: checkNotAssigned
Car.assigned == false
Type: Integrity Constraint

Name: checkNotRented
Car.rented == false
Type: Integrity Constraint

Name: checkNotScheduled
Car. scheduled == false
Type: Integrity Constraint

EU-Rent Rule: If a specific model has been requested, a car of that model should be assigned if
one is available. Otherwise, a car in the same group as the requested model should be assigned.
EU-Rent Rule: If no specific model has been requested, any car in the requested group may be
assigned.

The rules shown above can be implemented using the following CAA rule.

Name: assignCarOnModel0rGroup
Condition: Car.model != null
Action: 1. Car.group = getGroup(Car.model)
2. Car.carlD = assignCarOnModel(Car.model, Car.group)
Alternative Action: 1. Car.carlD= assignCarOnGroup(Car.group)

Type: CAA Rule

Operation get~roup definition:
Input: Car.model
Output: Car.group
Query the database for the group of the given model and return it.










Operation assignCarOnModel definition:
Input: Car.model, Car.group
Output: Car.carlD
Query the database for a suitable car by model, if no results, query by group and return the
carlD.

Operation assignCarOnModel definition:
Input: Car.group
Output: Car.carlD
Query the database for a suitable car by group and return the carlD.

EU-Rent Rule: After all assignments within a group have been made, 10% of the group quota
for the branch (or all remaining cars in the group, whichever number is lower) must be reserved
for the next day's walk-in rentals. Surplus capacity may be used for upgrades.
Name: reserveForWalkIn
Condition: 0. 1 Group.quota < Group. numRemainingCars
Action: 1. reserveGroupByQuota(Group .grouplD, Group. quota)
Alternative Action: 1 reserveGroupByRemC ars(Group.grouplD,
Group .numRem ai ningC ars)
Type: CAA Rule

Operation reserveGroupByQuota definition:
Input: Group.grouplD, Group.quota
Output:
Find the first 0. 1 Group.quota cars for Group.grouplD that have not been assigned, scheduled,
rented, or reserved, and reserve them.

Operation reserveGroupByQuota definition:
Input: Group.grouplD, Group.numRemainingCars
Output:
Find all remaining cars for Group.grouplD that have not been assigned, scheduled, rented, or
reserved, and reserve them.

EU-Rent Rule: If there are not sufficient cars in a group to meet demand, a one-group free
upgrade may be given (i.e. a car of the next higher group may be assigned at the same rental rate)
if there is capacity.
EU-Rent Rule: Customers in the loyalty incentive scheme have priority for free upgrades.

The two rules shown above can be implemented as the following CAA rule.

Name: giveUpgrade
Condition: Group.numRemainingCars == 0 OR Customer.points > 0
Action: 1. Car.carlD = upgrade(Group. grouplD,
Group.numRemainingCars, Rental.rentalCharge,
Customer.points)
Alternative Action: None










Type: CAA Rule


Operation upgrade definition:
Input: Group.grouplD, Group.numRemainingCars, Rental .rentalCharge, Customer.points
Output: Car.carlD
The system will notify the rental agent with the following message: "If the customer is in the
loyalty incentive scheme, please assign an upgrade. If the number of cars remaining in a group is
zero, please assign an upgrade. When you have done so, please log on to the system and indicate
that operation upgrade has been performed." The agent needs to provide the rental car ID as the
output of the operation, which is entered through the user interface.

EU-Rent Rule: A car may be allocated from the capacity reserved for the next day's walk-ins
EU-Rent Rule: A car due for return the next day may be allocated, if there is a suitable car
available and there is time to transfer it to the pick-up branch.

The two rules shown above can be implemented as the following CAA rule.

Name: allocateNextDay
Condition: Car.carlD == -1
Action: 1. Car.carlD =
assignFromReservedOrNextDay(Rental .startDate)
Alternative Action: None
Type: CAA Rule

Operation assignFromReservedOrNextDay definition:
Input: Rental.startDate
Output: Car.carlD
Find a car that has been reserved for next day's walk-in or if a car due to be returned the next day
can be allocated, provided there is time to prepare it for servicing.

EU-Rent Rule: A 'bumped upgrade' may be made.
Name: bumpedUpgrade
Condition: Car.carlD == -1 && Group.grouplD != "D"
Action: 1. Car.carlD =
findHigherGroup(Group .grouplD)
Alternative Action: None
Type: CAA Rule

Operation findaigher~roup definition:
Input: Group.grouplD
Output: Car.carlD
Find an available car from the next group and return the ID.

EU-Rent Rule: A downgrade (a car of a lower group) may be made.
Name: downgrade
Condition: Car.carlD == -1 && Group.grouplD != "A"










Action: 1. Car.carlD = findLowerGroup
(Group.grouplD)
Alternative Action: None
Type: CAA Rule

Operation findLower~roup definition:
Input: Group.grouplD
Output: Car.carlD
Find an available car from the next lower group and return the ID.

EU-Rent Rule: A car from another branch may be allocated, if there is a suitable car available
and there is time to transfer it to the pick-up branch
(This is best expressed as an event and rule processing scenario)
Name: findCarInOtherBranch
Condition: Car.carlD == -1
Action: 1. PostEvent("RemoteRentalRequest");
2. Car.carlD = getCarlD("RemoteRentalRequest");
Alternative Action: None
Type: CAA Rule

Operation getCarlD definition:
Gets the car ID returned as a re sult of p osti ng "'Rem oteRentalReque st"

EU-Rent Rule: A car scheduled for service may be used, provided that the rental would not take
the mileage more than 10% over the normal mileage for the service.

The rule show above is implemented as assignScheduledCar for a later similar EU-Rent
rule

EU-Rent Rule: Pick-up may have to be delayed until a car is returned and prepared
Name: delayPickUp
Condition: Car.carlD == -1
Action: 1. Car.carlD, Rental.startDate= findFirstAvailable()
Alternative Action: None
Type: CAA Rule

Operation findFirstAvailable definition:
Input:
Output: Car.carlD, Rental.startDate
Find the first available car and return it. Return the date it will be available

EU-Rent Rule: A car may have to be rented from a competitor
Name: rentFromCompetitor
Condition: Car.carlD == -1
Action: 1. Car.carlD =
findFromCompetitor(Rental .startDate, Rental. endDate)










Alternative Action: None
Type: CAA Rule

Operation findFromCompetitor definition:
The system will notify the rental agent with the following message: "Please find an available car
from a competitor. When you have done so, please log on to the system and indicate that
operation findFromCompetitor has been performed." The agent needs to provide the rental car
ID as the output of the operation, which is entered through the user interface.
EU-Rent Rule: The end date of the rental must be before any scheduled booking of the assigned
car for maintenance or transfer.
Name: checkCarNotScheduled
Rental.endDate < Car.serviceDate
Type: Integrity Constraint

EU-Rent Rule: If there are several available cars of the model or group requested, the one with
the lowest mileage should be allocated.
Name: findAvailableCars
Condition: Rental.numCars > 0
Action: 1. Car.carlD =
allocateWithLowestMileage(Car.model, Car.group)
Alternative Action: None
Type: CAA Rule

Operation allocateWithLowestMileage definition:
Input: Car.model, Car.group
Output: Car.carlD
Find the number of available cars for the specified model or group and return its ID.

EU-Rent Rule: The credit card used to guarantee a rental must belong to one of the authorized
drivers; and this driver must sign the rental contract. Other drivers must sign an 'additional
drivers authorization' form.
Name: authorizedDrivers
if(Rental.mode == 'Credit Card')
then (Rental.driverName == Rental. creditCardName AND Rental.driverSigned = 'true'
AND Rental.addDriversSigned == 'true')
Type: Integrity Constraint


EU-Rent Rule: Before releasing the car, a credit reservation equivalent to the estimated rental
cost must be made against the guaranteeing credit card.
EU-Rent Rule: A customer may request a rental extension by phone the extension should be
granted unless the car is scheduled for maintenance.

The above two rules can be implemented as the following CAA rule.

Name: beforeRelease









Condition: None
Action: 1 makeC ardReservati on(Rental. rentalCharge)
2. notifyExtensionProcedure(Rental .startDate,
Rental. endDate)
Alternative Action: None
Type: CAA Rule

Operation makeCardReservation definition:
Input: Rental.rentalCharge
Output:
The system will notify the rental agent with the following message: "Please charge the drivers
credit card with the amount of the rental charge."

Operation notifyExtensionProcedure definition:
Input: Rental.startDate, Rental.endDate
Output: Rental. extendedEndDate
The system will notify the rental agent with the following message: "Please approve the
customer' s request to grant an extension by phone unless the car is scheduled for maintenance."

EU-Rent Rule: The car must not be handed over to a driver who appears to be under the
influence of alcohol or drugs.
EU-Rent Rule: The driver must be physically able to drive the car safely must not be too tall,
too short or too fat; if disabled, must be able to operate the controls.

The above two rules can be implemented as the following CAA rule.

Name: checkDriver
Condition: None
Action: 1. Rental.driverOK = checkDriverOK()
Alternative Action: None
Type: CAA Rule

Operation checkDriverOK definition:
Input:
Output: Rental.driverOK
The system will notify the rental agent with the following message: "Please check that the driver
does not appear to be under the influence of alcohol or drugs, and is physically able to drive the
car safely must not be too tall, too short or too fat; if disabled, must be able to operate the
controls. When you have done so, please log on to the system and indicate that operation
checkDriverOK has been performed." The agent needs to provide if the driver seems OK as the
output of the operation, which is entered through the user interface.

EU-Rent Rule: The car must have been prepared cleaned, full tank of fuel, oil and water
topped up, tires properly inflated.
EU-Rent Rule: The car must have been checked for roadworthiness tire tread depth, brake
pedal and hand brake lever travel, lights, exhaust leaks, windscreen wipers.










EU-Rent Rule: Cars needing repairs (other than minor body scratches and dents) must not be
used for rentals.

The above three rules can be implemented as the following CAA rule.

Name: checkCar
Condition: None
Action: 1. Rental.carOK = checkCarOK()
Alternative Action: None
Type: CAA Rule

Operation checkCarOK definition:
Input:
Output: Rental.carOK
The system will notify the rental agent with the following message: "Please check that the car
has been cleaned, has a full tank of fuel, oil and water topped up, tires properly inflated. Please
check the car for roadworthiness tire tread depth, brake pedal and hand brake lever travel,
lights, exhaust leaks, windscreen wipers. Please make sure that the car does not need repairs.
When you have done so, please log on to the system and indicate that operation checkCarOK has
been performed." The agent needs to provide if the car seems OK as the output of the operation,
which is entered through the user interface.

EU-Rent Rule: If an assigned car has not been picked up 90 minutes after the scheduled pick-up
time, it may be released for walk-in rental, unless the rental has been guaranteed by credit card.
Name: noShowNoGuarantee
Condition: ninetyMinuteDelay == true AND Rental.guarantee =
false
Action: 1. releaseCar (Car.carlD)
Alternative Action: None
Type: CAA Rule

Operation releaseCar definition:
Input: Car.carlD
Output:
Set assigned, rented to false and set reserved to true

EU-Rent Rule: If a rental has been guaranteed by credit card and the car has not been picked up
by the end of the scheduled pick-up day, one day' s rental is charged to the credit card and the car
is released for use the following day.
Name: noShowWithGuarantee
Condition: Rental.endDate < endOfDay AND Rental.guarantee =
true
Action: 1. releaseCar (Car.carlD)
Alternative Action: None
Type: CAA Rule











EU-Rent Rule: If a car is returned to a location other than the agreed drop-off branch, a drop-off
penalty is charged.
Name: chargeDropOffPenalty
Condition: Rental .dropOffBranch != Branch.branchlD
Action: 1. Rental. rentalCharge = addDropOffPenalty(Rental .
rentalCharge)
Alternative Action: None
Type: CAA Rule

Operation addDropOffPenalty definition:
Input: Rental. rentalCharge
Output: Rental.rentalCharge
Add the drop off penalty to the rental charge and return the new charged amount.

EU-Rent Rule: At the end of a rental, the customer may pay by cash, or by a credit card other
than the one used to guarantee the rental.
EU-Rent Rule: Local tax must be collected (at the drop-off location) on the rental charge.
EU-Rent Rule: The car must be checked for wear (brakes, lights, tires, exhaust, wipers etc.) and
damage, and repairs scheduled if necessary.
EU-Rent Rule: If the car has been damaged during the rental and the customer is liable, the
customer' s credit card company must be notified of a pending charge.

The above rules can be implemented as the following CAA rule.

Name: checkCarOnReturn
Condition: None
Action: 1. acceptableModeOfPayment()
2. Rental.rentalCharge = collectLocalTax(Rental .dropOffBranch,
Rental. rental Charge)
3. Rental.rentalCharge = checkForWear(Rental .rentalCharge)
Alternative Action: None
Type: CAA Rule

Operation acceptableModeOfPayment definition:
Input:
Output:
The system will notify the rental agent with the following message: "Please be informed that at
the end of a rental, the customer may pay by cash, or by a credit card other than the one used to
guarantee the rental.

Operation collectLocalTax definition:
Input : Rental .dropOffBranch, Rental.rentalCharge
Output : Rental.rentalCharge
float localTax = access the database to get the local tax at the drop-off branch
Rental.rentalCharge = localTax Rental .rentalCharge/100 + Rental .rentalCharge;











Operation checkForWear definition:
Input: Rental.rentalCharge
Output: Rental.rentalCharge
The system will notify the rental agent with the following message: "Please check the car for
wear (brakes, lights, tires, exhaust, wipers etc.) and damage, and schedule repairs if necessary. If
the car has been damaged during the rental and the customer is liable, return the new amount
charged and notify the customer' s credit card company of a pending charge. When you have
done so, please log on to the system and indicate that operation checkCarOK has been
performed." The agent needs to provide the new amount charged as the output of the operation,
which is entered through the user interface.

EU-Rent Rule: If a car is returned early, the rental charge is calculated at the rate appropriate to
the actual period of rental (e.g., daily rate rather than weekly).
Name: adjustOnEarlyReturn
Condition: Rental.endDate > currentDate
Action: 1. Rental.rentalCharge = adjustCharge(Rental .rentalCharge,
Rental.startDate, Rental.endDate)
Alternative Action: None
Type: CAA Rule

Operation adjustCharge definition:
Input: Rental.rentalCharge, Rental.startDate, Rental.endDate
Output: Rental.rentalCharge
The system will notify the rental agent with the following message: "Please calculate the rental
charge at the rate appropriate to the actual period of rental. When you have done so, please log
on to the system and indicate that operation adjustCharge has been performed." The agent needs
to provide the new amount charged as the output of the operation, which is entered through the
user interface.

EU-Rent Rule: If the car is returned late, an hourly charge is made up to 6 hours' delay; after 6
hours a whole day is charged.
Name: calculateLateCharge
Condition: Rental.endDate < currentDate
Action: 1. Rental.rentalCharge = lateCharge(Rental .rentalCharge,
Rental.startDate, Rental.endDate)
Alternative Action: None
Type: CAA Rule

Operation lateCharge definition:
Input: Rental.rentalCharge, Rental.startDate, Rental.endDate
Output: Rental.rentalCharge
Determine the delay, if less than 6 hours, add hourly rate and return the new amount, else charge
for the whole day.










EU-Rent Rule: If a car is not returned from rental by the end of the scheduled drop-off day and
the customer has not arranged an extension, the customer should be contacted.
Name: lateNoExtension
Condition: Rental.endDate < endOfDay AND Rental.extension ==
False
Action: 1. contactCustomer(Rental .custlD)
Alternative Action: None
Type: CAA Rule
Operation contactCustomer definition:
Input:
Output:
The system will notify the rental agent with the following message: "Please contact the customer
as the rental date has passed and the customer has not asked for an extension."

EU-Rent Rule: If a car is three days overdue and the customer has not arranged an extension,
insurance cover lapses and the police must be informed.
Name: threeDaysOverdue
Condition: Rental.endDate < endOfI~hreeDays AND Rental.extension
== false
Action: 1. contactPolice()
Alternative Action: None
Type: CAA Rule

Operation contactPolice definition:
Input:
Output:
The system will notify the rental agent with the following message: "Please contact the police as
the rental is three days overdue and the customer has not asked for an extension."

EU-Rent Rule: Each car must be serviced every three months or 10,000 kilometers, whichever
occurs first.
Name: checkServiceNeeded
if(Car. serviceMileage >= 10000 OR Car.threeMonthsServiceDate <= currentDate) then
(Car.needsService == true)
Type: Integrity Constraint

EU-Rent Rule: If there is a shortage of cars for rental, routine maintenance may be delayed by
up to 10% of the time or distance interval (whichever was the basis for scheduling maintenance)
to meet rental demand.
Name: assignScheduledCar
Condition: Car.carlD == -1
Action: 1. Car.carlD =
as signF rom Scheduled(Rental .mileage,
Car.serviceMileage, Car.serviceDate,
Car.scheduledDate, Rental.endDate)
Alternative Action: None










Type: CAA Rule


Operation assignFromScheduled definition:
Input: Rental.mileage, Car.serviceMileage, Car.serviceDate, Rental.endDate
Output: Car.carlD
Find if a scheduled car can be assigned, provided the rental mileage would not take it more than
10% of approved service mileage, or the delay is no more than 10% of the interval between the
service date and the scheduled date.

EU-Rent Rule: Only cars on the authorized list can be purchased.
Name: checkAuthorizedCar
Car.model in {list of aut~horizedT models}
Type: Integrity Constraint

EU-Rent Rule: Cars are to be sold when they reach one year old or 40,000 kilometers,
whichever occurs first.
Name: isToBeSold
if(Car.year < currentYear + 1 OR Car.mileage >= 40000)
then (Car.toBeSold = true)
Type: Derivation Rule

EU-Rent Rule: A branch cannot refuse to accept a drop-off of a EU-Rent car, even if a one-way
rental has not been authorized.
EU-Rent Rule: When a car is dropped off at a branch other than the pick-up branch, the car' s
ownership (and, hence, responsibility for it) switches to the drop-off branch when the car is
dropped off.

The above two rules can be implemented as the following CAA rule.

Name: noAuthorizedOneWay
Condition: Rental. dropOffBranch != Branch.branchlD AND Rental.oneWay
== false
Action: 1 advi seNoRefusal(Rental .rentallD)
2. assignOwner(Branch.branchlD, Car.carlD)
Alternative Action: None
Type: CAA Rule

Operation adviseNoRefusal definition:
Input:
Output:
The system will notify the rental agent with the following message: "Please do not refuse to
accept a drop-off of a EU-Rent car, even if a one-way rental has not been authorized."

Operation assignOwner definition:
Input: Branch.branchlD, Car.carlD
Output:










Change the car's owner to this branch.


EU-Rent Rule: When a transfer of a car is arranged between branches, the car' s ownership
switches to the 'receiving' branch when the car is picked up.
Name: switchOwner
Condition: None
Action: 1. Car.owningBranch = assignOwner(Branch.branchlD)
Alternative Action: None
Type: CAA Rule

EU-Rent Rule: In each car group, if a branch accumulates cars to take it more than 10% over its
quota, it must reduce the number back to within 10% of quota by transferring cars to other
branches or selling some cars.
Name: adjustQuotaDown
Condition: 1. Group.numRemainingCars > Group.quota + 0. 1 *
Group. quota
Action: 1. sell OrTransfer(Group. grouplD)
Alternative Action: None
Type: CAA Rule

Operation sellOrTransfer definition:
Input: Group.grouplD
Output:
The system will notify the branch manager with the following message: "Please reduce the
number of cars back to within 10% of quota by selling or transferring."

EU-Rent Rule: In each car group, if a branch loses cars to take it more than 10% below its
quota, it must increase the number back to within 10% of quota by transferring cars from other
branches or buying some cars.
Name: adjustQuotaUp
Condition: 1. Group.numRemainingCars < Group.quota 0. 1 *
Group. quota
Action: 1. buyOrTransfer(Group .grouplD)
Alternative Action: None
Type: CAA Rule

Operation buyOrTransfer definition:
Input: Group.grouplD
Output:
The system will notify the branch manager with the following message: "Please increase the
number of cars back to within 10% of quota by buying or transferring."

EU-Rent Rule: To j oin the loyalty incentive scheme, a customer must have made 4 rentals
within a year.
Name: eligibleForLoyaltyScheme
if(Customer.numYearlyRental s >= 4)










then (Customer.eligible = true)
Type: Derivation Rule

EU-Rent Rule: Each paid rental in the scheme (including the 4 qualifying rentals) earns points
that may be used to buy 'free rentals.'
Name: earnPoints
Condition: Customer.points > 0 AND Rental.free == false
Action: 1. Customer.points = addPoints(Rental .rentallD,
Cusomter.custlD)
Alternative Action: None
Type: CAA Rule

Operation addPoints definition:
Calculate the number of points the customer will earn and add that to his total. Return the new
points.

EU-Rent Rule: Only the basic rental cost of a free rental can be bought with points. Extras, such
as insurance, fuel and taxes must be paid by cash or credit card
Name: freeRental
Condition: Cusomter.points >0 AND Rental.free == true
Action: 1. Customer.points, Rental.rentalCharge =
getFreeRental (Rental. rentallD, Rental. rental Charge,
Customer.custlD)
Alternative Action: None
Type: CAA Rule

Operation getFreeRental definition:
Input: Rental.rentallD, Rental .rentalCharge, Customer.custlD
Output: Customer.points, Rental.rentalCharge
Subtract the basic cost of rental from the rental charge, and subtract the customer' s points, return
the adjusted charge and the new points.

EU-Rent Rule: A free rental must be booked at least fourteen days before the pick-up date.
Name: checkAdvBooking
if(Rental.free == true)
then (getBookingGap(Rental .bookDate, Rental. startDate) >= 14)
Type: Integrity Constraint

Operation getBookingGap definition:
Input: Rental.bookDate, Rental.startDate
Output: bookingGap
Returns the number of days between the book and the start dates

EU-Rent Rule: Free rentals do not earn points
Name: freeRentalPoints
if(Rental.free == true)










then (Rental.points = 0)
Type: Derivation Rule

EU-Rent Rule: Unused points expire three years after the end of the year in which they were
earned.
Name: unusedPoints
Condition: getDifference(Customer.pointsYear, currentYear) >= 3
Action: 1. Cusomter.points = expireUnusedPoints(
Customer.custlD, Customer.pointsYear)
Alternative Action: None
Type: CAA Rule

Operation getl~ifference definition:
Input: Customer,pointsYear, currentYear
Output: difference
Returns the number of years between the year the customer first earned the points and the current
year

Operation expireUnusedPoints definition:
Input: Customer.custlD, Customer.pointsYear
Output: Cusomter.points
Expire unused points of the customer and return the adjusted points

ETKnet Rule: Get the branch information
Name: getBranch
Condition None
Action: 1. Branch.* = getBranchInfo(Branch.branchlD)
Alternative Action: None
Type: CAA Rule

Operation getBranchInfo definition:
Input: Branch.branchlD
Output:Branch.*
Return the information about this branch


Events and Triggers

On the occurrence of an event, the associated trigger will be processed

Event: Reservation Request (Customer.*, Car.*, Branch.branchlD)

Trigger: driver Check getBranch

(RS 1)capac1ity Check










noGroupAndModel Specified


assignCarOnModel0rGroup


giveUpgrade



allocateNextDay bumpedUpgrade downgrade assignScheduledCar

Event: No Suitable Car Found (Car.*)

Trigger:
(RS2) delayPickUp



rentFromCompetitor

Event: Suitable Car Found (Car.*, Customer.*)

Trigger: checkOwningBranch
(RS3)

checkNotAssigned


checkNotRented


checkNotScheduled


noMultipleCars


reserveForWalkIn

Event: Walk In Request(Customer.*, Car.*)

Trigger:
(RS4) driverCheck











noGroupAndModel Specified


assignCarOnModel0rGroup


findAvailableCars


checkC arNot Schedul ed

Event: Handover(Customer.*", Car.*)

Trigger: driverCheck
(RS5)

m echani calC onditi onAndEmi ssi onC heck


authorizedDrivers


beforeRelease


checkDriver checkCar


earnPoints

Event: Rental Return (Rental.*)

Trigger:
(RS6) noAuthorizedOneWay


switchOwner


chargeDropOffPenalty


adjustOn~a return calculateLateCharge









lateNoExtension


threeDaysOverdue

Event: No Show (Rental.*, Customer.*)

Trigger: Rules 'noShowNoGuarantee' and 'noShowWithGuarantee' will be processed

Event: Car Transfer(Car.*, Branch.*)

Trigger: switchOwner
(RS7)

adjustQuotaDown adjustQuotaUp


Event: Free Rental Request (Customer.*, Rental.*)

Trigger: eligibleForLoyaltyScheme
(RS8)

freeRental


freeRentalPoints checkAdvBooking

Event: Car Sale And Purchase(Car.*)

Trigger: isToBeSold
(RS9)

checkAuthorizedCar

Event: Three Month Service Check (Car.*)

Trigger: Rule 'checkServiceNeeded' will be processed

Event: Expire Points (Customer.*)

Trigger: Rule 'unusedPoints' will be processed










Table B-1. Average time to create and execute rules and rule structures in the EU-Rent domain
Rule or rule structure name Avg time to define(sec.) Avg time to execute(sec.)
DriverCheck 8 0.229
Mechani cal Conditi onAndEmi ssi onCheck 7.7 0.099
NoGroupAndModel Specified 7.8 0.033
CapacityCheck 7.6 0.096
NoMultipl eCars 7.7 0.102
CheckOwningBranch 7.6 0.096
CheckNotAssigned 7.7 0.075
CheckNotRented 7.6 0.077
CheckNotScheduled 7.4 0.075
AssignCarOnModel0rGroup 8.3 1.089
ReserveForWalkIn 8.1 1.058
GiveUpgrade 8.1 8.2
AllocateNextDay 7.7 1.023
BumpedUpgrade 7.9 3.5
Downgrade 7.8 3.5
DelayPickUp 9.5 0.181
RentFromCompetitor 8.0 2.7
CheckCarNotS scheduled 7.5 0.054
FindAvailableCars 7.6 1.004
AuthorizedDrivers 7.7 0.100
BeforeRelease 7.5 4.1
CheckDriver 7.8 2.7
CheckCar 7.6 2.6
NoShowNoGuarantee 7.8 1.072
NoShowWithGuarantee 7.7 1.028
ChargeDropOffPenalty 7.7 1.871
CheckCarOnReturn 7.9 4.6
AdjustOnEarlyReturn 7.9 1.883
CalculateLateCharge 8.0 1.816
LateNoExtension 7.9 4.5
ThreeDaysOverdue 8.0 4.6
CheckServiceNeeded 7.8 0.096
AssignScheduledCar 7.9 2.939
CheckAuthorizedCar 7.6 0.054
IsToBeSold 8.4 0.102
NoAuthorizedOneWay 8.3 1.932
SwitchOwner 8.1 1.986
AdjustQuotaDown 8.4 0.465
AdjustQuotaUp 8.1 0.500
EligibleForLoyaltyS cheme 8 0.055
EarnPoints 8 1.491
FreeRental 8.2 1.512
CheckAdvBooking 8 1.7
FreeRentalPoints 7.8 0.054










UnusedPoints 8 0.5
GetBranch 7.9 0.499
RS1 9.1 2.047
RS2 8.3 2.285
RS3 8.6 8.6
RS4 8.5 7.1
RS5 8.8 23
RS6 8.7 30
RS7 8 4.7
RS8 8.1 4.9
RS9 7.6 2.3









APPENDIX C
EVENTS AND RULES IN THE NPDN DOMAIN

Note: Operations in the SOP can be either automated or manual. Automated operations are
performed by the system automatically. Manual operations are implemented by notifying the
proper persons or organizations to perform the operations. All notifications specified in this
document are sent via emails, text messages on the receivers' cell phones, and displayed on the
screen when users log in.

The steps of the SOP that the events and rules are derived from are also mentioned.

Step la
Organization: Grower, Pest Advisor, or other Sample Submitting Entity (SSE)
Any of the organizations that can be the sample submitting entity can post the event in case
a suspect sample is observed. By posting, we mean the occurrence of the following event.

Event SSEE1: Suspect Sample Observed (npdn.Sample Sample.*)
Rule SSER1: Condition : None
Action: 1. time of arrival, method of delivery =
Send_Sample_To Diagnostician(npdn. Sample Sample.*)
2. Contact Diagnostician(npdn.Sample Sample.*, time of arrival,
method of delivery)
Alternative Action: None

The data item Salmple (i.e. the entity npdn.Sample) contains the following attributes, which may
or may not have any data. As the diagnosis proceeds, the attributes get assigned appropriate
values.
* samplelD of type integer (blank)
* sampleDate of type date (filled in by Grower, Pest Advisor or other SSE)
* cropCode of type integer (blank)
* cropGenus of type string (blank)
* cropSpecies of type string (blank)
* pestCode of type string (blank)
* pestGenus of type string (blank)
* pestSpecies of type string (blank)
* classification of type string ("Suspect")
* stateOfOrigin of type string (filled in by Grower, Pest Advisor or other SSE)
* notes of type string (blank)

SendSampleTo Diannostician() definition: The system will notify the Grower, Pest Advisor
or other Sample Submitting Entity (SSE) with the following message: "Please send the sample
to an NPDN triage lab. When you have done so, please log on to the system and indicate that
operation Send SampleTo Diagnostician has been performed." The SSE needs to provide the
time of delivery (of type date) and the method_of delivery (of type string) as the output of the
operation, which are entered through the user interface.









ContactDiagnostician definition: The system will notify the Grower, Pest Advisor or other
Sample Submitting Entity with the following message: "Please contact the Diagnostician at the
State Department of Agriculture to notify that a suspect sample is enroute with time of arrival
and method of delivery. When you have done so, please log on to the system and indicate that
operation Contact Diagnostician has been performed."

Trigger: SSEE1 -SSER1 (i.e., Event SSEE1 will trigger the processing of Rule SSER1)

Step lb
Organization: State Department of Agriculture, APHIS-PPQ, or University Staff (i~e.
"Diagnostician" mentioned above)
Any of the organizations that can be the diagnostician can post the event in case a suspect
sample is received. By posting, we mean the occurrence of the following event.

Event SDAE1: Suspect Sample Received (npdn.Sample Sample.*)
The data item Salmple contains the following attributes, which may or may not have any data. As
the diagnosis proceeds, the attributes get assigned appropriate values.
* samplelD of type integer (blank)
* sampleDate of type date (filled in by Grower, Pest Advisor or other SSE)
* cropCode of type integer (blank)
* cropGenus of type string (blank)
* cropSpecies of type string (blank)
* pestCode of type string (blank)
* pestGenus of type string (blank)
* pestSpecies of type string (blank)
* classification of type string ("Suspect")
* stateOfOrigin of type string (filled in by Grower, Pest Advisor or other SSE)
* notes of type string (blank)

Rule SDAR1: Condition: None
Action: 1. Send_Sample_ToNPDN(npdn. Sample Sample.*)
Alternative Action: None

Send Sample To NPDN() definition: The system will notify the State Department of
Agriculture, APHIS-PPQ, or University Staff with the following message: "Please send the
sample to the National Plant Diagnostic Network Triage Lab. When you have done so, please log
on to the system and indicate that operation Send Samp~zle To NPDN() has been performed."

Trinner: SDAEl SDAR1 (i.e., Event SDAEl will trigger the processing of Rule SDAR1)

Steps 2a-2d
Organization: NPDN Triage Lab
Event NTLE1: Suspect Sample Received (npdn.Sample Sample.*)
Rule NTLR1: Condition: None
Action: 1. AckReceipt(npdn.Sample Sample.*)
2. Sample.samplelD = AssignID (npdn.Sample Sample.*)









3. Sample.* = Examine_Sample (npdn. Sample Sample.*)
4. Sample.classification =
ClassifyAs Presumptive Positive()
5. Store_Sample(npdn.Sample Sample.*)
6. RequestConfirming Diagnosis(npdn. Sample Sample.*)
7. distance_diagnosis_capability = GetCapability()
Alternative Action: None

AckReceipt definition: The system will notify the NPDN Triage Lab staff with the following
message: "Please acknowledge receipt of the sample to the State Department of Agriculture or
University Staff. When you have done so, please log on to the system and indicate that operation
AckReceipt has been performed."

Assign ID definition: An automated operation that generates a unique id for the given sample.
After this operation is performed, the sample has the samplelD attribute filled in:
* samplelD of type integer (filled in by Assign_ID)
* sampleDate of type date (filled in by Grower, Pest Advisor or other SSE)
* cropCode of type integer (blank)
* cropGenus of type string (blank)
* cropSpecies of type string (blank)
* pestCode of type string (blank)
* pestGenus of type string (blank)
* pestSpecies of type string (blank)
* classification of type string ("Suspect")
* stateOfOrigin of type string (filled in by Grower, Pest Advisor or other SSE)
* notes of type string (blank)

Examine Sample definition: The system will notify the NPDN Triage Lab staff with the
following message: "Please examine the sample. When you have done so, please log on to the
system and indicate that operation ExamnineSmple has been performed." The staff needs to
provide the updated sample information Sample.* (of type npdn. Sample) as the output of the
operation, which is entered through the user interface.

Classify As Presumptive Positive definition: An automated operation that fills in the value
"Presumptive Positive" for the sample classification since the sample has been examined.

After this operation the sample may have the remaining attributes filled in:
* samplelD of type integer (filled in by Assign_ID)
* sampleDate of type date (filled in by Grower, Pest Advisor or other SSE)
* cropCode of type integer (possibly filled in by Examine_Sample)
* cropGenus of type string (possibly filled in by Examine_Sample)
* cropSpecies of type string (possibly filled in by Examine_Sample)
* pestCode of type string (possibly filled in by Examine_Sample)
* pestGenus of type string (possibly filled in by Examine_Sample)
* pestSpecies of type string (possibly filled in by Examine_Sample)









* classification of type string ("Presumptive Positive")
* stateOfOrigin of type string (filled in by Grower, Pest Advisor or other SSE)
* notes of type string (possibly filled in by Examine_Sample)

StoreSample definition: The system will notify the NPDN Triage Lab staff with the following
message: "Please store the sample securely. When you have done so, please log on to the system
and indicate that operation StoreSmple has been performed."

RequestConfirmingDiagnosis definition: The system will notify the NPDN Triage Lab staff
with the following message: "Please contact the state of origin SPRO, state of origin SPHD,
APHIS-PPQ CDD, and NPDN Hub Lab informing them that a presumptive positive sample is in
the system. When you have done so, please log on to the system and indicate that operation
RequestConfirmingDiagnosis has been performed."

GetCapability definition: An automated operation that finds out whether or not this lab has the
di stance diagnosis s capability, indicated by the output di stance_diagnosi s_capability.

Step 2e
Rule NTLR2: Condition: distance diagnosis s_capability = true
Action: ConductWebBased Diagnosi s(npdn. Sample Sample.*)
Alternative Action: sample~image = EmailPicture()

ConductWeb_ BasedDiannosis definition: The system will notify the NPDN Triage Lab staff
with the following message: "Please contact the APHIS-PPQ CDD, and NPDN Hub Lab to set
up a web-based distance diagnosis session. When you have done so, please log on to the system
and indicate that operation ConductWebBa;sedDiagnosis has been performed."

Email Picture definition: The system will notify the NPDN Triage Lab staff with the following
message: "Please take a picture of the sample and email it to the APHIS-PPQ CDD, and the
NPDN Hub Lab. When you have done so, please log on to the system and indicate that operation
EmailPicture has been performed." The staff needs to provide the picture of the sample,
samplerimage (of type File) as output, which is entered through the user interface.

Steps 2f-2h
Rule NTLR3: Condition: None
Action: 1. Shipment.*, time of delivery, method of delivery =
Divide And Ship_Sample(npdn. Sample Sample.*)
2. ContactAbout Shipment (npdn.Shipment Shipment.*, String
Sample. stateOfOrigin, time_of delivery, method of delivery,
int Sample.samplelD)
Alternative Action: None

Divide And ShipSample definition: The system will notify the NPDN Triage Lab staff with
the following message: "The sample should go to an NPDN hub lab OR to the CDD. Please
consult the CDD on which it should be. If routine sample or if hub lab has provisional approval
to ID from CDD then it should go to the hub lab, otherwise if hub lab is not provisionally









approved for the suspect species or if it is very high consequence first occurrence, then it should
go to CDD directly. Accordingly, divide the sample into portions and send a portion to the
APHIS-PPQ CDD Lab or to the NPDN Regional Hub Lab. Please ensure that the sample is
double bagged in zippable bags and sealed in a box with tape, sample submission form is
included, diagnostician's business card is included, and sample box is marked as 'Plant samples
for diagnosis'. When you have done so, please log on to the system and indicate that operation
Divide And Ship_Sample has been performed." The staff needs to provide shipment
information, Shipment.* (of type npdn.Shipment), time of delivery (of type string), and
method of delivery (of type string) as output, which are entered through the user interface.

The data item \1hipinentll (i.e. the entity npdn.Shipment) contains the following attributes.
sender of type string (filled in by NPDN Triage Lab)
receiver of type string (filled in by NPDN Triage Lab)
trackingNumber of type string (filled in by NPDN Triage Lab)
doubleBagged of type Boolean (filled in by NPDN Triage Lab)
submissionFormlncluded of type Boolean (filled in by NPDN Triage Lab)
businessCardlncluded of type Boolean (filled in by NPDN Triage Lab)
shippingLabel of type string (filled in by NPDN Triage Lab)

ContactAbout Shipment definition: The system will notify the NPDN Triage Lab staff with the
following message: "Please contact the state of origin SPRO, APHIS-PPQ SPHD, APHIS-PPQ
CDD, and NPDN Hub Lab or Expert Lab informing them of the presumptive positive sample
shipment time and delivery method, including tracking number. When you have done so, please
log on to the system and indicate that operation ContactAbout_.1hqunentr'l has been performed."

Step 2i
Rule NTLR4: Condition: None
Action: 1. ContactCampus_Safety_Officer(npdn.Sample Sample.*)
Alternative Action: None

Contact Campus Safety Officer definition: The system will notify the NPDN Triage Lab staff
with the following message: "Please contact the Campus Safety Officer informing them of a
presumptive positive sample in the system. When you have done so, please log on to the system
and indicate that operation Contact Campus Safety/_Offcer has been performed."

Trinner: The following rule structure is identified as "NTLRS1"

NTLE1 NTLR1


NTLR2


NTLR3 NTLR4










(i.e. Event NTLE1 will trigger the processing of rule NTLR1, followed by rule NTLR2. Once
rule NTLR2 completes execution, rules NTLR3 and NTLR4 are executed in parallel)

Steps 3a-3b
Organization: State of Origin SPRO
Event SPROE1: Presumptive Positive Sample Recorded (npdn.Sample Sample.*)
Rule SPROR1: Condition: None
Action: 1. ResponsePlan.* = ContactSPHD(npdn.Sample Sample.*)
Alternative Action: None

ContactSPHD definition: The system will notify the State of Origin SPRO with the following
message: "Please contact the State of Origin SPHD to discuss response plans in the event that the
presumptive positive sample is confirmed positive by the APHIS-PPQ CDD. You can
communicate with other regulatory officials in neighboring states to plan and/or activating the
strategy. When you have done so, please log on to the system and indicate that operation
ContactSPHD has been performed." The SPRO needs to provide information about the
response plan, ResponsePlan.* (of type npdn.ResponsePlan) as output, which is entered through
the user interface.

The data item ResponsePlan (i.e. the entity npdn.ResponsePlan) contains the following
attributes:
* officialsToBeNotified of type string
* pestGenus of type string
* pestSpecies of type string
* pressRelea~se of type string

Trigger: SPROE1 -SPROR1

(i.e. Event SPROE1 will trigger the processing of rule SPROR1)

Steps 4a-4b
Organization: NPDN Regional Hub Lab
Event NHLE1: Presumptive Positive Sample Received (npdn.Sample Sample.*)
Rule NHLR1: Condition: (Shipment.doubleBagged == true) &&
(Shipment.submissionFormlncluded == true) &&
(Shipment. businessCardlncluded == true) &&
(Shipment.shippingLabel == "Plant samples for diagnosis")
Action: 1. AckReceipt (npdn.Sample Sample.*)
2. Sample.* = Examine_Sample(npdn.Sample Sample.*)
3. contact~local_expert = Is_OK_ToContactLocalExpet()
Alternative Acti on: 1 C contact NPDNlTri ageLab (Bool ean
Shipment.doubleB( !e~wed, i boolean
Shipment.submissionFormlncluded, boolean
Shipment. businessCardlncluded, String
Shipment.shippingLabel, npdn.Sample Sample.*)










AckReceipt definition: The system will notify the NPDN Hub Lab staff with the following
message: "Please acknowledge receipt of the sample to the NPDN Triage Lab. When you have
done so, please log on to the system and indicate that operation AckReceipt has been
performed."

ExamineSample definition: The system will notify the NPDN Regional Hub Lab staff with the
following message: "Please examine the sample. When you have done so, please log on to the
system and indicate that operation ExamnineSmple has been performed." The staff needs to
provide updated information about the sample, Sample.* (of type npdn. Sample) as output, which
is entered through the user interface.

After this operation is performed, the sample may have some changes to the values of some of its
attributes:
* samplelD of type integer (filled in by Assign_ID)
* sampleDate of type date (filled in by Grower, Pest Advisor or other SSE)
* cropCode of type integer (possibly changed by Examine_Sample)
* cropGenus of type string (possibly changed by Examine_Sample)
* cropSpecies of type string (possibly changed by Examine_Sample)
* pestCode of type string (possibly changed by Examine_Sample)
* pestGenus of type string (possibly changed by Examine_Sample)
* pestSpecies of type string (possibly changed by Examine_Sample)
* classification of type string ("Presumptive Positive")
* stateOfOrigin of type string (filled in by Grower, Pest Advisor or other SSE)
* notes of type string (possibly changed by Examine_Sample)

Is OK To Contact Local Expert definition: The system will notify the NPDN Regional Hub
Lab staff with the following message: "Please contact the Director to determine if it is OK to
bring in a local expert. When you have done so, please log on to the system and indicate that
operationIs OKTo_ContactLocalExpert has been performed." The staff needs to provide
contact~local_expert (of type boolean) as output, which is entered through the user interface.

Contact NPDN Triage Lab definition: The system will notify the NPDN Regional Hub Lab
with the following message: "Please contact the NPDN Triage Lab indicating that proper sample
shipping procedures were not followed. When you have done so, please log on to the system and
indicate that operation ContactNPDNTriage Lab has been performed."

Step 4c
Rule NHLR2: Condition: (contact~local_expert == true)
Action: 1. results~received = ContactLocalExpert(npdn.Sample Sample.*)
Alternative Action: None

Contact Local Expert definition: The system will notify the NPDN Hub Lab with the following
message: "Please contact the Local Expert for confirming diagnosis. When you have done so,
please log on to the system and indicate that operation ContactLocalExpert has been
performed." The staff needs to provide results~received (of type boolean) as output (this will
indicate that the local expert provided the results), which is entered through the user interface.










Steps 4g-4i
Rule NHLR3: Condition: None
Acti on: 1. Contact NPDNDirectorAnd_APHIS (npdn. Sample Sample.*)
2. ContactSPROSPHD( String Sample.classificati on)
3. Contact CS_Offi cer(String S ampl e.cl as sifi cati on)
4. to_send~toAPHIS = ContactAPHIS(npdn.Sample Sample.*)
Alternative Action: None

ContactNPDNDirectorAndAPHIS definition: The system will notify the NPDN Hub Lab
with the following message: "Please contact the NPDN Regional Director and APHIS-PPQ-
Confirming Diagnosis Designate with preliminary conclusions/results. When you have done so,
please log on to the system and indicate that operation ContactNPDNDirector AndAPHIS has
been performed."

ContactSPRO_ SPHD definition: The system will notify the NPDN Hub Lab with the following
message: "Please contact your own SPRO and SPHD to inform them that a presumptive positive
sample is housed in NPDN Regional Hub until shipment to APHIS-PPQ Confirming Designate
or until it is destroyed following diagnosis. Do not disclose the state of origin to SPRO or
SPHD. When you have done so, please log on to the system and indicate that operation
ContactSPROSPHD has been performed."

Contact CS_ Officer definition: The system will notify the NPDN Hub Lab staff with the
following message: "Please contact the Campus Safety Officer informing them of a presumptive
positive sample in the system. Do not disclose state of origin. When you have done so, please log
on to the system and indicate that operation ContactCS Officer has been performed."

Contact APHIS definition: The system will notify the NPDN Hub Lab with the following
message: "Please contact the APHIS-PPQ Confirming Diagnosis Designate and ask if they
request sending sample for confirmation, When you have done so, please log on to the system
and indicate that operation ContactAPHIS has been performed." The staff needs to provide
to_send toPHIS (of type boolean) as output, which is entered through the user interface.

Steps 4j-4k
Rule NHLR4: Condition: to send to APHIS == true
Action: 1. Shipment.*, time of delivery, method of delivery =
Send_Sample_ToPHIS(npdn. Sample
Sample.*)
2. ContactAPHISWith_ShipmentDetails(npdn. Shipment
Shipment.*")
Alternative Action: None

SendSampleToAPHIS definition: The system will notify the NPDN Hub Lab with the
following message: "Please send the sample to the APHIS-PPQ CDD. When you have done so,
please log on to the system and indicate that operation Send Samp~zle ToAPHIS() has been
performed." The staff needs to provide information about the shipment, Shipment.* (of type










npdn. Shipment), time of delivery (of type date), and method_of delivery (of type string) as
output, which are entered through the user interface.

Contact_ APHISWith_ ShipmentDetails definition: The system will notify the NPDN Hub Lab
with the following message: "Please contact the APHIS-PPQ CDD to notify that a presumptive
positive sample is enroute with time of arrival and method of delivery. When you have done so,
please log on to the system and indicate that operation ContactAPHISWith_.\r1 hqunall)etails
has been performed."

Trigger: The following rule structure is identified as "NHLRS1"

NHLE 1 NHLR 1


NHLR2 NHLR3


NHLR4

(i.e. Event NHLE1 will trigger the processing of rule NHLR1. Once rule NHLR1 completes
processing, rules NHLR2 and NHLR3 will be executed in parallel. Once both these rules finish
processing, rule NHLR4 will be executed)

Steps 4d-4f
Organization: Local Expert
Event LEE1: Presumptive Positive Sample Received (npdn.Sample Sample.*)
Rule LER1: Condition: None
Action: 1. Sample.* = Examine_Sample(npdn.Sample Sample.*)
2. Contact NPDNTWithResults(npdn. Sample Sample.*)
Alternative Action: None

ExamineSample definition: The system will notify the Local Expert with the following
message: "Please make the preliminary diagnosis in collaboration with NPDN Regional Hub
staff. When you have done so, please log on to the system and indicate that operation
ExamnineSmple has been performed." The expert needs to provide information about the
sample, Sample.* (of type npdn. Sample) as output, which is entered through the user interface.

ContactNPDN_ WithResults definition: The system will notify the Local Expert with the
following message: "Please contact the NPDN Regional Hub Diagnostician with
conclusions/results. When you have done so, please log on to the system and indicate that
operation ContactNPDNWithResults has been performed."

Trigger: LEE1 -LER1
(i.e. Event LEE1 will trigger the processing of rule LER1)










Step 5
Organization: NPDN Regional Director from state of origin
Event NRDE1: Presumptive Positive Sample Under Diagnosis (npdn.Sample Sample.*)
Rule NRDR1: Condition: None
Action: 1. Contact NPDNTProgramLeader(npdn.Sample Sample.*)
Alternative Action: None

ContactNPDNProgramLeader definition: The system will notify the NPDN Regional

Director with the following message: "Please contact the NPDN Program Leader indicating that
the presumptive positive sample is under diagnosis. Do not disclose state of origin except to
Program Leader. When you have done so, please log on to the system and indicate that operation
ContactNPDN Progra~m Leader has been performed."

Trinner: NRDE1 NRDR1
(i.e. Event NRDE1 will trigger the processing of rule NRDR1)


Step 6a
Organization: APHIS-PPQ CDD
Event ACDDE1: Presumptive Positive Sample Received (npdn.Sample Sample.*)
Rule ACDDR1: Condition: None
Action: 1. AckReceipt(npdn. Sample Sample.*)
2. expected_date, more than_seven~days =
Date Of ResultNotifieati on(npdn. Sample Sample.*)
3. ok~to_contact NPDN = Is_OK_To_C contact NPDN()
Alternative Action: None

AckReceipt definition: The system will notify the APHIS-PPQ CDD staff with the followings
message: "Please acknowledge receipt of the sample to the NPDN Triage Lab. When you have
done so, please log on to the system and indicate that operation AckReceipt has been
performed."

Date Of Result Notification definition: The system will notify the APHIS-PPQ CDD staff with
the following message: "Please indicate to the NPDN Triage Lab the expected date of result
notification When you have done so, please log on to the system and indicate that operation
DateOfResultNotification has been performed." The staff provides the expected_date (of type
date) of confirmation information as well as whether confirmation it will be more than seven
days after submission, more than_seven~days (of type boolean) as output, which are entered
through the user interface.

Is OK To Contact NPDN definition: The system will notify the APHIS-PPQ CDD staff with
the following message: "Please ask the APHIS-PPQ Program Manager to consult with the
NPDN Program Leader and determine if it is OK to inform other NPDN Regional Directors and
their diagnosticians. When you have done so, please log on to the system and indicate that
operationIs OKToContactNPDN has been performed." The staff needs to provide
ok~to_contactNPDN (of type boolean) as output, which is entered through the user interface.










Steps 6b-6c
Rule ACDDR2: Condition: (more than_seven_days == true) &&
(ok~to_contact NPDN == true)
Acti on: 1 C ontactOtherDirectors()
2. C contact Di agnosti ci ans()
Alternative Action: None

ContactOtherDirectors definition: The system will notify the NPDN Regional Director of
affected region with the following message: "Please contact other NPDN Regional Directors to
inform them that a presumptive positive sample is in the system. Kindly do not disclose origin
of sample. When you have done so, please log on to the system and indicate that operation
ContactOtherDirectors has been performed."

ContactDiagnosticians definition: The system will notify all NPDN Regional Directors with the
following message: "Please contact diagnosticians in your region at NPDN labs in each state to
inform them that a presumptive positive sample is under diagnosis in an unknown location in the
nation and to be alert for similar samples that may be appearing in other labs. When you have
done so, please log on to the system and indicate that operation Contact_ Diagnosticians has
been performed."

Steps 6d-6g, Step 7a
Rule ACDDR3: Condition: None
Action: 1. Result.* = ConductConfirming Diagnosis(npdn.Sample
Sample.*)
2. ContactAdmini strator(npdn.Result Result.*)
3. Contact RegionalPHIS_Staff(npdn.Result Result.*)
4. ContactSPHD(npdn.Result Result.*)
5. ContactTriageLab (npdn.Result Result.*)
Alternative Action: None

The data item Result (i.e. the entity npdn.Result) contains the following attributes.
* samplelD of type integer
* sampleDate of type date
* cropCode of type integer
* cropGenus of type string
* cropSpecies of type string
* pestCode of type string
* pestGenus of type string
* pestSpecies of type string
* classification of type string
* confirmedDiagnosisDate of type date
* expectedDate Time of type date
* notes of type string

ConductConfirming,_Diagnosis definition: The system will notify the APHIS-PPQ CDD Staff
with the following message: "Please conduct the confirming diagnosis. When you have done so,









please log on to the system and indicate that operation ConductConfirming Diagnosis has been
performed." The staff needs to provide the diagnosis results, Result.* (of type npdn.Result) as
output, which is entered through the user interface.

ContactAdministrator definition: The system will notify the APHIS-PPQ CDD Staff with the
following message: "Please contact the APHIS-PPQ Administrator to inform him of the final
results. When you have done so, please log on to the system and indicate that operation
ContactAdministrator has been performed."

ContactRegionalAPHIS_ Staff definition: The system will notify the APHIS-PPQ
Administrator with the following message: "Please contact the Regional APHIS Staff to inform
them of the Einal results. When you have done so, please log on to the system and indicate that
operation Contact RegionalAPHIS Staffhas been performed."

ContactSPHD definition: The system will notify the APHIS-PPQ Administrator with the
following message: "Please contact the State Plant Health Director of the state of origin to
inform him of the final results. When you have done so, please log on to the system and indicate
that operation ContactSPHD has been performed."

ContactTrianeLab definition: The system will notify the APHIS-CDD Staff with the following
message: "Please contact the Triage Lab to inform them of the final results after enough time has
passed that state of origin SPHD and SPRO and Triage Lab Diagnostician should have been
informed of the confirmed diagnosis results by regional APHIS-PPQ office. When you have
done so, please log on to the system and indicate that operation ContactTriageLab has been
performed."

Trigger: The following rule structure is identified as "ACDDRS"

ACDDE 1 -ACDDR1


ACDDR2


ACDDR3

(i.e. Event ACDDE1 will trigger the sequential processing of rules ACDDR1, ACDDR2, and
ACDDR3 )

Step 6h
Organization: SPHD from State of Origin
Event SPHDE1: Results Received(npdn.Result Result.*)
Rule SPHDR1: Condition: None
Action: 1. ContactSPRO(npdn.Result Result.*)
Alternative Action: None









ContactSPRO definition: The system will notify the SPHD with the following message: "Please
contact the State Plant Regulatory Official of the state of origin to inform him of the Einal results.
When you have done so, please log on to the system and indicate that operation Contact SPRO
has been performed."

Trinner: SPHDE1- SPHDR1

(i.e. Event SPHDE1 will trigger the processing of rule SPHDR1)

Step 6i, Step 9b
Organization: SPRO from State of Origin
Event SPROE2: Results Received from SPRO(npdn.Result Result.*)
Rule SPROR2: Condition: None
Action: 1. ContactTriageLab(npdn.Result Result.*)
2. SubmitRecord(npdn.Result Result.*)
Alternative Action: None

ContactTrianeLab definition: The system will notify the SPRO with the following message:
"Please contact the Triage Lab to inform them of the Einal results. When you have done so,
please log on to the system and indicate that operation ContactTriageLab has been performed."

SubmitRecord() definition: The system will notify the SPRO with the following message:
"Please submit the record to the NAPIS CAPS database. When you have done so, please log on
to the system and indicate that operation Submit Record has been performed."

Trinner: SPROE2 SPROR2
(i.e. Event SPROE2 will trigger the processing of rule SPROR2)

Steps 7b-7c, Steps 7g-7h
Organization: NPDN Triage Lab
Event NTLE2: Results Received from APHIS(npdn.Result Result.*)
Rule: NTLR5: Condition: None
Action: 1. ContactRelevantOrganizations(npdn.Result Result.*)
2. Contact NPDNHub(npdn.Result Result.*)
3. ContactSSE(npdn.Result Result.*, npdn.ResponsePlan
ResponsePlan.*)
4. ContactCampus_Offieer(npdn.Result Result.*)
Alternative Action: None

Contact_ RelevantOrganizations definition: The system will notify the NPDN Triage Lab Staff
with the following message: "Please contact the state of origin SPHD, SPRO, and the Regional
NPDN Director to acknowledge receipt of results. When you have done so, please log on to the
system and indicate that operation ContactRelevant Organizations has been performed."

ContactNPDNHub definition: The system will notify the NPDN Triage Lab Staff with the
following message: "Please contact the NPDN Regional Hub Lab to notify them of the results.









When you have done so, please log on to the system and indicate that operation
ContactNPDNHub has been performed."

ContactSSE definition: The system will notify the NPDN Triage Lab Staff with the following
message: "Please coordinate with SPRO and SPHD to contact Sample Submitting Entity with
results as approved and designated by the state of origin SPRO and SPHD. When you have done
so, please log on to the system and indicate that operation ContactSSE has been performed."

ContactCampusOfficer definition: The system will notify the NPDN Triage Lab Staff with the
following message: "Please contact the Campus Safety Officer with result and assurance of
sample destruction. When you have done so, please log on to the system and indicate that
operation Contact CampusOfficer has been performed."

Step 7i
Rule: NTLR6: Condition: Result.classifieation == "Positive"
Action: 1. Destroy_Sample()
2. select~agent = Is_SelectAgent()
Alternative Action: None

Destrov_ Sample(1 definition: The system will notify the NPDN Triage Lab Staff with the
following message: "Please destroy the confirmed positive sample by placing all packing
material and the sample in an autoclave for at least 20 minutes. When you have done so, please
log on to the system and indicate that operation DestroySample has been performed."

IsSelectAnent definition: The system will notify the NPDN Triage Lab Staff with the
following message: "Please check if the confirmed positive sample was a select agent. When you
have done so, please log on to the system and indicate that operationIs Select Agent has been
performed." The staff needs to provide select~agent (of type boolean) as output, which is entered
through the user interface.

Rule: NTLR7: Condition: select~agent == true
Action: 1. SubmitForm4()
Alternative Action: None

Submit Form4(1 definition: The system will notify the NPDN Triage Lab Staff with the
following message: "Please complete and submit Form 4. When you have done so, please log on
to the system and indicate that operation SubmitForm4 has been performed."

Step 9a
Rule: NTLR8: Condition: None
Action: 1. SubmitRecord(npdn.Result Result.*)
Alternative Action: None

SubmitRecord definition: The system will notify the NPDN Triage Lab Staff with the following
message: "Please submit the record to the NPDN database. When you have done so, please log
on to the system and indicate that operation Submit Record has been performed."











Trigger: The following rule structure is identified as "NTLRS2"

NTLE2 NTLR5


NTLR6


NTLR7


NTLR8

(i.e. Event NTLE2 will trigger the sequential processing of rules NTLR5, NTLR6, NTLR7, and
NTLR8)

Step 7d, Steps 8a-8b
Organization: NPDN Regional Hub Lab
Event NHLE2: Results Received from NPDN Triage Lab (npdn.Result Result.*)
Rule: NHLR5: Condition: None
Action: 1. Contact ProgramLeader(npdn.Result Result.*)
2. ContactSPROAnd_SPHD (npdn.Result Result.*)
3. ContactCampus_Officer (npdn.Result Result.*)
4. select~agent = Is_SelectAgent()
Alternative Action: None

ContactProoramLeader definition: The system will notify the NPDN Hub Lab Staff with the
following message: "Please contact the NPDN Program Leader to notify him/her of the results.
When you have done so, please log on to the system and indicate that operation
ContactProgram Leeade has been performed."

Contact SPRO And SPHD definition: The system will notify the NPDN Hub Lab Staff with the
following message: "Please contact the SPRO and SPHD with result and assurance of sample
destruction. Do not disclose state of origin. When you have done so, please log on to the system
and indicate that operation ContactSPROAnd SPHD has been performed."

ContactCampusOfficer definition: The system will notify the NPDN Hub Lab Staff with the
following message: "Please contact the Campus Officer with result and assurance of sample
destruction. Do not disclose state of origin. When you have done so, please log on to the system
and indicate that operation Contact Campus Officer has been performed."

Is Select Agent definition: The system will notify the NPDN Hub Lab Staff with the following
message: "Please check if the confirmed positive sample was a select agent. When you have
done so, please log on to the system and indicate that operationIs Select Agent has been










performed." The staff needs to provide select~agent (of type boolean) as output, which is entered
through the user interface.

Rule: NHLR6: Condition: select~agent == true
Action: 1. SubmitForm4()
Alternative Action: None

SubmitForm4() definition: The system will notify the NPDN Hub Lab Staff with the following
message: "Please complete and submit Form 4. When you have done so, please log on to the
system and indicate that operation SubmitForm4 has been performed."

Trigger: The following rule structure is identified as "NHLRS2"

NHLE2 NHLR5


NHLR6
(i.e. Event NHLE2 will trigger the sequential processing of rules NHLR5 and NHLR6)
Step 7e
Organization: NPDN Regional Director from state of origin
Event NRDE2: Results Received from NPDN Triage Lab (npdn.Result Result.*)
Rule: NRDR2: Condition: None
Action: 1. ContactOtherDirs(npdn.Result Result.*)
Alternative Action: None

ContactOtherDirs definition: The system will notify the NPDN Regional Director with the
following message: "Please contact other NPDN Regional Directors, if engaged at the discretion
of APHIS-PPQ in consultation with NPDN Program Leader, with the results. Do not disclose
state of origin. When you have done so, please log on to the system and indicate that operation
ContactOtherDirs has been performed."

Trigger: NRDE2 -NRDR2
(i.e. Event NRDE2 will trigger the processing of rule NRDR2)

Step 7f
Organization: Other NPDN Regional Directors
Event ONRDE1: Results Received from NPDN Regional Director in state of origin
(npdn.Result Result.*)
Rule: ONRDR1: Condition: None
Acti on: 1 Contact RegionalLab s (npdn.Result Result.*)
Alternative Action: None

Contact Regional Labs definition: The system will notify the NPDN Regional Director with the
following message: "Please contact NPDN Regional Labs, if engaged at the discretion of
APHIS-PPQ in consultation with NPDN Program Leader, with the results. Do not disclose state










of origin. When you have done so, please log on to the system and indicate that operation
Contact Regional Labs has been performed."

Trigger: ONRDE1 -ONRDR1
(i.e. Event ONRDE1 will trigger the processing of rule ONRDR1)


Table C-1. Average time to create and execute rules and rule structures in the NPDN domain
Rule or rule structure name Average time to define (sec.) Average time to execute (sec.)
SSER1 8.7 44
SDAR1 9.3 22
NTLR1 8.3 29
NTLR2 8.4 25
NTLR3 8.5 46
NTLR4 8.3 5
NTLRS 1 8.4 46
SPROR1 8.2 5
NHLR 1 8.7 6.7
NHLR2 8.2 2.7
NHLR3 8.7 30
NHLR4 8.6 54
NHLRS 1 8.4 63
LER1 8.6 48
NRDR1 8.5 26
ACDDR1 8.3 16
ACDDR2 8.2 45
ACDDR3 8.4 89
ACDDRS 8.5 54
SPHDR1 8.2 22
SPROR2 8.4 2
NTLR5 8.8 11
NTLR6 8.2 4
NTLR7 8.1 20
NTLR8 8.4 0.3
NHLR5 8.7 16
NHLR6 8.3 4
NHLRS2 8.5 20
NTLRS2 8.5 31
NRDR2 8.5 22
ONRDR1 8.5 28









LIST OF REFERENCES


1. Agrawal, R., Evfimievski, A., Srikant, R.: Information Sharing across Private Databases. In:
Proceedings of the ACM SIGMOD Conference, pp. 86-97, 2003

2. Aiken, A., Widom, J., Hellerstein, J.: Behavior of Database Production Rules : Termination,
Confluence and Observable Determinism. In: Proceedings of the ACM SIGMOD
Conference, pp. 59-68, 1992

3. Aiken, A., Widom, J., Hellerstein, J. Static analysis techniques for predicting the behavior of
active database rules. ACM TODS 20(1), 3-41 (1995)

4. Bailey, J., Dong, G., Ramamohanarao, K.: Decidability and Undecidability Results for the
Termination Problem of Active Database Rules. In: Proceedings of PODS, pp. 264-273, 1998

5. Baralis, H., Widom, J.: An Algebraic Approach to Rule Analysis in Expert Database
Systems. In: Proceedings of the 20th VLDB Conference, pp. 475-486, 1994

6. Baralis, E., Ceri, S., Paraboschi, S.: Modularization Techniques for Active Rules Design.
ACM Transactions on Database Systems 21(1), 1-29 (1996)

7. Baralis, E., Ceri, S., Paraboschi, S.: Compile-Time and Runtime Analysis of Active
Behaviors. IEEE Transactions on Knowledge and Data Engg. 10(3), 3 53-3 70 (1998)

8. Bassiliades, N., Vlahavas, I., Elmagarmid, A.: E-DEVICE: An Extensible Active Knowledge
Base System with Multiple Rule Type Support. IEEE Transactions on Knowledge and Data
Engg. 2(5), 824-844 (2000)

9. Bieber, M., et al.: Towards Knowledge-Sharing and Learning in Virtual Professional
Communities. In: Proceedings of the 35th Annual Hawaii International Conference on System
Sciences, pp. 2843-2852, 2002

10. Boley, H., Kifer. M.: RIF Core Design. W3C Working Draft, 2007. Accessed March 2007,
http://www.w3. org/TR/rif-core/

11. Booth, D., et al. (eds.).: Web Services Architecture. W3C Working Group, 2004. Accessed
May 2005, http://www.w3. org/TR/2004/NOTE-ws-arch-200402 11

12. Brownston, L., Farrell, R., Kant, E.: Programming Expert Systems in OPS5. Addison-
Wesley, Massachusetts (1985)

13. Buchmann, A., et al.: DREAM: Distributed Reliable Event-Based Application Management.
In: Levene, M., Poulovassilis, A. (eds.), Web Dynamics, Springer-Verlag, pp. 319-352, 2004

14. Cabrera, L., Jones, M., Theimer, M.: Herald: Achieving a Global Event Notification Service.
In: Proceedings of the Eighth Workshop on Hot Topics in Operating Systems, pp. 87-92,
2001









15. Caldwell, N. et al.: Web-Based Knowledge Management for Distributed Design. IEEE
Intelligent Systems 15(3), 40-47 (2000)

16. Carzaniga, A., Rosenblum, D., Wolf, A.: Achieving Scalability and Expressiveness in an
Intemet-Scale Event Notification Service. In: Proceedings of the 19th ACM Symposium on
Principles of Distributed Computing, pp. 219-227, 2000

17. Ceri, S., Widom, J.: Deriving Production Rules for Constraint Maintenance. In: Proceedings
of the 16th VLDB Conference, 566-577, 1990

18. Chen, H., et al.: COPLINK: Managing Law Enforcement Data and Knowledge. Commun.
ACM 46(1), 28-34, (2003)

19. Couchot, A.: Termination analysis of active rules modular sets. In: Proceedings of the
International Conference on Information and Knowledge Management, pp. 326-333, 2001

20. Cover, R. (ed.).: Business Rules Markup Language. Cover Pages, 1998. Accessed May 2005,
http:.//xml. coverpages. org/brml. html

21. Cover, R. (ed.).: Simple Rule Markup Language. Cover Pages, 2001. Accessed May 2005,
http:.//xml. coverpages. org/srml. html

22. Dhamankar, R. et al.: iMAP: Discovering Complex Semantic Matches between Database
Schemas. In: Proceedings of the ACM SIGMOD Conference, pp. 383-394, 2004

23. Filho, R., De Souza, C., Redmiles, D.: The Design of a Configurable, programmable and
Dynamic Notification Service. In: Proceedings of the 2nd International Workshop on
Distributed Event-Based Systems, pp. 1-8, 2003

24. Friedman-Hill, E.: Java Expert System Shell. Sandia National Laboratories, 2007. Accessed
May 2005, http://www.j essrules.com/j ess/index. shtml

25. Gandon, F., Sheshagiri, M., Sadeh, N.: Rule Language in OWL. Camegie Mellon University,
2004. Accessed May 2005,
http://mycampus. sadehlab .cs. cmu. edu/publi c_pages/ROWL/ROWL html

26. Ginsberg, A., et al. (eds.).: RIF Use Cases and Requirements. W3C Working Draft, 2006.
Accessed Jan 2007, http://www.w3 .org/2005/rules/

27. He, B., Chang, K.: A holistic paradigm for large scale schema matching. In: Proceedings of
the ACM SIGMOD Conference, pp. 20-25, 2004

28. Heimrich, T., Specht, G.: Enhancing ECA Rules for Distributed Active Database Systems.
In: Proceedings of Web, Web-Services, and Database Systems, pp. 199-205, 2002

29. Hill, M., et al.: Required Fields for the NPDN National Database, NPDN Handout, July 2006









30. Hirtle, D., et al.: Schema Specifieation of RuleML 0.91. The Rule Markup Initiative, 2006.
Accessed Jan 2007, http://www.ruleml.org

31. Horrocks, I., et al. SWRL: A Semantic Web Rule Language Combining OWL and RuleML.
Defense Advanced Research Projects Agency, 2003. Accessed May 2005,
http://www. daml. org/2003/11/swrl/

32. Hovy, E., Philpot, A. Falke, S.: Automating the Integration of Heterogeneous Databases. In:
Proceedings of the National Conference on Digital Govemnment Research, pp. 24-26, 2004

33. ILOG Inc.: ILOG JRules. ILOG, 2007. Accessed May 2005,
http://www.ilog. com/products/jrules/

34. Iowa State University, Iowa Soybean Association and Iowa Soybean Promotion Board, Iowa
Department of Agriculture and Land Stewardship, & United States Department of
Agriculture Animal and Plant Health Inspection Service Plant Protection and Quarantine,
Iowa Response and Action Plan for Asian Soybean Rust, Draft 1.5, 2004

3 5. Kantere, V. et al.: Coordinating Peer Databases Using ECA Rules. In: Proceedings of the
International Workshop on Databases, Information Systems and Peer-to-Peer Computing, pp.
108-122, 2003

36. Kantere, V., Mylopoulos, J., Kiringa, I.: A Distributed Rule Mechanism for Multidatabase
Systems. In: Proceedings of the Intemnational Conference on Cooperative Information
Systems, pp. 56-73, 2003

37. Karadimce, A., Urban, S.: Refined Triggering Graphs: a Logic-Based Approach to
Termination Analysis in an Active Obj ect-Oriented Database. In: Proceedings of the Intl.
Conf. on Data Engineering, pp. 384-391, 1996

38. Kolber, A., et al.: Defining Business Rules What Are They Really? Business Rules Group,
2000. Accessed May 2005, http ://www.businessrulesgroup Org/first_paper/BRG-
whati sBR 3ed.pdf

39. Krishnamurthy, B., Rosenblum, D.S.: Yeast: A general purpose Event-Action System. IEEE
Transactions on Software Engineering 21(10), 845-857 (1995)

40. Lee, J., Sohn, M.: Enhanced Knowledge Management with eXtensible Rule Markup
Language. In: Proceedings of the 36th Hawaii International Conference on System Sciences
Hawaii, 8 pp., 2003

41. Lee, M., Su, S Y. W., Lam, H.: A Web-based Knowledge Network for Supporting Emerging
Intemet Applications. WWW Journal 4(1/2), 121-140 (2001)

42. Lee, S., Ling, T.: Unrolling Cycle to Decide Trigger Termination. In: Proceedings of the 25th
VLDB Conference, pp. 483-493, 1999









43. Linehan, M., and Ferguson, D.: Business Rules Standards Interoperability and Portability.
In: Proceedings of the W3C Workshop on Rule Interoperability, 7 pp., 2005

44. Loucopoulos, P., Katsouli, E.: Modelling business rules in an office environment. ACM
SIGOIS Bulletin 13(2), 28-37 (1992)

45. McGuinness, D., Van Harmelan, F. (eds.) .: OWL Web Ontology Language, W3C
Recommendation, 2004. Accessed May 2005, http://www.w3 .org/TR/owl-features/

46. Matena, V., et al.: Applying Enterprise JavaBeans, 2nd Ed. Addison-Wesley, Massachusetts
(2003)

47. Merali, Y., Davies, J.: Knowledge Capture and Utilization in Virtual Communities. In:
Proceedings of the First Intemnational Conference on Knowledge Capture, pp. 92-99, 2001

48. MySQL AB.: MySQL Server 5.0. MySQL AB, 2005. Accessed Jun 2005,
http://dev. mysql. com/downl oads/mysql/5. 0. html

49. National Plant Diagnostic Network (NPDN), 2002, http://www.npdn.org

50. National Plant Diagnostic Network.: The National Plant Diagnostic Network Standard
Operating Procedure for APHIS-PPQ Pest of Concern Scenario General SOP, June 2005

51. Nonaka, I., Takeuchi, H.: The Knowledge Creating Company. Oxford University Press, New
York (1995)

52. Pantel, P., Philipot, A., Hovy, E.: Aligning Database Columns using Mutual Information. In:
Proceedings of the National conference on Digital Govemnment Research, pp. 205-210, 2005

53. Preece, A. et al.: KRAFT: An Agent Architecture for Knowledge Fusion. International
Journal on Intelligent Cooperative Information Systems 10(1/2) 171-195 (2001)

54. Production Systems Technologies.: OPS/J. Production Systems Technologies, 2003.
Accessed May 2005, http://www.pst. com/opsj.htm

55. Riley, G.: C Language Integrated Production System. CLIPS Expert System Group, 2007.
Acces sed May 200 5, http://www.ghg. net/clip s/CLIP S.html

56. Rosenberg, F., Dustdar, S.: Business Rules Integration in BPEL A Service-Oriented
Approach. In: Proceedings of the 7th Intemnational IEEE Conference on E-Commerce
Technology, pp. 476-479, 2005

57. Rosenberg, F., Dustdar, S.: Towards a Distributed Service-Oriented Business Rules System.
In: Proceedings of the 3rd European Conference on Web Services, IEEE, pp. 14-24, 2005

58. Rouvellou, I., et al.: Combining Different Business Rules Technologies: A Rationalization.
In: Proceedings of the OOPSLA 2000 Workshop on Best-practices in Business Rule Design
and Implementation, 2000









59. Rowstron, A,. et al.: SCRIBE: The Design of a Large-scale Event Notification Infrastructure.
In: Proceedings of The 3rd International Workshop on Networked Group Communication, pp.
30-43, 2001

60. Schlimmer, J. (ed.).: Web Services Description Requirements. W3C Working Draft, 2002.
Accessed May 2005, http://www.w3.org/TR/ws-desc-reqs

61. Southern Plant Diagnostic Network (SPDN), 2002, http://spdn.ifas.ufl.edu

62. Sowa, J.: Knowledge Representation: Logical, Philosophical and Computational
Foundations. Brooks Cole, California (2000)

63. Stack, J. et al.: The National Plant Diagnostic Network. Plant Disease 90(2), 128-136 (2006)

64. Su, S.Y.W., et al.: An Internet-based Negotiation Server for E-Commerce. VLDB Journal
10(1), 72-90 (2001)

65. Su, S.Y.W., et al.: Transnational Information Sharing, Event Notification, Rule Enforcement
and Process Coordination. Intl. J. of Electronic Government Research 1(2), 1-26 (2005)

66. Sun Microsystems.: The Sun Java System Application Server. Sun Microsystems, 2005.
Accessed May 2005, http://developers. sun. com/prodtech/appserver/index. html

67. Tidwell, D.: UDDI4J: Matchmaking for Web services. IBM Inc., 2001. Accessed May 2005,
http://www- 12 8.ibm. com/devel operworks/web servi ces/library/ws-uddi4j .html

68. Todd, J. (ed.).: Sudden Oak Death. United States Department of Agriculture- Cooperative
State Research Education and Extension Service, 2004. Accessed May 2005,
http://www. aphis.usda. gov/plant~health/plant_pest~info/pram/downlod/d ie/ainl
estalert_.pdf

69. Tucker, J.: Historical Trends Related to Bioterrorism: An Empirical Analysis. Emerging
Infectious Diseases, Centers for Disease Control and Prevention, 5(4), 498 504 (1999)

70. Ullman, J.: Principles of Database Systems, 2nd Ed. Computer Science Press, Maryland,
(1982)

71. Ullman, J.: Principles of Database and Knowledge-Base Systems, Vols I and II. Computer
Science Press, Maryland (1988)

72. U.S. Congress.: Office of Technology Assessment, Harmful Non-Indigenous Species in the
United States, OTA-F-565 Washington, DC, U.S. Government Printing Office, 3-5, 1993

73. Viens, S., et al.: The Apache jUDDI Project. Apache Software Foundation, 2003. Accessed
Jun 2005, http://ws.apache. org/juddi/

74. Wagner, G.: The Agent-Obj ect-Relationship Metamodel: Towards a Unified View of State
and Behavior. Inf. Syst. 28(5), 475-504 (2003)









75. Warmer, J., Kleppe, A.: The obj ect constraint language: precise modeling with UML.
Addison-Wesley Longman, Massachusetts (1998)

76. Wenger, E.: Communities of practice: The social fabric of a learning organization.
Cambridge University Press, New York (1998)

77. White, S., Sleeman, D.: A Grammar-Driven Knowledge Acquisition Tool that Incorporates
Constraint Propagation. In: Proceedings of the International Conference On Knowledge
Capture, pp. 187-193, 2001

78. Widom, J., Ceri, S.: Active Database Systems, Triggers and Rules for Advanced Database
Processing. Morgan Kaufmann, California (1996)

79. Yu, C., and Popa, L.: Semantic Adaptation of Schema Mappings when Schemas Evolve. In:
Proceedings of the 3 1st VLDB Conference, pp. 1006-1017, 2005

80. Zhang, N., Zhao, W.: Distributed Privacy Preserving Information Sharing. In Proceedings of
the 31st VLDB Conference, pp. 889-900, 2005









BIOGRAPHICAL SKETCH

Seema Degwekar was born in Thane, India on November 10, 1978. She received her

Bachelor of Engineering in Computer Engineering from Vivekanand Education Society' s

Institute of Technology, affiliated with University of Mumbai, in June 2000. She j oined the

Computer and Information Science and Engineering (CISE) graduate program at the University

of Florida in August 2000. She has been a part of the Database Research and Development

Center from August 2001. She graduated in December 2002 with a Master of Science in

Computer Engineering.

At University of Florida, she has worked as a research assistant, a teaching assistant, and

has taught an undergraduate course for around two years. She is the founder of the department' s

graduate student association. She is also the recipient of the Outstanding International Student

award from the College of Engineering for her academic achievements, and the Alec Courtelis

award in recognition of academic excellence and University and community service.

Her research areas include event and rule based systems, knowledge management and

sharing, distributed computing, indexing large databases, web services, peer-to-peer systems,

XML and web databases.





PAGE 1

1 ETKnet: A DISTRIBUTED EVENTAND RULE-BASED SYSTEM FOR KNOWLEDGE SHARING IN A COLLABORATIVE FEDERATION By SEEMA DEGWEKAR A DISSERTATION PRESENTED TO THE GRADUATE SCHOOL OF THE UNIVERSITY OF FLORIDA IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF DOCTOR OF PHILOSOPHY UNIVERSITY OF FLORIDA 2007

PAGE 2

2 2007 Seema Degwekar

PAGE 3

3 To my husband and best friend, Nikhil

PAGE 4

4 ACKNOWLEDGMENTS During my years of graduate study here, I have received support from many people in many different ways. First of all, I would like to thank my advisor, Dr. Stanley Y. W. Su, who has been a perfect mentor. I feel extremely fortunate to be advised by him. Through his association, I have not only picked up valuable technical expertise, but also important personality traits such as determination, perseverance, and focus on the task-at-hand. He has shown infinite patience with me, for which I will be eternally grateful. I would also like to thank Dr. Herman Lam, Dr. Stephen Thebaut, Dr. Christopher Jermaine, and Dr. Howard Beck for being a part of my PhD committee. On the personal front, I thank my husband, Nikhil, without whose support, I would have never completed this very important step in my life. He has always been there, whenever and wherever I needed him. I am very grateful for my parents, Lata and Pradeep, and my brother, Sachin who have supported me in all possible ways. I would also like to thank my mother-in-law, Smita, and my sister-in-law, Swati for their encouragement and appreciation. Big thanks go to all my colleagues in the Database Center. Special thanks to Subi, Shantanu, and Abhijit for the many lunches, coffees, stimulating conversations, and great advice! I would also like to acknowledge Gilliean, Laukik, Padma, Xuelian, Alexandra, Jayendra, Jungmin, Sanghyun, Florin, Alejandro, Mark, Jeff, Mingxi, Oguzhan, Reasey, Brian, Manas, and Manna for making the lab a great place to work. I would like to thank Alina, Andres, Raazia, Padma, and Sameep for their enthusiasm and efforts with ASCIE. I would especially like to thank Pedro, James, and Alok for helping me kick-start the organization. I would also like to thank the CISE administration and staff for all the help they have given to me as well as to all students. Very special and heartfelt thanks go to Amy

PAGE 5

5 for her constant support, and great involvement in student affairs. We are very lucky to have such a wonderful graduate advisor. I would also like to acknowledge Debra Anderson, Maud, and all the other great folks at the International Center for helping us international students with all sorts of things. Finally, I would like to thank all of my friends and family who have always cheered me on.

PAGE 6

6 TABLE OF CONTENTS page ACKNOWLEDGMENTS ...............................................................................................................4 LIST OF TABLES ...........................................................................................................................9 LIST OF FIGURES .......................................................................................................................10 ABSTRACT ...................................................................................................................................11 CHAPTER 1 INTRODUCTION ......................................................................................................................13 2 RELATED WORK .....................................................................................................................19 Rule Markup Languages .........................................................................................................19 Simple Rule Markup Language (SRML) ........................................................................19 Business Rules Markup Language (BRML) ...................................................................19 Rule Markup Language (RuleML) ..................................................................................20 Extensible Rule Markup Language (XRML) ..................................................................20 Other Markup Languages ................................................................................................20 Eventand Rule-Based Systems .............................................................................................21 Event-based Systems .......................................................................................................21 Rule-based Systems .........................................................................................................21 Rule Interoperability ...............................................................................................................23 E-DEVICE .......................................................................................................................23 Service-Oriented Business Rules System ........................................................................24 Rule Interchange Format .................................................................................................25 3 KNOWLEDGE SPECIFICATION LANGUAGE .....................................................................27 Integrity Constraints ...............................................................................................................28 Derivation Rules .....................................................................................................................31 Action-oriented Rules .............................................................................................................32 Rule Structure .........................................................................................................................34 Examples of Rules and Rule Structures from Two Application Domains .............................35 EU-Rent Car Rental Company ........................................................................................36 Example Rules and Rule Structure from the EU-Rent Rule Set .....................................37 Example Rule 1 ........................................................................................................37 Example Rule 2 ........................................................................................................37 Example Rule 3 ........................................................................................................39 Example Rule Structure ...........................................................................................40 National Plant Diagnostic Network .................................................................................41 Example Rules and Rule Structure from NPDN Plant Diagnostic Laboratories ............43 Example Rule 1 ........................................................................................................43

PAGE 7

7 Example Rule 2 ........................................................................................................44 Example Rule 3 ........................................................................................................45 Example Rule Structure ...........................................................................................46 4 HETEROGENEOUS RULES AS WEB SERVICES.................................................................49 Creating a Web Service ..........................................................................................................49 Algorithms for Different Rule Types .....................................................................................50 Integrity Constraints ........................................................................................................50 Derivation Rules ..............................................................................................................51 CAA Rules .......................................................................................................................52 Rule Structure .........................................................................................................................53 5 SYSTEM ARCHITECTURE AND RULE PROCESSING .......................................................63 System Architecture ................................................................................................................63 Event-triggered Processing of Rules and Rule Structures in the EU-Rent Domain ...............68 Decomposition of Rule Structure ...........................................................................................70 Event-triggered Processing of Rules and Rule Structure in the NPDN Domain ....................72 Distributed Rule and Rule Structure Processing in the NPDN domain ..................................73 6 RESEARCH ISSUES .................................................................................................................78 Event Data Aggregation .........................................................................................................78 Event Data Inconsistencies and Contradictions ......................................................................80 Avoiding Cyclic Rule Execution ............................................................................................82 7 SUMMARY, CONTRIBUTIONS, AND FURTHER RESEARCH ..........................................94 APPENDIX A XML Schema documents ...........................................................................................................97 RuleBase.xsd ..........................................................................................................................97 RuleStruc.xsd ........................................................................................................................106 EventData.xsd .......................................................................................................................108 Events.xsd .............................................................................................................................109 Operations.xsd ......................................................................................................................110 B EVENTS AND RULES IN THE EU-RENT DOMAIN ..........................................................113 Description of entities used ..................................................................................................113 EU-Rent Rules ......................................................................................................................114 Events and Triggers ..............................................................................................................128 C EVENTS AND RULES IN THE NPDN DOMAIN ................................................................134 LIST OF REFERENCES .............................................................................................................151

PAGE 8

8 BIOGRAPHICAL SKETCH .......................................................................................................157

PAGE 9

9 LIST OF TABLES Table page 6-1 Build time and run time overhead of the cyclic rule avoidance strategy ...........................90 B-1 Average time to create and execute rules and rule structures in the EU-Rent domain ....132 C-1 Average time to create and execute rules and rule structures in the NPDN domain .......150

PAGE 10

10 LIST OF FIGURES Figure page 3-1 Example rule structures......................................................................................................48 4-1 Algorithm for web service synthesis..................................................................................55 4-2 Algorithm for integrity constraint rules .............................................................................56 4-3 Algorithm for derivation rules ...........................................................................................57 4-4 Algorithm for condition-action-alternative_action rules ...................................................58 4-5 Algorithm for rule structures .............................................................................................60 5-1 ETKnet system architecture ...............................................................................................75 5-2 Event and rule processing in the EU-Rent domain ............................................................76 5-3 Event and rule processing in the NPDN domain ...............................................................77 6-1 Algorithm to aggregate event data and identify conflicts ..................................................91 6-2 Algorithm to find possible cyclic paths on registration of an event ..................................92 6-3 Algorithm to compute the rule expression for a possibly cyclic rule ................................93 6-4 Algorithm to update possible cyclic paths on addition of a global rule.............................93

PAGE 11

11 Abstract of Dissertation Presented to the Graduate School of the University of Florida in Partial Fulfillment of the Requirements for the Degree of Doctor of Philosophy ETKnet : A DISTRIBUTED EVENTAND RULE-BASED SYSTEM FOR KNOWLEDGE SHARING IN A COLLABORATIVE FEDERATION By Seema Degwekar August 2007 Chair: Stanley Y. W. Su Cochair: Herman Lam Major: Computer Engineering Enabling government organizations to solve complex global problems such as illegal immigration, border control, and terrorism or business organizations to maintain a globally competitive edge, requires these organizations to collaborate and share not only data and application system resources, but also knowledge that captures organizational and inter-organizational policies, constraints, regulations, processes and procedures. In our study, we focus on the research and development of a knowledge specification language and the techniques, algorithms, system and infrastructure for the sharing of knowledge among collaborating organizations. We represent knowledge using three types of rules : condition-action-alternative -action rules, logic-based derivation rules, or integrity constraints, and structures of these rules. We introduce an XML-based language that enables the specification and sharing of multi-faceted knowledge. Collaborating organizations can specify events of importance, data associated with those events, and rules and rule structures that should be triggered upon the occurrences of those events. We develop a distributed eventand rule-based system called ETKnet for event notification, event data transmission and aggregation, and processing of distributed rules, rule

PAGE 12

12 structures, triggers, automated application system operations and manual operations. Data associated with an event occurrence and generated by triggered rules, rule structures and automated/manual operations can thus be shared and used by collaborating organizations for their decision-making and problem-solving. Our approach to achieve the interoperation of heterogeneous rules is to translate rules and rule structures into program code and wrap them as web services for their uniform representation, discovery and invocation in a web service infrastructure. This dissertation presents the system architecture, the distributed event and rule processing strategy, algorithms used for the translation of heterogeneous rules and rule structures into web services, implementation details, and issues and solutions related to event data aggregation, conflicting rules, and cyclic rules.

PAGE 13

13 CHAPTER 1 INTRODUCTION Recent breakthroughs in technology have served to bring the world closer together. While easy communication and accessibility solve many fundamental problems for the world community, they also give rise to new complex ones. Some of these problems have potentially serious consequences. For example, government organizations face complex problems such as drug trafficking, terrorism, illegal immigration, and disease detection and control. Other problems likely hamper global economic progress. For example, most business organizations are facing the challenges of increasing productivity and profit while reducing costs, developing synergy among different departments of an organization or among collaborating organizations, and recognizing and planning for future assets in an ever changing world. In order for business organizations to compete in the global economy and for government organizations to tackle complex problems, they must collaborate and share their data, application system operations (automated or manual), as well as knowledge specifications that express their policies, constraints, regulations, processes and procedures [18, 32, 65]. Research has shown that knowledge acquisition and learning can greatly benefit from interaction and collaboration with others that share similar interests [76]. The basic technology of sharing distributed, heterogeneous data has been extensively studied. Many recent efforts that address schema matching [22, 27], data privacy [1, 80], and schema mapping [52, 79] are important for achieving meaningful sharing of data. However, an effective means of sharing human and organizational knowledge among collaborating organizations is still lacking. Organizations that share data, knowledge and application operations form a collaborative federation. Each organization in such a federation typically has its own file system or database

PAGE 14

14 management system to manage its data. It may also have a knowledge-based system to store and process its organizational knowledge. One approach to achieve data, knowledge and operation sharing is to build a distributed system on top of the existing systems of the collaborating organizations for accessing distributed data, knowledge and operation resources. However, direct due to security reasons and the autonomous nature of these organizations. Instead, we propose that each collaborating organization publish/export only the data, knowledge specifications and application operations that it is willing to share. We provide a distributed system capable of processing these shareable resources. At any given point in time, an organization will not be interested in getting all the shareable data of other collaborating organizations. Usually, it will be interested in getting only the specific data associated with the occurrence of an event (e.g., a delay of the delivery date of a product, a police arrest of an illegal immigrant, a terrorist attack, etc.) and the data that are generated by the execution of relevant knowledge specifications that are triggered by the event occurrence. In this work, we focus on event-triggered data, knowledge and operation sharing among collaborating organizations. To achieve effective event-triggered data and knowledge sharing, we need to answer three e achieve the interoperability of heterogeneous knowledge Knowledge can be broadly classified as tacit or explicit [51]. Explicit knowledge can be expressed in language and can therefore be codified and recorded, whereas tacit knowledge cannot be expressed in language and is usually transmitted through socialization processes [47].

PAGE 15

15 conceptual models, etc. [9]. In this work, we are interested in representing the explicit knowledge knowledge can be specified by different types of rules [44, 62]. As such, this knowledge is multi-faceted. There are three common types of knowledge rules used in existing rule-based systems [38, 58]. Condition-action or event-condition-action (ECA) rules [78] are the most common type of rules used in eventbased systems [13, 16] and production rule systems [55, 12opinions expressed in forms of deductive rules are employed for decision-support [71]. In addition, constraint rules are used to enforce data integrity in most database systems [70]. The above three types of rules may be structured (hereafter referred to as rule structure) to express a rule execution order that models an organizational or inter-organizational process or operational procedure. By developing a high-level, declarative knowledge specification language for describing these three popular types of knowledge rules and rule structures, we can provide a powerful means to capture the different facets of knowledge to be shared by collaborating organizations. We now address the type of system needed to process distributed, heterogeneous rules and rule structures. As we mentioned earlier, collaborating organizations are usually interested in obtaining only those data that are pertinent to the occurrence of an event of common interest (i.e., event data) and in processing only those knowledge rules that are applicable to the event data. An event is any incident of significance to collaborating organizations (e.g. an arrest, a terrorist incidence, the detection of a disease, a special state of a database, a signal from a sensor, etc.) that occurs at a particular point in time. Each organization of a federation can define and share its events of interest, along with data generated by these events. It can also specify rules

PAGE 16

16 that should be processed upon the occurrence of an event defined by either the organization itself associated with the event occurrence (i.e., event data) are sent to organizations that have applicable knowledge rules and rule structures. A rule or rule structure is applicable to an event if the set of data items to be processed by the rule or rule structure is a subset of the event data. The processing of these rules may add to or modify the initial event data, and/or activate shareable application operations that add to or modify the event data. The results of rule processing are sent to the site that posted the event occurrence, which then merges the data collected from different organizations to produce a new version of event data and sends it out again to sites that have applicable rules. This process of event data transmission and rule processing continues until all relevant rules have been applied. The last version of the event data contains all the data that are relevant to the event occurrence. It can be used by collaborating organizations for additional problem-solving and decision-support. Thus, an eventand rule-based system that facilitates event subscription, event notification, delivery of event data, and processing and interoperation of applicable knowledge rules and rule structures would be ideal for any collaborative federation and is the focus of our research. Now we come to the question of how to process heterogeneous rules and make them interoperable. One approach is to use three types of rule engines to process the corresponding three different types of rules and find some way to make these engines interoperable. We believe this will result in a very complex and inefficient system. Another approach taken in [8] is to choose one knowledge representation (e.g., event-condition-action rule) and convert the other two types of rules into the chosen one so that they can all be processed by a single rule engine. Since the semantics of these rule types are different, one problem with this approach is that it is

PAGE 17

17 not always possible to convert one type of rule into another type without some loss of meaning. Also, most existing rule engines interpret rules at runtime resulting in an inefficient and unscalable rule system. A third more promising approach taken in [43, 57] is to provide a web service interface to heterogeneous rule engines, thereby providing a uniform access API. In [57], rule execution is carried out by individual engines interpretively. Support for rule structures is lacking and it is also not clear how one rule engine can make use of the results generated by another. In our work, we use a compilation approach by translating different types of rules and rule structures at rule definition time into code and wrapping this code as web services for their uniform registration, discovery and invocation in a web service infrastructure. The contributions of this research are to: 1. Develop a an XML-based knowledge specification language for organizations to specify their knowledge in terms of three types of rules and rule structures, 2. Develop algorithms for converting different types of rules and rule structures to web services and a strategy for processing rules and rule structures to demonstrate the interoperation of heterogeneous knowledge rules, 3. Research on techniques for managing dynamic event data and processing distributed knowledge rules, merging event data documents, handling event data inconsistencies and preventing cyclic execution of rules, and 4. Develop a distributed eventand rule-based system to achieve inter-organizational sharing of event data, knowledge and application operations. As mentioned before, the proposed technology and system has applications in e-business, homeland security and other such collaborative efforts. Specifically, we will present two applications to demonstrate the need and use of the proposed work: one in the e-business domain by using the EU-rent car rental company example published by the Business Rules Group [38], and the other in the homeland security domain by using the National Plant Diagnostic Network (NPDN) System [49].

PAGE 18

18 The rest of this dissertation is organized as follows. Chapter 2 presents earlier efforts in this area. Chapter 3 describes the syntax of the three types of rules and rule structure, and also presents our knowledge specification language, along with examples of rules and rule structures from the abovementioned applications. Chapter 4 presents algorithms for converting heterogeneous rules and rule structure to web services. Chapter 5 presents the architecture of our eventand rule-based system, the implementation framework and technologies used. Chapter 6 describes research issues pertaining to event data aggregation, event data inconsistencies, and cyclic rule execution. Finally, Chapter 7 summarizes our contributions and presents ideas for further research.

PAGE 19

19 CHAPTER 2 RELATED WORK Rule Markup Languages Several recent efforts are concerned with developing a rule markup language for business applications. The main aim of these languages is to capture rule syntax in an XML form. Some common approaches are outlined below: Simple Rule Markup Language (SRML) SRML [21], proposed by ILOG in 2001, addresses the problem of sharing rules across applications with different Java rule engines. They realize that there are several commercial Java rule engines on the market such as ILOG JRules [33], JESS [24], OPS/J [54], etc. each with their own feature sets. Each of these rule engines has their own set of Java APIs, and their own proprietary rule language. This prohibits applications from sharing rules across rule engines, and as a result, ties such applications to a specific platform. Their proposed solution is to provide an XML representation for Java rule engines. They mainly provide the syntax to describe forward-chaining condition-action rules. Constraints and deductive rules can potentially be specified by converting them to condition-action rules. However, the language does not provide explicit mechanisms to represent these other types of rules. Business Rules Markup Language (BRML) BRML [20] -Commerce Project. It aims to provide a common representation for exchanging rules between heterogeneous rule systems. It concentrates on heterogeneous expert systems only, and thus has support only for the representation of deductive rules.

PAGE 20

20 Rule Markup Language (RuleML) By far the most popular and advanced markup language available today, RuleML [30] aims to capture all three types of business rules in a standardized format. The RuleML initiative began in 2000. Since then, the language is continuously evolving. The aim is to represent both forward-chaining and backward-chaining rules for deduction and other transformations. The syntax for deductive rules has been pretty much finalized, and we adopt some syntactic constructs in our own knowledge specification language. However, the effort to extend RuleML to include constraint and event-condition-action rule specifications is still in an early developmental stage. Extensible Rule Markup Language (XRML) The eXtensible Rule Markup Language (XRML) [40] aims to represent and process rules implicitly embedded in web pages. Towards that end, it defines a Rule Identification Language which allows a user to specify rules, a Rule Structure Language which converts these rules into a formal structure usable by an expert system, and a Rule Triggering Language, which defines the conditions under which these rules will be triggered. These conditions relate to events in our terminology. The user can thus make use of special tags to augment unstructured information. This can then be processed by a software agent to derive rules embedded in the web page. The aim here is to support knowledge sharing between a human being and a software agent. Currently, XRML supports deductive rules only. Also, they focus on knowledge sharing within a single organization. Other Markup Languages Besides the ones mentioned above, there are many other efforts such as the Semantic Web Rule Language (SWRL) [31], which aims to extend the set of the Web Ontology Language (OWL) [45] axioms to include Horn-like (deductive) rules,

PAGE 21

21 the Rule Language in OWL (ROWL) [25], which allows the specification of deductive rules in OWL and provides the facility for translating these rules into Java Expert System Shell (JESS) rules, and the Agent-Object-Relationship Markup Language (AORML) [74], which represents the behavior of business entities (business processes, events, agents, claims, etc.) by means of reaction (or ECA) rules. All of the above languages and systems support only one or two of the rule types we are interested in. As far as we know, RuleML is the only effort that aims to represent all three types of rules. However, the language is yet to be finalized. Eventand Rule-Based Systems Event-based Systems Several distributed event notification/service systems such as DREAM [13], Siena [16], Herald [14], Scribe [59], Yeast [39] and the work reported in [23] provide features similar to our distributed event infrastructure. These systems focus on scalability issues of event data, event subscription, efficient event notification, event filtering, and event history processing. However, most of them do not couple event notification with rule processing. DREAM and Yeast achieve this, but only use the event-condition-action (ECA) rules. Rule-based Systems There are many rule-based systems that process rules specified in a single rule representation. For example, the Web-based knowledge management system reported in [15] uses derivation rules to assist product designers in conceptual designs of products. Each rule specifies the condition(s) under which a design attribute is satisfied. In [77], a general-purpose knowledge acquisition tool called COCKATOO uses formal grammar augmented with constraint specifications to specify structured and declarative knowledge. There are many so-called active database systems, which use ECA rules as surveyed in [78].

PAGE 22

22 With the exception of a few rule processing systems designed for processing rules in a distributed environment, most of the knowledge-based management systems are centralized: i.e., they use a single rule processing engine to process specific type of rules. Some examples of distributed rule management systems are given below. In [35], a distributed rule processing mechanism for multi-database systems is presented. The work deals with the processing of simple and composite event expressions and the decomposition of event expressions to create sub-rules for processing on multi-databases. In [28], the authors present a distributed active database system that has a central shared knowledge repository and an ECA rule base. They also present the technique for processing ECA rules in a distributed environment. ECA rules are decomposed into sub-rules and then these sub-rules are distributed to different sites for processing against distributed databases. The authors address the issue of how to evaluate rules correctly considering the order of distributed rule executions. In [3], the authors discuss the behavior of active rules in multi-database systems. An event service generates event managers to detect, produce and notify distributed events, while a rule service generates rule managers with specific rule engines for executing reactive rules. They propose five execution policies for processing multiple rules. In [36], the concept and the technique for coordinating peer databases using ECA rules are presented. Peer databases are stand-alone, independently developed databases that are linked to each other through acquaintances. They each contain local data, a set of mapping tables and expressions, and a set of ECA rules, which are used to exchange data among them. The set of acquaintances and peers constitutes a dynamic peer-to-peer network in which acquaintances are continuously established and abolished. The paper describes techniques for specifying data exchange policies on-the-fly based on constraints imposed on the way peers exchange and share data. It provides on-the-fly specification of data

PAGE 23

23 exchange policies by building coordination ECA rules at acquaintance time. In [53], a system called KRAFT deals with the access of heterogeneous data from multiple, distributed, and heterogeneous data sources. An integration schema provides a common representation across the distributed system. Distributed database queries are processed to retrieve data instances. However, to make these instances meaningful, KRAFT attaches context information with these instances. The context information is expressed in the form of constraints, which describe how each data instance should be interpreted and used. There are three main differences between our system and those mentioned above. First, in these systems, event notification is not linked with the processing of heterogeneous, distributed rules. Second, they deal with the processing of only one type of rules, whereas, our system deals with the processing of multiple types of rules and rule structures. Third, they decompose rules into sub-rules and transmit them to multiple sites for processing against distributed data, whereas we transmit event data, which is limited in quantity as compared with stored databases, to those sites that contain applicable rules. Rule Interoperability The following three systems aim to achieve heterogeneous rule interoperability in different ways. The first one designates one of the three types of rules as the standard, and converts the other two into the standard representation. The second and the third propose providing a standardized interface to three types of rule engines. E-DEVICE E-DEVICE [8] proposes an active knowledge based system to support the processing of all three types of rules. The core system is an active OODB system that has support for events and ECA rules. Derivation rules and integrity constraints are mapped into ECA rules and processed by a single rule engine. The events monitor the insertion, update, or deletion of an object, an

PAGE 24

24 object attribute, or an intra-object pattern. The condition clause is an inter-object pattern, which consists of the conjunction of one or more intra-object patterns. The action clauses are either insertion, deletion, or update of an object or object attribute. The implemented system (at the time of writing) does not support the translation of integrity constraints into ECA rules. The operations allowed in action clauses are limited to database operations instead of application system operations. Service-Oriented Business Rules System The system presented in [57] addresses the lack of flexibility and reusability of business rules across distributed rule engines. The authors propose a service-oriented business rules system that manages and deploys business rules to different business rule engines. Their distributed system consists of several nodes, which can belong to one or more of the following three types: Rules Broker Node, Deployment Node, and Coordination Node. Each Rules Broker node hosts one or more Business Rules Brokers, which can have several different rule engines plugged in. The broker is used to direct the rule processing to the appropriate engine and uses the web service interface as a communication mechanism between different types of engines. A rule is first implemented in the appropriate rule engine. The interface to this rule is generated as a web service and is deployed at one or more deployment nodes. The coordination node is responsible for coordinating the deployment of a set of rules among multiple available rules broker nodes. This node uses a two-phase commit protocol to ensure that all participating rules broker nodes have received the correct set of rules. This same system has also been used to demonstrate rule integration in BPEL [56]. Here, the authors focus on the integration of business rules with web service composition. A process workflow is augmented with preand postactivity rules that encapsulate business logic. Different from this work, rule execution in our system is governed not only by explicit triggers that link events to rules and rule structures, but

PAGE 25

25 also by implicit triggers determined by examining whether the input data to a rule or rule structure are a subset of the event data. Implicit triggers give our system the forward-chaining like behavior which is not present in the referenced system. Furthermore, rule execution in the referenced system is carried out by individual engines interpretively, whereas we use a compilation approach. Support for rule structures is lacking and it is also not clear how one rule engine can make use of the results generated by another. Rule Interchange Format W3C has established a Rule Interchange Format working group [10] to produce a framework or language to translate rules between different systems. The purpose of this group is to enable rule interoperability by allowing rules specified in one format to be processed by a different rule engine. At the time of this writing, the RIF Core has been developed. From the RIF equality (and with a standard first-order semantics). Syntactically, however, RIF Core has a number of extensions to support features such as objects and frames, URIs as identifiers for concepts, and XML Schema data types. These features make RIF a Web language. However, RIF is designed to enable interoperability among rule languages in general, and its uses are not limited to the Web. The semantics of RIF has provisions for future extensions towards dialects that support pure FOL, dialects that support negation as failure (NAF), business (or production) rules, reactive rules, and other features. Eventually, it is hoped that RIF dialects will cover a number of important paradigms in rule-based specification and programming. Our main target paradigms include production rules, logic programming, FOL-based rules, reactive rules, and normative rules (integrity constraints). It is worthwhile to point out some key differences between our system and those mentioned above. E-DEVICE is an event-based system, but it does not use a compilation

PAGE 26

26 approach for rule processing. Instead, it converts different types of rules into ECA. Also, its application domain is a single organization with an OODB instead of a collaborative federation. The service-oriented business rules system is not an event-based system. It assumes the existence of a knowledge base, against which user queries are issued, and aims to answer such queries by applying all relevant business rules. It provides a web service interface to communicate with different engines; however the actual processing of the rules is done by a rule engine, which uses an interpretive approach. There is no rule structure or workflow-like construct for modeling business processes. The Rule Interchange Format effort is a fairly new one. At the time of this can be extended to derivation rules, reactive rules, as well as integrity constraints, which are future deliverables. After surveying the existing efforts and systems that are related to our work, we have arrived at the following two conclusions. To our knowledge, there is no system that uses a combination of different rule types to manner. The interoperation among distributed, heterogeneous rules in a collaborative federation has not been investigated.

PAGE 27

27 CHAPTER 3 KNOWLEDGE SPECIFICATION LANGUAGE Rules and rule structures specified in an XML format are used for two purposes: translation to the corresponding web services for rule processing, and transmission among collaborating organizations for knowledge exchange. Each organization uses a GUI tool to define a set of rules and rule structures that form a local rulebase to be shared with other organizations. Each rule has the following characteristics: a name, a description, an optional state (which can be either active or suspended, the default being active), and a sharing attribute to indicate whether the rule is local to the defining organization or global, i.e. shared across the federation. The root element RuleBase represents the local rulebase. RuleBase has one or more child elements, Rule, which represent individual rules. The Rule constructs that define a RuleBase are shown in the Backus-Naur Form (BNF) syntax below. The elements IntCons, Implies, and CAARule represent an integrity constraint rule, a derivation rule and a condition-action-alternative_action rule respectively. They are described in detail in the following sections. We adopt BNF syntax notations to describe the language for clarity and conciseness. The actual XML schema is included in Appendix A. The schema for describing the rule structure, events, event data as well as operations is also included in Appendix A. The notation A ::= B, where both A and B are non-terminal symbols, is used to denote that the XML element B is a direct descendant of the XML element A; i.e., A is described by the following schema . The notation A ::= t, where A is a non-terminal symbol and t is a terminal symbol, is used to denote that the value of A is restricted to the terminal t. Square brackets denote an optional element; i.e., an element which can appear either zero or one time. Curly brackets denote an element that can appear zero or more times. Boldface font is used to distinguish

PAGE 28

28 terminal symbols from non-terminal symbols. The terminal symbol letter is used to represent uppercase (A-Z) and lowercase (a-z) letters of the alphabet, digit is used to represent decimal digits 0-9, and the symbol space is used to indicate any whitespace (a single space, a tab, a line feed, etc.). RuleBase ::= Rule {Rule} Rule ::= RuleName RuleDescription [RuleState] Sharing IntCons | RuleName RuleDescription [RuleState] Sharing Implies | RuleName RuleDescription [RuleState] Sharing CAARule RuleName ::= letter {letter | digit | space} RuleDescription ::= letter {letter | digit | space} Sharing ::= local | global RuleState ::= active | suspended Integrity Constraints An integrity constraint [70] ensures that changes made to the database do not result in a loss of data consistency. In the context of this effort, it is used to verify the consistency of event data. For constraint specification, we adopt some syntactic constructs of our earlier work on a Constraint Specification Language [64], which was patterned after the Object Constraint Language [75]. Since we use an object-oriented data model to represent event data, constraints can be specified on an object or on one or more of its attributes. Constraints can be classified into two types: attribute constraint and inter-attribute constraint. Thus, the IntCons element representing the integrity constraint has the following syntax. The element AttCons represents an attribute constraint and InterAttCons represents an inter-attribute constraint. IntCons ::= AttCons | InterAttCons An attribute constraint is of the form or 1,n2a} where x is an object or object attribute, n is a value from x is one of the six

PAGE 29

29 in}, and {n1,n2a} represents a set of enumerated values from xconstraint specifies the allowed or valid constant values of an object or object attribute. Examples of attribute constraints are: a >10, b in {2, 5, 9}, where a and b are object attributes. The BNF syntax of an attribute constraint is shown below. AttCons ::= DataItem RelOp Value | DataItem EnumOp Value {Value} DataItem ::= Name Type Name ::= letter {letter | digit | space} Type ::= String | double | float | int | boolean |java.io.File |java.util.Date | java.util.HashMap | npdn.Sample | npdn.Shipment | npdn.ResponsePlan | npdn.Result | eurent.Branch | eurent.Car | eurent.Rental | eurent.Customer | eurent.Group Value ::= {letter | digit} | digit {digit} {digit} RelOp ::= gt | lt | ge | le | eq | ne EnumOp ::= in | not in The object or object attribute is represented by the element DataItem, which consists of a name and a type. Since we generate web services from such constraint specification programmatically, the precise name and type information are needed by the programming language used to implement the web service. Also, the type information is specific to the programming language Java in our implementation, but it can be easily changed or extended for any other programming language. Furthermore, any additional types introduced by the application domain also need to be specified here. In the above BNF, we have included the type specifications for the NPDN and the EU-rent domains. Element RelOp stands for arithmetic comparison operators, element EnumOp for the enumeration operator, and Value for constant values. An inter-attribute constraint is of the form f1(x1,x2b2(y1, y2c), or If P1 2 d then Q1 2 e

PAGE 30

30 where f1(x1,x2b) and f2(y1, y2c) are mathematical formulas relating the objects or object attributes x1,x2b, and y1, y2c, respectively. P1, P2d and Q1, Q2e are predicate expressions of the form f1(x1,x2b2(y1, y2c) which is a member of the set {AND, OR}. Examples of inter-attribute constraints are: a+b>=c, If (a>10 and b>15) then (c=5), where a, b and c are object attributes. Based on the above definition, we categorize the inter-attribute constraints into two sub-types. Constraints specified using the first form described above are called formula constraints and those specified using the second form are called condition constraints. Their BNF syntaxes are shown below. InterAttCons ::= FormulaCons | CondCons FormulaCons ::= Expr RelOp Expr Expr ::= Term {MathOp Term} | Expr MathOp Expr {MathOp Expr} Term ::= DataItem | Value | Operation MathOp ::= + | | / | Operation ::= OperationName {DataItem} [Returns] OperationName ::= letter {letter | digit | space} Returns ::= DataItem {DataItem} CondCons ::= IfExpr ThenExpr IfExpr ::= [Not] BooleanExpr {LogicalOp BooleanExpr} | [Not] IfExpr LogicalOp IfExpr {LogicalOp IfExpr} ThenExpr ::= [Not] BooleanExpr {LogicalOp BooleanExpr} | [Not] ThenExpr LogicalOp ThenExpr {LogicalOp ThenExpr} BooleanExpr ::= [Not] PredicateExpr | [Not] Term PredicateExpr ::= Expr RelOp Expr LogicalOp ::= AND | OR The formula constraints are represented by the element FormulaCons, whereas the condition constraints are represented by the element CondCons. Each of these XML elements makes use of building blocks like the elements Expr for an expression, IfExpr, for the if construct, and ThenExpr for the then construct. The Expr construct is composed of one or more Term elements linked by mathematical operators. A Term can be a single data item, a constant

PAGE 31

31 value, or an operation. An operation represents a function that operates on zero or more parameters yielding zero or more output data items. An IfExpr element is composed of one or more Boolean expressions, represented by BooleanExpr, which in turn can be either a predicate expression (an expression that links two Expr elements by a comparison operator), or a single term. Derivation Rules Logic-based derivation rules [71], also known as inference rules or deductive rules, assess a given premise to come to some conclusion. They can be expressed as or P => Q the semantics of which are: If P is evaluated to true based on the contents of the event data, then Q should be made true (i.e., data expressed by Q should be added to the event data). P is the body of the implication, and Q is the head or conclusion. Both P and Q are Boolean expressions of the form r 1 2 m where each r i ( ) is a premise if r i P and is a part of the conclusion if r i Q is the logical operator, AND or OR We allow arbitrary nesting of the logical operators in P and as such do not restrict P to conform to either conjunctive or disjunctive normal form, instead we rely on grouping or nesting constructs (parentheses) which allow the creator of the rule to specify his/her semantics precise ly. We restrict the logical operator in Q to be and for clear interpretation of the conclusion. If or semantics are desired as shown in the following rule R R: p => q 1 V q 2 n

PAGE 32

32 The single rule R can be rewritten as multiple rules r1n, with each ri () having the same premise p as the original rule, and qi as the conclusion. The derivation rule syntax is shown below: Implies ::= Body Head Body ::= IfExpr Head ::= Atom {AndOp Atom} Atom ::= DataItem RelOp DataItem | DataItem RelOp Value AndOp ::= AND It is derived in part from RuleML [30]. The implication is represented by the element Implies. Implies consists of the Head and Body elements. The Head element contains one or more Atom elements linked by the AND operator. Each of these atoms specifies a new or derived value for the indicated object or object attribute. The Body element is represented by the element IfExpr. Premises in our language can contain executable functions in addition to variables. Action-oriented Rules Action-oriented rules are typically found in active database systems [78]. They are known as event-condition-action (ECA) rules or just event-action rules [44]. When an event specified by the event clause occurs, the ECA rule checks for the truth value of the condition clause, and executes the action clause if the condition expression is true. The general format of the rule is thus On E if C then execute A If we separate the event (E) from the condition-action (CA) part, we see that the CA part is in fact the action-oriented rule. The event is used to indicate when to perform the action-oriented rule. Also, an action-oriented rule may specify what actions are to be taken when the condition expression evaluates to false. We can model this concept as two complimentary if-then rules C1A, and C2B

PAGE 33

33 where C2 is the complement of C1, and A and B are action clauses. Another way would be to model them as a single condition-action-alternative_action (CAA) [41] rule. Thus, the semantics of the CAA rule are as shown below. We use this form of the action-oriented rule in our work. If C then A else B Since we are interested in developing a distributed eventand rule-based system, the separation of the event specification and the action-oriented rule specification is important. It allows events and action-oriented rules to be defined by different organizations. Events can be flexibly linked to action-oriented rules by triggers, which can be defined by the same or other organizations. It also allows an organization to link an event with not only a CAA rule, but any other type of rules or a rule structure. Thus an event occurrence can invoke an integrity constraint check, a derivation of new data, an execution of a CAA rule, and/or an execution of a rule structure. We show the syntax of a condition-action-alternative_action rule below. CAARule ::= [Condition] Action [AlternativeAction] Condition ::= [Guard] CondExpr Guard ::= PredicateExpr {PredicateExpr} CondExpr ::= IfExpr Action ::= Operation {Operation} AlternativeAction ::= Operation {Operation} The condition clause is represented by the Condition element, the action clause by the Action element and the alternative-action clause by the AlternativeAction element. Each of these elements uses the building blocks like IfExpr, Expr, Term, etc. mentioned earlier. An action-oriented rule may want an action to be executed unconditionally. This is why the Condition element is optional. Also, there may be no defined alternative action for a particular rule. Thus, the AlternativeAction element is also optional.

PAGE 34

34 The condition expression consists of two parts an optional guard clause and the condition clause. If the guard evaluates to false, the execution of the rule is skipped, thereby serving as a means of conditionally deactivating the rule. If not, the condition is evaluated to determine whether to perform the action or the alternative action, which are represented by Action and AlternativeAction elements, respectively. These elements are described by one or more operations. Rule Structure When a specific event occurs, an organization may have a number of applicable rules that need to be executed in a specified order. It is very natural to model a process or an operating procedure by specifying the structural relationship between individual rules. We capture this relationship by means of a rule structure [41]. In an organizational process, a rule r may be required to execute before another rule s, thus establishing a direct link between r and s. Similarly, a rule r may be required to execute before multiple rules s1, s2m, m>1, which can then be processed in parallel. In this case, r is connected to s1, s2m in a split construct. A rule s may be required to wait for all of a given set of rules r1, r2n, n>1 to finish before it can start its own execution. In this case, r1, r2n are connected to s in an and-join construct. Also, s may be required to wait for not all but a subset of the rules r1, r2n n>1 to finish execution. This establishes an or-join relationship between r1, r2n and s. In each type of relationship, the rule(s) that governs(govern) the execution of other rules is(are) termed predecessor(s), and the rule(s) that executes(execute) after the predecessor(s) is(are) termed successor(s). A rule structure can now be defined as a directed graph with different types of rules as nodes that are connected by link, split, and-join, and or-join constructs.

PAGE 35

35 Some example rule structures are shown in Figure 3-1. R1, R2R8 are individual rules which could belong to any of the three types discussed above. The syntax of a rule structure is given below. RuleStruc ::= Name RuleStrucDescription [RuleStrucState] Sharing RuleSubStruc {RuleSubStruc} RuleStrucDescription ::= letter {letter | digit | space} RuleStrucState ::= active | suspended Sharing ::= local | global RuleSubStruc ::= Link | Split | AndJoin | OrJoin Link ::= Predecessor Successor Split ::= Predecessor Successors AndJoin ::= Predecessors Successor OrJoin ::= Num Predecessors Successor Predecessor ::= RuleName Predecessors ::= RuleName RuleName {RuleName} Successor ::= RuleName Successors ::= RuleName RuleName {RuleName} RuleName ::= letter {letter | digit | space} Name ::= letter {letter | digit | space} Num ::= digit {digit} It is represented by the RuleStruc element. A complicated rule structure can be broken down into substructures, each of which represents a single type of relationship between two or more rules. We represent such substructures using the RuleSubStruc element. Each type of relationship is represented by XML elements with the respective name. The predecessors and successors are represented by the following elements: Predecessor (rule r in a link or split), Predecessors (rules r1, r2rn in a join), Successor (rule s in a link or join), and Successors (rules s1, s2sm in a split). Num indicates the number of predecessor rules to be executed in an or-join before the successor rule can be invoked. Examples of Rules and Rule Structures from Two Application Domains We now give some selected examples of rules and rule structures defined for two application domains: e-business (EU-Rent car rental company) and Agricultural Homeland Security (the National Plant Diagnostic Network).

PAGE 36

36 EU-Rent Car Rental Company The GUIDE Business Rules Project [38] an approach for identifying and articulating the rules which define the structure and control the of a fictitious car rental company EU-Rent, which is owned by EU-Corporation. EU-Rent is one of the three businesses that EU-Corporation operates; the other two are EU-Fly airlines, and EU-Stay hotels. EU-Rent has 1000 branches in towns in several countries. At each branch cars, classified by car group, are available for rental. Each branch has a manager and booking clerks who handle rentals. The car rental company has to handle rental reservations, rental returns, car servicing, maintain customer relations, promote customer loyalty, and deal with car purchase and sale. These tasks form the core of the company and it is therefore very essential that they be managed in a very consistent and efficient manner. EU-Rent has captured key aspects of each task in the form of business rules. Such rules are broadly similar across branches; however, each branch also has its own local set of policies that generate its own local set of business rules. Each branch may wish to share some data and knowledge specifications with the other branches to achieve better management of the company as a whole. Thus each branch is a collaborating site in the collaborative federation of the EU-Rent company. We realize that the above is not a real-world inter-organizational setting, yet it suffices to serve our purpose due to the following reasons. First, the rule set has been independently constructed and published for academic use by a well-known group. Second, each of the rules in the rule set belongs to one of the three different rule types processed by our system. Third, as can be seen from the rule set, managing the activities of a branch requires the interoperation of

PAGE 37

37 different rule types captured in a rule structure. We now give some example rules and a rule structure from the rule set and their conversion to our knowledge specification language. Example Rules and Rule Structure from the EU-Rent Rule Set Example Rule 1 Rule: Reservations may be accepted only up to the capacity of the pick-up branch on the pick-up day. Name: capacityCheck Type: Integrity Constraint Rule Representation in Knowledge Specification Language: We include only the main XML element Branch.numReservations int le Branch.capacity int Example Rule 2 Rule: To join the loyalty incentive scheme, a customer must have made 4 rentals within a year.

PAGE 38

38 Name: eligibleForLoyaltyScheme Type: Derivation Rule Representation in Knowledge Specification Language: We include only the main XML element Customer.numYearlyRentals int ge <>4 Customer.eligible boolean eq <>true

PAGE 39

39 Example Rule 3 Rule: After all assignments within a group have been made, 10% of the group quota for the branch (or all remaining cars in the group, whichever number is lower) must be reserved for the -in rentals. Surplus capacity may be used for upgrades. Name: reserveForWalkIn Type: Condition-Action-Alternative_Action Rule Representation in Knowledge Specification Language: We include only the main XML element Group.numRemainingCars int gt * Group.quota int

PAGE 40

40
reserveGroupByQuota Group.groupID int Group.quota int reserveGroupByRemCars Group.groupID int Group.numRemainingCars int
Example Rule Structure Rule Structure: Each paid rental in the (loyalty incentive) scheme (including the 4 qualifying can be bought with points. Extras, such as insurance, fuel and taxes must be paid by cash or credit card. A free rental must be booked at least fourteen days before the pick-up date. Free rentals do not earn points. Name: RS1 Representation in Knowledge Specification Language: This is a rule structure that can be used to

PAGE 41

41 only the basic cost of the rental is bought with points and extras are paid for by using a CAA Free Rental Rule Structure Procedure to give a free rental ACTIVE global eligibleForLoyaltyScheme freeRental freeRental freeRentalPoints checkAdvBooking National Plant Diagnostic Network The United States Department of Agriculture, Cooperative State Research, Education and Extension Service (USDA, CSREES) launched a multi-year national project in May 2002 to build the National Plant Diagnostic Network (NPDN) [49]. This was done with a view to

PAGE 42

42 riculture by facilitating quick and accurate detection of disease and pest outbreaks in crops. Such outbreaks can occur naturally as foreign pathogens are introduced into the United States through mechanisms ranging from accidental importation to air-borne introduction by currents that traverse entire continents [63, 72]. They can also occur intentionally through deliberate introduction, as an act of bioterrorism [69]. In this nation-wide effort, the University of Florida was selected as the southern regional center of NPDN and is responsible for building a Southern Plant Diagnostic Network (SPDN) [61]. SPDN consists of a regional center system at the University of Florida and 12 state systems (counting Florida) and Puerto Rico connected to the regional center system through the Internet. The functions of the SPDN Regional Center are: to establish a network for the detection and diagnosis of plant health problems, extend and support sound public policies, implement environmentally sound prevention and management strategies, and provide leadership and training. Data collected from the region is sent to NPDN at Purdue University in Indiana. We intend to use this real-world example to demonstrate the applicability and usefulness of our system. One of the plant diseases being monitored by USDA is Asian soybean rust [34], which is an aggressive fungal disease that can potentially reduce soybean yield by as much as 80 percent. Another disease is Sudden Oak Death, which is a disease capable of causing a range of symptoms from leaf spots to plant death on many woody hosts [68]. Plant growers and others (first detectors) may submit samples to an NPDN lab to be diagnosed. The lab runs preliminary diagnostic tests. If the results are positive, the lab staff seeks the help of a central authority designated for confirmation of the disease. We have obtained the diagnostic procedures from NPDN for the above two diseases. An analysis of these procedures reveals the existence of the

PAGE 43

43 three types of knowledge rules and rule structure. We present some examples rules and rule structure from these procedures along with their representations in our knowledge specification language below. The derivation rule and the CAA rule have been obtained from [50], and the integrity constraint is obtained from the NPDN required fields list [29]. The rules obtained from [50] are described in Appendix C. The derivation rule mentioned here, is included as part of another CAA rule in the appendix to preserve the structure of the operating procedures as outlined by NPDN. Example Rules and Rule Structure from NPDN Plant Diagnostic Laboratories Example Rule 1 Rule: viewed by a diagnostician. Name: NPDNR1 Type: Derivation Rule Representation in Knowledge Specification Language: We include only the main XML element Sample.examined boolean eq true

PAGE 44

44
Sample.classification String eq <>Presumptive Positive
Example Rule 2 Rule: -Genus-e onfirmeduspectedInconclusiveot Detected Name: NPDNR2 Type: Integrity Constraint Rule Representation in Knowledge Specification Language: We include only the main XML element PestGenusConfirmation String in <>C <>S <>J N

PAGE 45

45 Example Rule 3 Rule: Triage Lab staff, NPDN Regional Hub Lab staff and APHIS-PPQ Confirming Diagnosis Designate may conduct live web-based distance diagnosis examination of sample and microscope mounts, if Triage Lab has this distance diagnosis capability. Or the diagnostician can take a digital image and email to the other two diagnosticians if web cam is not available Name: NPDNR3 Type: Condition-Action-Alternative_Action Rule Representation in Knowledge Specification Language: We include only the main XML element distance_diagnosis_capability boolean eq Conduct_Web_Based_Diagnosis

PAGE 46

46 npdn.Sample.* npdn.Sample
Email_Picture sample_image java.io.File
Example Rule Structure Rule Structure: If an NPDN Regional Hub or Expert Lab receives a presumptive positive sample, Expert Lab Staff acknowledges sample receipt to Triage Lab. NPDN Regional Hub or Expert Lab staff examines presumptive positive sample. NPDN Regional Hub or Expert Lab staff may contact Local expert, for additional input, but does not disclose state of origin. This is performed Local Expert may examine sample. Local Expert may make preliminary diagnosis in collaboration with NPDN Regional Hub or Expert Lab staff. Local Expert contacts NPDN Regional Hub or Expert Lab Diagnostician with conclusions/results. This NPDN Regional Hub or Expert Lab Diagnostician contacts NPDN Regional Director and APHIS-PPQ-Confirming Diagnosis Designate with preliminary conclusions/results. NPDN Regional Hub or Expert Lab staff contacts own SPRO and APHIS-PPQ SPHD to inform them that a presumptive positive sample is housed in NPDN Regional Hub or Expert Lab until shipment to APHIS-PPQ Confirming Designate or until it is destroyed following diagnosis. The state of origin is not disclosed to NPDN Regional Hub or or SPHD. NPDN Regional Hub or Expert Lab staff contacts its own

PAGE 47

47 Campus Safety Officer to inform of presumptive positive sample in the lab. State of origin is not disclosedIf APHIS-PPQ Confirming Diagnosis Designate requests NPDN Regional Hub or Expert lab to send sample for confirmation, then NPDN Regional Hub or Expert Lab contacts APHIS-PPQ Confirming Diagnosis Designate and Triage lab indicating that they are sending the presumptive positive sample to APHIS-PPQ Confirming Diagnosis Designate Lab including shipment date, method, tracking number and sample number. This is performed by CAA rul Representation in Knowledge Specification Language: Rule NHLR1 is executed first, followed by rules NHLR2 and NHLR3 in parallel. After both NHLR2 and NHLR3 finish execution, rule NPDN Regional Hub Lab Procedure Procedure followed by the NPDN Regional Hub Lab ACTIVE global NHLR1 NHLR2 NHLR3 NHLR2 NHLR3 NHLR4

PAGE 48

48
Figure 3-1. Example rule structures R2 L R2 R1 R3 R4 R3 R1 R2 R4 R5 R6 R7 R8 S A L L S L O[1] A A = AND JOIN L = LINK O = OR JOIN S = SPLIT R1

PAGE 49

49 CHAPTER 4 HETEROGENEOUS RULES AS WEB SERVICES In Chapter 1, we mentioned our idea of translating different types of rules and rule structures at rule definition time into code and wrapping this code as web services for their uniform registration, discovery and invocation in a web service infrastructure. In this chapter, we present the algorithms for automatically converting the three types of rules and rule structures to web services. Creating a Web Service The W3C group defines web services as follows. A web service is a software application identified by a uniform resource identifier (URI), whose interfaces and binding are capable of being defined, described and discovered by XML artifacts and supports direct interactions with other software applications using XML based messages via Internet-based protocols. [60]. Since the introduction of the web services concept, the software industry has provided many tools to wrap application code as a web service. Software developers can thus focus on developing the application code instead of worrying about conformity with the web service protocols laid out by W3C [11]. Therefore, the most significant task in creating a web service is the development of application code to be exposed as a web service. Figure 4-1 gives an overview of the algorithm for web service synthesis. It takes as input a rule specification in XML that conforms to the knowledge specification language presented in Chapter 3. The algorithm identifies the type of the rule and invokes appropriate handler methods to create the source code for the rule (steps 3-5). This code is generated as an interface (or header) file and an implementation (or source) file. The implementation file contains the translation of the rule to code. Each rule is represented as a web service with one operation, the

PAGE 50

50 characteristics of which depend on the rule type. A web service operation translates to a method in a programming language. The specification of input and output parameters of the operation is the terms method and operation interchangeably. For successful compilation and deployment of a web service, we need to create the appropriate WSDL document. This is done with the help of configuration files, the exact type and nature of which depend on the application framework used (steps 6-8). To facilitate the discovery of a web service using UDDI, we also publish the web service to a private UDDI registry (step 9). Algorithms for Different Rule Types In the following sections we describe the algorithms used to create the web services for each of the three rule types. The basic idea in the algorithms is to create the code (using the Java programming language) that captures the intent of the rule. Thus, we build the interface and implementation files line by line. We use the pseudo code statement to indicate that program statement A should be written out to either the interface or the implementation file, as specified. When navigating through the XML rule document specified, we use the construct elem1elem2 to refer to the XML child element elem2 of the XML element elem1. We use the term method to refer to the web service operation generated for the specific rule type, and the term algorithm to refer to the algorithm for creating the method. Integrity Constraints Each integrity constraint rule is represented as a web service with the operation/method check. The algorithm determines the type of the constraint and generates the appropriate program statements for check, details of which are given in Figure 4-2. The method check examines the supplied input data and returns a Boolean value which is true if the specified

PAGE 51

51 constraint is satisfied and false otherwise. Specific cases to handle comparison operators, enumeration operators, formula constraints and condition constraints are shown in the algorithm. All data items referenced in the constraint rule constitute the input to check. If the constraint type is an attribute constraint, the rule code checks if the relationship specified by the comparison or the enumeration operator holds. If the constraint is an inter-attribute constraint of the formula constraint subtype, the algorithm first generates code for the expressions on the left hand side and the right hand side as lExprCode and rExprCode, respectively. The method check then determines if the lExprCode is related to rExprCode as specified by op, where op is the comparison operator used. For a condition constraint, the algorithm generates code for the if-part and the then-part as ifPartCode and thenPartCode, respectively. The method check then determines if ifPartCode is true. If so, it determines if thenPartCode also holds true. Derivation Rules Each derivation rule is translated to a web service with the operation/method implies. This method examines the input data to determine if the body of the implication is true. If so, it returns the new data specified in the head of the implication. Figure 4-3 shows the algorithm for creating the method. The input parameters to the method implies are the data items required by the body of the implication The body contains one or more Boolean expressions linked by logical operators and and or. The getBodyVal function translates the implication body into program statements. Each Boolean expression in the implication body makes use of the function getExprCodefrom Figure 4-2 to generate the code for the expression. The head of the implication contains one or more Atom elements linked by the and operator. Each of these elements contains a derived data item and the corresponding

PAGE 52

52 value. This value can be a constant value or another data item. The function getHeadMap constructs a hashmap named headVal, which contains the new data as a (name, value) pair indexed by name. If the body evaluates to true, the output contains each pair in headVal, otherwise it is null. CAA Rules Each CAA rule is translated to a web service with the operation/method perform. If the guard clause evaluates to true, this method examines the input data to see if the condition is satisfied. If so, the operations specified in the action clause are executed, and the output of those operations is returned, otherwise the operations specified in the alternative_action clause are executed and the output of those operations is returned. Figure 4-4 gives the algorithm for creating the method perform. The input parameters to the rule are the data items referenced in the condition clause, and the data items specified as input to the operations in the action and alternative_action clauses. The output data from the operations in the action clause are added to the hashmap actionData, and the output data from the operations in the alternative_action clause are added to the hashmap altActionData. Both these maps contain (name, value) pairs, indexed by name. The function getConditionCode translates the condition clause to program statements. Similarly, the functions getActionCode and getAltActionCode translate the action and alternative_action clauses to code, respectively. The output of the method perform is a hashmap named map, which contains the result of the operations performed by the rule. At runtime, either the action or the alternative_action clause is executed, and map contains the corresponding output. The function getActionCode is shown in some detail in Figure 4-4B. getAltActionCode is very similar and is not shown separately. An action (or alternative_action) clause consists of a list of operations to be executed. The function translates

PAGE 53

53 each operation to program statements of the form output = operation name (input), or operation name (input) depending upon whether the operation contains return parameters or not. In case the operation returns multiple data items, we create an output class that captures all of these data All such program statements are stored in the array actionVal (or altActionVal), which is returned. Rule Structure A rule structure links rules together in a directed acyclic graph as explained in Chapter 3. It is defined and published as a web service just like any other rule. We require the following condition to be met to guarantee that the generated web service for a rule structure will be executable. Each of the rules in a rule structure must have already been defined and published as a web service before the rule structure is defined. Each rule structure is represented as a web service with the operation/method execute. Figure 4-5 shows the algorithm for creating execute. This method takes in all the input data items required by all the rules in the structure, and returns the output data items produced by all these rules. The objective of the method is to invoke the rules in the order specified by the structure. To facilitate this, it creates invoker threads for each rule in the structure. The algorithm to create such an invoker thread () is also shown in the figure. The algorithm rsHandler breaks down the given rule structure into substructures. Details of how a given rule structure is partitioned into substructures and how such partitioning aids rule structure execution will be presented in Chapter 5. Each substructure contains a link, a split, an and-join, or an or-join relationship between two or more rules. The algorithm generates invoker threads for every distinct rule in the substructure. Depending on the substructure type, one of the four handler functions is called. Each of these handler functions is responsible for

PAGE 54

54 generating code that will cause the rule execution in the manner specified by the corresponding substructure type. The method execute is then constructed by putting together code generated by each of the handler routines. The method execute maintains an array toBeExecuted to keep track of those rules that have yet to begin execution. linkHandler generates program statements to ensure that a successor rule r2 is executed only after the predecessor rule r1 has finished execution as follows. First, the code creates an invoker thread object for r1. If this is a newly created thread, r1 is included in toBeExecuted, if not already put in, and starts the thread for r1. Once this rule has finished execution, it copies the output items from r1 r1 from toBeExecuted. It creates an invoker thread for r2, and puts it in toBeExecuted if this is a newly created thread. Once r1 finishes execution, r2 is allowed to proceed. Once r2 has finished execution, it is removed from toBeExecuted, and its output copied to member variables. Similarly, splitHandler generates code to invoke the successor rules only after the predecessor rule has been executed, andJoinHandler generates code to execute the successor rule only after all the predecessor rules have been executed, and orJoinHandler generates code to execute the successor rule only after the specified number of predecessor rules have been executed. The algorithms for splitHandler and orJoinHandler are included in Figure 4-5.

PAGE 55

55 Figure 4-1. Algorithm for web service synthesis Algorithm 1 createWebService ( 1 ) rules = getRules( ruleBase ); ( 2 ) for each rule r do ( 3 ) if ( r i s an integrity constraint) icHandler( r ); end if ( 4 ) else if ( r is a derivation rule) drHandler( r ); end if ( 5 ) else if ( r is a CAA rule) caaHandler( r ); end if (6) createConfigFiles( r ); (7) compile( r ); ( 8 ) deploy( r ); ( 9 ) publish( r ); ( 10 ) end for

PAGE 56

56 Figure 4-2. Algorithm for integrity constraint rules Algorithm 2 icHandler ( 1 ) paramNames = null, paramTypes = null; stmts = null; ( 2 ) if constraint c is an attribute constraint do ( 3 ) d = c (4) add d d paramN ames and paramTypes respectively (5) op = c (6) if op is a comparison operator (7) stmts (8) end if (9) if op is the enumeration operator in (10) values = getValues(c); (11) stmts (12) end if (13) if op is the enumeration operator not in (14) values = getValues(c); (15) ) stmts ( 16) end if (17) else if constraint c is an inter attribute constraint do (18) dataItemList = getInputData( c ); ( 1 9) for each DataItem d in dataItemList do (20) add d d paramNames and paramTypes respectiv ely ( 21 ) end for ( 22 ) if c is a formula constraint do ( 23 ) lExprCode = getExprCode( c ( 24 ) op = c ( 25 ) rExprCode = getExprCode( c ( 26 ) to stmts ( 2 7) end if ( 2 8) else if c is a condition constraint do (29) ifPartCode = getIfExprCode( c (30) thenPartCode = getThenExprCode( c (31) stmts (32) end else (33) end else (34) createServiceInterfaceFile( paramNames paramTypes ); (35) createServiceImplementationFile( paramNames paramTypes stmts ); Function: createServiceImplementationFile(paramNam es, paramTypes, stmts) ( 1 ) for each stmt s in stmts do (2) write s to file ( 3 ) end for ( 4 )

PAGE 57

57 Figure 4-3. Algorithm for derivation rules Algorithm 3 drHandler ( 1 ) paramNames = null, paramTypes = null; ( 2 ) body = implies ( 3 ) head = implies ( 4 ) dataItemList = getInputData( body head ); ( 5 ) for each DataItem d in dataItemList do (6) add d d paramNames and paramTypes respectively. (7) end for (8) bodyVal = getBodyCode( body ); (9) headVal = getHeadCode( head ); (10) createServiceInterfaceFile( paramNames paramTypes ); (11) createServiceImplementationFile( paramNames paramTypes bodyVal headVal ); Function: getHeadCode(head) (1) headVal = null; (2) atomList = getAtoms( head ); (3) for each Atom a in atomList do (4) dataItem = a (5) value = a (6) add the pair ( dataItem value ) to headVal (7) end for (8) return headVal ; Function: createServiceImplementationFile(paramNames, paramTypes, bodyVal, headVal) (1) wri (2) (3) for each pair ( dataItem value ) in headVal do (4) (5) end for (6) ( 7 )

PAGE 58

58 Figure 4-4. Algorithm for condition-action-alternative_action rules. A) Description of the overall algorithm Algorithm 4 caaHandler ( 1 ) paramNames = null, paramTypes = nul l, actionMap = null, altActionMap = null; (2) actionData = null, altActionData = null; (3) condition (4) condExpr (5) action (6) altAction (7) dataItemList = getInputData( condition action altAction ); (8) for each DataItem d in dataItemList do (9) add d d paramNames and paramTypes respectively (10) end for (11) dataItemList = getInputData ( action altAction ) (12) f or each DataItem d in dataItemList do (13) add d d paramNames and paramTypes respectively. (14) end for (15) dataItemList = getOutputData( action ); (16) for each DataItem d in dataItemList do (17) a dd d d actionData (18) end for (19) dataItemL ist = getOutputData( altAction ); (20) for each DataItem d in dataItemList do (21) add d d altActionData (22) end for (23) conditionVal = getCondCode( condition ); (24) actionVal = getActionCode( action ); (25) altActionVal = getAltActionCode( altAction ); (26) createServiceInterfaceFile( paramNames paramTypes ); (27) createServiceImplementationFile( paramNames paramTypes conditionVal (28) actionVal altActionVal actionData altActionData );

PAGE 59

59 Figure 4-4. Algorithm for condition-action-alternative_action rules. B) Description of supplementary functions Fu nction: getActionCode(action) ( 1 ) actionVal = null; ( 2 ) operationList = getOperations( action ); ( 3 ) for each o peration o in operationList do ( 4 ) name = o dataItemList = getInputData( o ); return = o (5) create the parameter list from dataItemList (6) if return == null (7) actionVal (8) end if (9) else ( 10) returnData (1 1 ) if returnData contains only one data item ( 1 2) actionVal (1 3 ) e nd if (14) else (15) outputClass (16) for each DataItem d in returnData do (17) include d as a member of the output class; (18) end for (19) actionVal (20) actionVal (21) end else (22) end else (2 3 ) end for ( 24) r eturn actionVal; Function: createServiceImplementationFile paramNames, paramTypes, conditionVal, actio nVal, altActionVal, actionData, altActionData); (1) (2) conditionVal (3) write actionVal to file (4) f or each pair ( dataItem value ) in actionData do (5) (6) end for (7) w (8) write altA ctionVal to file (9) for each pair ( dataItem value ) in altA ctionData do (10) (11) end for (1 2)

PAGE 60

60 Figure 4-5. Algorithm for rule structures. A) Description of the overall algorithm and the Algorithm 5 rsHandler (1) ruleStrucList = getRuleSubStruc( ruleStruc ); (2) ssVal = null; (3) distinctRules = get distinct rules referred in ruleStruc (4) for each rule r in distinctRules do ( 5) createCallerRoutine( r ) (6) end for (7) for each RuleSubStruc rss in ruleStrucList do (8) if rss is a Link ssVal + = linkHandler( rss end if (9) if rss is a Split ssVal + = splitHandler( rss end if (10) if rss is an ANDJoin ssVal + = andJoinHandler( rss end if (11) if rss is an ORJoin ssVal + = orJoinHandler( rss end if (12) end for (13) createServiceInterfaceFile(); (14) c reateServiceImplementationFile( ssVal ); Function: create InvokerThread (Rule r) r.name (2) dataItem List = getInputAndOutput( r ); (3) for each DataItem d in dataItem List do (4) declare a corresponding public data member with same name and type (5) end for (7) prepare for rule web serv ice call and write it out to the file (8) write code to call the rule web service to the file (9) for each DataItem d generated by the web service do (10) copy d (11) end f or Function: splitHandler(Split s) (1) pred = s (2) succList = s (3) splitVal callPred = invoker thread to call pred (4) splitVal for each Rule succ in succList do (5) splitVal callSucc = invoker thread to call succ (6) splitVal end f or

PAGE 61

61 Figure 4-5. Algorithm for rule structures. B) Description of the function for handling the OR join relationship (7) splitVal if callPred.state == NEW and callP red not in toBeExecuted (8) splitVal callP red to toBeExecuted (9) splitVal callPred ; (10) splitVal end if (11) splitVal if callPred.state == TERMINATED and callPred in toBeExecuted (12) splitVal callPred from toBeExecuted (13) splitVal (14) splitVal end if (15) splitVal for each R ule succ in succList do (16) splitVal if call Succ.state == NEW and callSucc not in toBeExecuted (17) splitVal callSucc to toBeExecuted (18) splitVal end if (19) splitVal if callPred .state == TERMINATED and callSucc.state == NEW (20) splitVal succ (21) splitVal end if (22) splitVal if call Succ .state == TERMINATED and callSucc in toBeExecuted (23) splitVal callSucc from toBeExecuted (24) split Val (25) splitVal end if (26) splitVal end f or (27) return splitVal ; Function: orJoinHandler(ORJoin o) (1) predList = o (2) succ = o (3) orJoinVal for each Rule pred in predList do (4) orJoinVal callPred = invoker thread to call pred (5) orJoinVal if callPred.state == NEW and callP red not in toBeExecuted (6) orJoinVal callP red to toBeExecute d (7) orJoinVal callPred ; (8) orJoinVal end if (9) orJoinVal if callPred.state == TERMINATED and callPred in toBeExecuted (10) orJoinVal callPred from toBeExecuted (11) orJoinVal (12) orJoinVal end if (13) orJoinVal end f or (14) orJoinVal num count = 0; (15) orJoinVal for each Rule pred in predList do (16) orJoinVal if call P red .stat e == TERMINATED (17) orJoinVal count (18) orJoinVal end if (19) orJoinVal end f or (15) orJoinVal if succ not in toBeExecuted and count >= num (16) orJoinVal (17) orJoinVa (15) return orJoinVal ;

PAGE 62

62 Figure 4-5. Algorithm for rule structures. C) Description of the function to generate the web service implementation file (20) orJoinVal callSucc = invoker thread for succ (21) orJoinVal if callSucc.state == NEW and callSucc not in toBeExecuted (22) orJoinVal call Succ (23) orJoinVal end if (24) orJoinVal if callSucc.state == NEW and count >= num (25) orJoinVal callSucc (26) orJoinVal end if (27) orJoinVal if call Succ .state == TERMINATED and c all Succ in toBeExecuted (28) orJoinVal call Succ from toBeExecuted (29) orJoinVal (30) orJoinVal end if (31) return orJoinVal ; Function: createServiceImplementation( ss Va l) (1) toBeExecuted == null (3) for each path execution p in ssVal (4) write p to file (5) end for (6) toBeExecuted

PAGE 63

63 CHAPTER 5 SYSTEM ARCHITECTURE AND RULE PROCESSING In this chapter, we describe our system architecture and implementation framework. We use example scenarios from the two application domains described in Chapter 3 to explain the event-triggered processing of distributed rules, rule structures and application operations. System Architecture The distributed eventand rule-based system called ETKnet has a peer-to-peer server architecture (Figure 5-1). All collaborating organizations have identical subsystems installed at their sites. Each site creates and manages its own events, rules, rules structures, triggers and operations, but their specifications are registered at the host site of a collaborative federation. The host maintains a repository of these specifications. The rule server component at each site stores and manages the web services generated for the rules and rule structures defined at that site. These web services are registered at the web service registry (WSRegistry) of the host site. The event server component is responsible for storing information about events defined at that particular site and information about event subscribers. A collaborating site can specify a trigger linking a distributed event to a rule or a rule structure, thus becoming an explicit subscriber of that event. This information is stored by the event server in a local database. Triggers can be automatically and dynamically generated by the system if the event data schema associated with an event occurrence is a superset of the input data schema of a rule or rule structure. In this case, the site that has the rule or rule structure becomes an implicit subscriber of the event. Both explicit and implicit subscribers will be notified upon the occurrence of an event. Distributed rules and rule structures are invoked and processed by replicas of the rule server. These rules and rule structures may invoke automated system operations and manual operations of collaborating sites. An event server at any site can

PAGE 64

64 serve as the coordinator for a particular knowledge sharing session initiated by an event occurrence at that site. It handles the integration and organization of the dynamic event data associated with the event occurrence. In a collaborative federation, since events, rules, triggers and operations can be defined by different collaborating organizations, terminology becomes an important issue. Specific terms used by an organization in its event, rule, trigger and operation specifications and in metadata descriptions can be quite different from those used by another organization. People searching for registered events and web services need some form of common ontology to resolve these discrepancies. It would be beneficial to define an ontology for a particular application domain in a collaborative federation. Thus, the host site in the system architecture also incorporates an ontology database to contain the terms used in event, rule, trigger and operation specifications, in event data and in metadata of these information and knowledge resources, and their mappings to concepts and concept associations defined in the domain ontology. The architecture also includes an ontology manager to resolve discrepancies and identify similarities between the specified terms, and to facilitate search. These components are included to give the reader a complete picture of the collaborative system. It should be noted that the design and implementation of such an ontology database manager is beyond the scope of this work. The user interface tools at the host and the collaborating sites aid users in the definition and maintenance of events, rules, rule structures, triggers and operations. These tools use the local security and access control policies to ensure that only authorized users get access to the system. These tools also provide the facility for creating and maintaining the domain ontology. However, their design and implementa

PAGE 65

65 been implemented by one of the members in the group working on application of the event and rule processing ideas in the NPDN domain. We have implemented the algorithms presented in Chapter 4 for converting knowledge rules and rule structures to web services in Java, with the Sun Java System Application Server Platform Edition 9.0 [66] as our application server. The event and rule servers have been implemented using the Enterprise JavaBeans 2.1 framework [46]. To facilitate easy and efficient lookup, we publish the deployed web services to our private UDDI registry. This registry makes use of the Apache jUDDI project [73] to communicate with MySQL Server 5.0 [48] that stores the web service information. The MySQL database is also used by the event server to store the event and trigger information. We use a private registry instead of a publicly available UDDI-based registry for two reasons. By eliminating clutter typically found in a business registry, we speed-up registry look up. Also, a private registry provides security, as it is available only to the organizations participating in a collaborative federation. The Sun Application Server provides many tools which facilitate the easy development of a web service. The bulk of the work is in generating the rule-specific source code. In addition, the following configuration files are needed to deploy the web service: config.xml, web.xml, sun-web.xml, and jaxrpc-ri.xml. The createConfigFiles function (Figure 4-1) uses the information from the service interface file to generate these configuration files. The web service is then compiled using the wscompile tool of the application server. This generates the WSDL description file and the service is then deployed using the wsdeploy tool of the application server. Once the service is deployed, it is published at the host site using the UDDI4J [67] API. The general event and rule processing strategy is as follows. When an event occurs at a collaborating site, the event data are first captured in an XML document. The site of occurrence

PAGE 66

66 now becomes the coordinating site (or coordinator) for this particular event processing scenario. The coordinator needs to determine the sites that contain applicable rules and/or rule structures (i.e., applicable sites) so that event data can be sent to them. Applicable sites are of two types. The first is those sites that have defined explicit triggers linking the event to one or more rules and/or rule structures. The second type is those sites that do not define explicit triggers, but do have rules and/or rule structures whose input data items are a subset of the event data items (i.e., applicable rules and/or rule structures). Such rules and/or rule structures can contribute to the event data and thus should be processed. Our system generates implicit triggers for the second type of applicable sites, details of which are described later. To determine the applicable sites, the coordinator queries the host event server passing the event data as the query input. The host site first examines the explicit triggers to determine the first type of applicable sites. For the remaining sites in the federation, the host site examines the published rule information to determine if any site contains applicable rules and/or rule structures. Once the coordinator receives this site information, it sends the XML document their corresponding local rule servers. Each local rule server carries out a three-step process. In the first step, it examines the explicit triggers and records the rule and rule structures that need to be processed. In the next step, it examines the event data and determines the rules and/or rule structures whose input is a subset of the event data. These rules and/or rule structures are also recorded. In the last step, it examines the recorded rules to see if any of them will be executed as part of a rule structure. A rule structure is specified by a decision-maker, and captures the required order of execution for the rules that participate in the structure. Thus, any applicable rule that is already part of an applicable rule structure, if processed individually, will result in the

PAGE 67

67 same rule being processed twice. Also, the processing of individual rules may not honor the order of execution. Thus, applicable rules that will be processed as part of an applicable rule structure are removed, and the remaining applicable rules and/or rule structures are processed. The processing of these applicable rules and rule structures may add data to or update the data in the event data document. They may also activate automated or manual operations that add or modify the event data document. Each applicable site returns its possibly updated event data document to the coordinator. The coordinator then merges all the event data documents to create a new version of the event data document to be sent out to applicable sites in the next round. During the data merging process, the coordinator identifies and separates event data information into old and new. It also detects inconsistencies and determines if any cyclic rules will be processed in the next round. Details of event data aggregation, detecting inconsistencies and avoiding cyclic rule execution will be presented in Chapter 6. At the beginning of every round of event data transmission and rule processing, the coordinator asks the host site for the applicable sites and sends the new version of event data document to them. There is one difference, however, in determining applicable sites as well as applicable rules and rule structures in the second and subsequent rounds. To determine whether a particular rule or rule structure is applicable in a round other than the first one, we also employ the condition that at least one of round. This is to prevent the processing of the same set of rules and rule structures on the same event data. Once no more applicable sites can be determined, the process of event data transmission and rule processing terminates. All sites involved in this process would have received the final

PAGE 68

68 event data document that contains all the data that are relevant to an event occurrence. The data can be used by these organizations for further decision-support and problem-solving. Event-triggered Processing of Rules and Rule Structures in the EU-Rent Domain In this section, we use an example scenario of the EU-Rent application domain to explain how the general event and rule processing strategy described above can be applied. We shall also explain how a rule structure is decomposed and processed. The complete set of events, rules, and rule structures derived from the EU-Rent rule set is included in Appendix B. We have used our knowledge specification language to define EU-structures, convert them to code, and register them as web services. The total number of rules we obtained from [38] is 46, 29 of which are CAA rules, 13 of which are integrity constraint rules and 4 of which are derivation rules. There were also 9 rule structures discernible from the rule set. Each of these rules and rule structures took about 6-7 seconds to be converted, compiled, deployed and published as a web service on a Windows XP machine with an Intel Pentium 4 processor and 1 GB RAM. The major component of the total time required for web service creation is in the compilation, deployment, and publication activities. The time taken to generate the appropriate service interface, implementation and configuration files has little impact on the total time. As a result, the web service creation time is more or less independent of the rule type. To demonstrate the event-triggered processing of distributed rules and rule structures, we use the following scenario (Figure 5-2). A customer approaches a local branch Branch1 with the request for a car rental. Branch1 is unable to satisfy his/her request. It posts an event Reservation Request and the event data in XML format is sent to all subscribing branches. The event data contains information about the customer and the type of car desired. Assume that Branch2, Branch5 and Branch8 are branches that have the applicable rule structure shown in detail for

PAGE 69

69 Branch5. As all the EU-Rent branches have similar rules, a similar rule structure is defined at each one. Details of the rules that are used in the rule structure are given in Appendix B. The rule structure checks if the driver of the car satisfies some required constraints by means of the rule driverCheck. In parallel, a check is made to ensure that the branch will not exceed its capacity by approving the request through the rule capacityCheck. If no group or model is specifienoGroupAndModelSpecified. A suitable car is determined based on the group or model through the CAA rule assignCarOnModelOrGroupscheme, or a suitable car cannot be found, an upgrade is given through the CAA rule giveUpgrade. If even then, a suitable car cannot be found, availability of a car from the next considered, or availability of a car scheduled to be returned earlier on the pick-up day is determined. The event data file contains new data resulting from the application of these rules at Branch2. This data is returned to Branch1 (the coordinating site of the event). Branch1 receives the updated event data from Branch2, Branch5, and Branch8 (not shown). Branch1 then merges this data and sends out the new version of the event data to all branches (not shown) because there may be rules and rules structures that are applicable to the new version of event data. In our scenario, we assume that there are no new applicable rules. Branch1 can then apply a local rule to select the branch among the three which preferably has the requested make and model available and is also the closest. Also, all other branches receive the final version of the event data, which can be used for their local decision-support and problem-solving. The implemented prototype system runs on multiple computers.

PAGE 70

70 Decomposition of Rule Structure We use the same scenario to present the technique used to decompose a rule structure into substructures for processing. A rule structure is a directed graph, in which rules (nodes) can be interconnected by link, split, and-join and or-join constructs (edges). An XML document however, organizes its constituent elements in a tree structure. Each of the four rule structure constructs, if considered independently, can be represented using a tree (by means of the predecessor-successor relationships), but the combination of these constructs that forms a particular rule structure may not always be a tree (Figure 5-2). It is worth noting that, if we break a rule structure into substructures, where each represents a single structural relationship between two or more rules, each substructure is a tree, and can now be represented by using XML. This does result in the same rule being referred at a maximum of two times, first when describing the relationship where this rule is a successor, and the next when describing the relationship where this rule is a predecessor. Rules that have no predecessors or successors still appear only once in the representation. The directed edges of a rule structure specify the order of execution of the constituent rules. This order is reflected in how the XML elements representing each substructure are ordered in the rule structure document. For a given rule structure, substructures are generated as we move from the top to the bottom of the graph. At any level, we follow a left to right ordering, thus if substructure S1 is to the left of substructure S2, S1 will be generated first. Taking the rule structure from Figure 5-2 as an example, the first substructure to be generated would be for the link construct with getBranch as the predecessor rule and capacityCheck as the successor rule. The second substructure generated would be for the and-join with driverCheck and capacityCheck as the predecessor rules and noGroupAndModelSpecified as the successor rule. After two link structures linking noGroupAndModelSpecified with assignCarOnModelOrGroup,

PAGE 71

71 and assignCarOnModelOrGroup with giveUpgrade, the final substructure would be the split construct with giveUpgrade as the predecessor rule and allocateNextDay, bumpedUpgrade, downgrade, assignScheduledCar as the successor rules. The above scenario takes about a total of 3 seconds for the requesting branch to send out its event data file to remote branches and for the remote branches to invoke the applicable rules and send the updated event data file back to the requesting branch. If we revisit the algorithm for converting a rule structure to a web service (Figure 4-6), we see that substructures are processed in the order specified in the rule structure document, which reflects the actual order of the rule structure. The program statements for each substructure are generated by the respective handler routines. Each routine checks if the toBeExecuted array contains the predecessor rule(s). This check is important since the predecessor rule(s) for a particular substructure might be the successor rule(s) of an earlier substructure, and thus may already be either executed or at least in the pipeline. This check in combination with the proper ordering of the substructures ensures that rules are always processed in the correct order during the actual execution of the rule structure. Decomposing a complicated rule structure into simpler substructures also facilitates the maintenance of the structure. Inserting a new relationship into an existing rule structure document requires only creating the appropriate substructure and inserting it into the correct position in the document. Similarly, deleting and modifying a structural relationship need to address only the substructure that represents that relationship, without affecting other parts of the rule structure document.

PAGE 72

72 Event-triggered Processing of Rules and Rule Structure in the NPDN Domain In this section, we provide more details about the NPDN application domain and use an example scenario from this domain to describe how the general event and rule processing strategy is applied. The key organizations in the NPDN environment and their functions [50] are given below: NPDN Triage Lab: The state facility designated to receive and examine suspect samples. This lab is often associated with the state Land Grant University, but in some states is part of the state department of agriculture. NPDN Regional Hub Lab: The key coordinating lab for an NPDN region. Currently, these labs are located at the California Department of Food and Agriculture (WPDN), Kansas State University Department of Plant Pathology (GPDN), Cornell University Department of Plant Pathology (NEPDN), Michigan State University Department of Plant Pathology (NCPDN), and University of Florida Department of Plant Pathology (SPDN). These labs provide coordination, training, funding, and surge capacity support to the NPDN triage labs within their region and occasionally to other regions. APHIS-PPQ: Animal and Plant Health Inspection Service, Plant Protection and Quarantine. Administered by the USDA. SPRO: State Plant Regulatory Official. Highest ranking state plant regulatory official. The SPRO is employed by the state department of agriculture. SPHD: APHIS-PPQ State Plant Health Director. Highest ranking federal plant regulatory official in a state. APHIS-PPQ-NIS: National Identification Service. The USDA-authorized lab for diagnosing plant diseases (fungal and viral). APHIS-PPQ-CPHST: Center for Plant Health, Science and Technology. The USDA-authorized lab for conducting DNA diagnosis (PCR) and bacterial diagnosis of plant diseases. APHIS-PPQ Confirming Diagnosis Designate: The person authorized to make a confirming diagnosis for a high risk pest. This diagnosis must withstand legal scrutiny if challenged in court. This lab may be one of the APHIS-PPQ labs (NIS or CPHST) in Beltsville, MD or may be one that has been approved or provisionally approved by APHIS-PPQ or APHIS-CPHST. Our study of the procedures used in this domain for diagnosis of plant samples has revealed the need for the NPDN organizations to communicate with each other effectively and in

PAGE 73

73 a timely manner. We provide the solution approach of capturing the procedures as rules and rule structures to be triggered by suitable events. The complete set of events, rules, rule structures, triggers and operations along with their descriptions, the data items they need or provide, as obtained from the NPDN SOP draft [50] are included in Appendix C. Distributed Rule and Rule Structure Processing in the NPDN domain and rule structures, convert them to code, and register them as web services. The total number of rules we obtained from [40] is 27, all of which are CAA rules. We have identified 10 different events and 5 rule structures. The time taken to publish the rules and rules structures as web services is similar to that in the EU-Rent domain. As mentioned earlier, collaborating sites can also share automated application system operations and manual operations. System operations are defined by collaborating organizations and published as web services for use in rules and application systems. Manual operations are manual tasks performed by people of these organizations. Each manual operation is defined in terms of who should be notified and instructed to perform the operation, what means of notification should be used (e.g., by email, short message to a cell phone, and/or instruction displayed on a monitor) and what data should be provided to the system when the task has been carried out. When a manual operation is activated by a rule, the system would notify the appropriate person using the specified means of notification, and instruct the person to 1) perform the manual operation, 2) inform the system when the operation has been carried out, and 3) input the data produced by the operation. Both automated and manual operations can be referenced in and activated by rules. We use a scenario (Figure 5-3) to demonstrate the distributed event and rule processing technique in the NPDN domain. The scenario begins with the NPDN Triage Lab receiving a

PAGE 74

74 suspect sample from the State Department of Agriculture, APHIS-PPQ, or university staff. The NPDN Triage Lab staff that receives the sahas information about the sample, such as the genus of the host plant, the date the sample was collected, etc. This event data is encapsulated in an XML document and processed by the rule structure shown in the figure. The Triage Lab conducts its own preliminary diagnosis, changes NTLR1 in the figure). It notifies appropriate personnel such as the APHIS-PPQ CDD, the NPDN Regional Hub Lab, the state of origin SPHD and SPRO, and ships portions of the sample to the NPDN Regional Hub Lab and the APHIS-PPQ CDD (Rules NTLR2-NTLR4 in the figure). This results in the event the APHIS-PPQ CDD and the NPDN Regional Hub Lab. The NPDN Regional Hub Lab may also employ a local expert to help with the diagnosis process, in addition to conducting its own diagnosis (Rules NHLR1, and NHLR2 in the figure). In addition, it is also responsible for contacting some key personnel like the NPDN Regional Director (Rule NHLR3 in the figure). Optionally, it may send the sample to the APHIS-PPQ CDD (Rule NHLR4 in the figure). The APHIS-PPQ CDD conducts the confirming diagnosis and contacts the NPDN Triage Lab as well as the SPHD with these results (Rules ACDDR1-ACDDR3 contain only some portion of the sample information. As diagnosis proceeds along the different organization, more and more information about the sample is obtained. The final diagnosis results represent a new piece of information which contains the confirmed host and pest information about the sample.

PAGE 75

75 The rule structure at the NPDN Triage Lab takes about a total of 14 seconds to execute. The rule structures at the APHIS Lab takes about a total of 101 seconds to execute and the one at the NPDN Regional Hub Lab takes about a total of 149 seconds. This discrepancy is mainly due to the varied number of automated and manual operations. The actual time required for the manual operations was not measured, as it will vary greatly in every situation; however the time required to send the notification to the concerned individual was measured. Figure 5-1. ETKnet system architecture EventServer RuleServer UI Tool DB EventServer RuleServer UI Tool DB CS1 CSn EventServer RuleServer UI Tool DB WSRegistry OMS ODB Local Connection Remote Connection CS Collaborating Site DB Database UI Tool User Interface Tool WS registry Web Service Registry OMS Ontology Management System ODB Ontology Database HOST

PAGE 76

76 Figure 5-2. Event and rule processing in the EU-Rent domain Branch1 Branch2 Branch5 Branch8 getBranch capacityCheck driverCheck noGroupAndModelSpecified AND assignCarOnModelOrGroup giveUpgrade assignScheduledCar downgrade bum p edUpgrade allocateNextDay Event: Reservation Request (Customer.*, Car.*)

PAGE 77

77 Figure 5-3. Event and rule processing in the NPDN domain NPDN Triage Lab Event: Suspect Sample Received (npdn.Sample Sample.*) NTLR1 NTLR3 NTLR2 NTLR4 NPDN Regional Hub Lab Event: Pr esumptive Positive Sample Received (npdn.Sample Sample.*) NHLR1 NHLR2 NHLR4 NHLR3 AND APHIS PPQ CDD Event: Presumptive Positive Sample Received (npdn.Sample Sample.*, npdn.Shipment Shipment.*) ACDDR1 ACDDR3 ACDDR2

PAGE 78

78 CHAPTER 6 RESEARCH ISSUES Event Data Aggregation The site of an event occurrence is termed as the coordinating site or coordinator for the event occurrence. During successive rounds of event and rule processing, the event data are wrapped in an XML document (termed as the parent document) and sent to explicit and implicit subscriber sites. Each collaborating site may add to or modify the event data items. These data items are returned to the coordinator as updated event data documents (child documents). The coordinator is responsible for aggregating the parent and child documents before starting the next round of processing. At the end of each round of processing, the coordinator compares the contents of the parent document with the child documents as follows. For each entity occurrence in the parent then systematically goes through each of the child documents. For each child entity instance that has a corresponding parent entity instance, the coordinator updates the parent instance with the updated values shown in the child instance and adds to the event data structure the new attributes and values obtained from the child instance. Any new entity instance in a child document that is not in the parent document is also added to the event data structure. When all child documents have been examined, the event data structure contains the most current states of all the entities in the parent and child documents. Its contents are written into an XML document. If there are explicit triggers that link an event to rules and/or rule structures, or if there are rules or rule structures that refer to the updated event data or new event data in their input data specifications and all of the rule or rule structure input is a subset of the event data, a new round of event and rule processing would start by sending the XML document to the applicable sites. This process

PAGE 79

79 of event notification, event data transmission and aggregation, and rule and rule structure processing terminates when no site has a rule or rule structure applicable to the last version of event data. Event data aggregation is achieved by viewing the event data document as the union of two disjoint sets, Ei and Di, for round i. Ei is the portion of the event data file sent in round (i-1) that was not updated, if i i = 0, Ei is empty. Di is the portion of the event data file which includes updates and/or additions from round (i-1), if i i = 0, Di is the initial event data that was made available from the event occurrence. Algorithm 1, presented in Figure 6-1 explains this process in greater detail. In Figure 6-1, ni is the number of applicable sites in round i of event processing. Below we give a correctness proof for the algorithm. Claim: Algorithm 1 ensures that for every round i, i Di contains the data items that were added or updated in round i-1 and Ei contains those data items that were not (i.e. old data). Let Uis denote the set of updates from site s in round i Let Ais denote the set of additions from site s in round i Let ds denote the data item being considered from site s Proof: (By induction) Basis step: For round 0: E0 D0 = initial event data This is correct since all data provided as a result of the event posting is considered new. At this point there is no old data. Induction step: Assume Ei-1 and Di-1 are correctly defined For round i: Ei = Ei-1 U Di-1, Di For every data item ds, there are three possible cases,

PAGE 80

80 (1) ds is unchanged from the previous round, and thus is part of the old data. Since ds was present in the previous round, ds Ei-1 U Di-1, and hence ds Ei. (2) ds pdated, i.e. ds Uis. Algorithm 1 removes ds from Ei and adds it to Di. This is correct since ds now has an updated value. (3) ds is a new data item, not present in the previous round, i.e. ds Ais. Algorithm 1 adds ds to Di, which is correct, since ds is a data item that was added. Also, ds Ei Conclusion: Thus, repeating steps 1-3 for every data item ds will ensure that all the updated/added data items are stored in Di, and those that were not are stored in Ei. Hence proved. Event Data Inconsistencies and Contradictions Rules and rule structures capture the knowledge of collaborating organizations. This knowledge reflects the opinions and experience of policy makers and experts in the ons to differ. When these differing opinions are processed as knowledge rules, inconsistencies and/or contradictions may arise. Knowledge rules (converted to web services) process the data items in the event data document and as a result may generate new data items (additions) or update the existing data items (updates). The event data documents of collaborating sites are returned to the coordinator. When the coordinator aggregates all the event data documents, it may find that inconsistent data values are given to an attribute of the same entity. A special case of inconsistency arises when the attribute is of the Boolean type and contradictory truth values are returned. From here on, we shall use the term conflict to mean either an inconsistency or a contradiction. When a conflict is detected, we propose to resolve it in the following manner. Collaborating organizations can decide to adopt a global resolution rule to determine the value of a particular data item in case of a conflict (e.g., by taking the minimum, maximum or average of conflicting values). However, if there is no such global resolution rule for a data item, one

PAGE 81

81 approach is to require all sites to attach their identities with the values they produce and the coordinator to transmit event data with site ids in the next round of event and rule processing. When a collaborating site receives conflicting values tagged with site ids, it can adopt a local resolution policy to decide which site it trusts the most and adopt the value supplied by that site. In the absence of both global and local resolution policies, rules and sites that generated the conflict values can be recorded and appropriate organizations can be informed to resolve the conflict by eliminating or modifying some rule(s). The algorithm shown in Figure 6-1 describes the detection and the resolution mechanism employed by the coordinator. Let (Ei + Di) be the event data file sent out in round i. Uis denotes the updates sent to the coordinator by site s for round i, and Ais denotes the additions sent to the coordinator by site s for round i. Let ni be the number of sites that were applicable for round i. Let us and as denote the value of an update or addition respectively tagged with the source site s. Let denote the empty set. Let UC be the set of conflicting data items due to updates and let AC be the set of conflicting data items due to additions. The algorithm looks at each data item sent in from a site s, and determines if there is a conflict for that data item, by checking if it was already updated by some other site If so, it applies the global resolution policy if one exists, and replaces the conflicting value with the resolved one. If not, it tags a particular value of the data item with its source and includes it in the event data document to be sent out. As each data item for a particular site is examined once, the algorithm has a complexity of the order O(minm), where mi is the number of applicable sites for a particular round i, and nm is the number of data items present in the event data document returned by site m. So, on average, the complexity can be assumed to be O(m'n'), where m', and

PAGE 82

82 n' are the mean values for a particular event processing scenario. Below we give a correctness proof for the algorithm. Claim: Algorithm 1 identifies a conflict iff it is present Let Uis denote the set of updates from site s in round i Let UC denote the set of conflicting data items due to updates Let Ais denote the set of additions from site s in round i Let AC denote the set of conflicting data items due to additions Let ds denote the data item being considered from site s Proof: For every data item ds considered in the aggregation phase, (1) if ds Uis and ds Di, the algorithm compares the value of ds, denoted by ds.v with the one stored in Di, denoted by ds(Di).v. If these values are not equal, a conflict due to update is registered, and ds is added to UC. (2) if ds Ais and ds Di, the algorithm compares the value of ds with the one stored in Di. If these values are not equal, a conflict due to addition is registered, and ds is added to AC. So, the algorithm identifies a conflict only in case of multiple values being present for the same data item, and thus detects a true conflict. Hence proved. Avoiding Cyclic Rule Execution Distributed knowledge rules and rule structures are independently and dynamically defined by collaborating organizations. During event and rule processing, each applicable collaborating site processes the relevant rules and returns the data items produced by these rules. This may trigger some other rules in the next round of processing. It is possible that a set of distributed rules may get locked into a cycle. rules has been widely studied [7, 19, 37, 42]. All of the work in this area addresses the issue of static determination of rule termination. The majority of these works use the concept of a triggering

PAGE 83

83 graph [17]. In [2], a basic static rule termination algorithm is described. This analysis does not [5, 42] do take into account this consideration. Also, in most cases, the rule set is globally known or a global rule set is assumed to be available for rule termination analysis [6]. The work in [19] does not assume the knowledge of a global rule set. However, all of these methods address static termination analysis. In our eventand rule-based system (ETKnet), knowledge rules are dynamic. Trule set is constantly changing. Multiple rules can be defined, updated, suspended or reactivated. Thus, the above approaches become inapplicable. The existing approaches consider termination of active rules in the active database paradigm. In this environment, active rules update a database relation on occurrence of a triggering event. These rules are usually expressed as ECA rules. The condition expression is a query on the current database state, and is true if the answer relation is non-empty. In ETKnet, we do not directly operate on a global database, however, the current event data document can be at build-time, they cannot consider the run-time values of data items. Thus, a build-time algorithm must always assume that the action in the triggered rule will get executed, and hence new data will be introduced as a result of the action. However, at run-time, a rule condition may not be satisfied, causing no execution of the action specified in the rule, making the above assumption false. As a result, in the ETKnet environment, use of static termination analysis can accurately determine termination, but not non-termination. For the above reasons, we resort to a run-time approach to guarantee termination of rule processing. We derive some concepts for rule termination from the theory on deadlock detection and deadlock avoidance in modern operating systems. Let us consider the concept of detection and

PAGE 84

84 recovery first. This approach allows a cycle to occur, detects it, and then deactivates some rule(s) to break the cycle. This is an acceptable approach to handle deadlocks since the deadlocked processes are stalled until the deadlock is broken. For distributed rule processing, however, if the rules locked in a cyclic processing are allowed to continue processing, the data values they produce may activate other rules, causing some non-idempotent operations to occur. Recovery from such a scenario is not always possible. As there is no guarantee that every cycle is self-contained and does not affect other rules, this approach is not desirable for rule termination. Rule termination can best be guaranteed by avoiding cycles altogether. Our avoidance strategy combines pre-computing possible rule cycles that can occur for every event with rule monitoring at runtime by the coordinating site. Thus, the coordinating site can make a runtime decision on whether or not a cycle exists. We explain the definition time process and runtime process below. All shared distributed knowledge rules are registered at the host site. Thus, the host site has full knowledge of the input and output specifications of each rule. When an event is registered at the host site, it determines the applicable rules based on the initial event data specification and their data value conditions). It then simulates the processing of that event. Starting with the set of rules that are applicable to the event data, the host site examines the output of these rules to determine those rules that will possibly become applicable in the next round of event processing. It keeps track of all executed rules in each round of event processing. For example, let us assume that during the processing of a particular event E, rules R1, R2, R3 will be executed in the first round, rules R4, R5, R6, R7, R8, R9, will be executed in the second, and rules R10, R11, R12 in the third round. The host will record the following information:

PAGE 85

85 R1, R2, R3 R4, R5, R6, R7, R of event processing, the host site determines that a rule Rc, that was executed in the previous round is applicable again in this round, it treats this as the beginning of a possible cycle. Rc is Rc, the host site looks at all rules executed in the previous round to determine the set that can provide any item iRc (an input item to Rc) as their output. Let us call this set, Rp, to denote the rules that can possibly trigger the execution of Rc. Each rule in this set is recorded, information thus has the following form: n V ri i=1 where each ri inRp, and V is the Boolean OR operator. For example, assume that in the third round of processing the same event E, R1 (with four input items a, b, c and d) is made applicable again due to the fact that rule R4 updates data item a, R7 updates data items a, b, and c, and R9 updates data items a and b. The expression R4 V R7 V R9 will be recorded for rule R1. As Rc was executed once earlier, an update on any one of its input items in a round of processing will result in the rule being applicable for the next round. Using the above example, execution of any of the rules R4, R7, and R9 will cause at least one of R1updated, thus making R1 applicable for processing in the next round. The host stores information about all cyclic rules until it determines that no new rules can be executed in the next round of processing. It is possible that multiple cycles for a single rule exist. In such cases, the host will

PAGE 86

86 calculate the rule expression for Rc for the current round, and use this to update any previous rule expressions computed for Rc. This rule termination information is stored for every registered event. The algorithm for the above process is described in Figure 6-2. The process to compute the rule expression is described in Figure 6-3. The function in Figure 6-3 iterates over all rules over all input items i in rc. Step 4 in the function examines each output item of rp to check if i is contained in rp.output, and also examines each rule in Rexpr to check that rp is not already included in Rexpr. This step takes a total of (r+n) time, where r is the total number of rules in Rexpr, which is at most the total number of defined rules, and n is the number of output items in rp. Assuming each rule has n input and output items, the complexity of the function computeCyclicExpression is of the order O(rn(r+n)). This is the most expensive calculation in Algorithm 2. The algorithm iterates over all rules in Rp, which in the worst case be all of the defined global rules. This is repeated until there are applicable rules that have not been examined. In the worst case, each iteration of the while loop just adds a single rule, and all defined rules are applicable to the event, making the worst-case complexity of the order O(r3n(r+n)). Claim: In round i, The rule expression expr computed for a possibly cyclic rule rc using function 1 is necessary and sufficient to predict whether or not the rule will be re-executed in round i+1. Let rc denote the possibly cyclic rule being considered Let irc denote a single input data item for rc Proof: After processing a given round i, the sets Ei and Di contain all the old and new/updated data items respectively. Event data items are never deleted, they are only added or they move between Ei and Di. When determining whether rc will be re-executed in i+1, we know that rc has

PAGE 87

87 already been executed in some previous round p, p < i. Thus, all of the input data items irc are already present in (Ei U Di). An update on any input data item irc will make rc applicable for processing in round i+1. Examining only the previous round is sufficient as the rules executed in all rounds q, q < i either do not contribute to rcnt rule expression for rc. Function 1 examines each rule executed in round i those rules Rexpr that contribute to rcr, r Rp is executed, the rule expression becomes true and rule rc becomes applicable in round i+1. Similarly, if the rule expression is determined to be true, it implies that at least one r, r Rp has been executed. As the rule expression captures exactly this and only this property of determining when any input item irc is updated, the rule expression is necessary and sufficient to predict whether or not the rule will be re-executed in round i+1. When a new global rule Rnew is added, it is registered at the host site. The host must determine what events can cause this rule to be processed, and accordingly update the rule processing path, similar to that shown in (1), and any information for cyclic rules, similar to that shown in (2). To achieve this, the host first determines if any event can directly provide the input for Rnew, and records this information. Next, for each input item, iRnew, the host determines the rules that can provide input item iRnew to be Ri. Finally, such expressions from each input item are Rnew to be processed, and has the following form: m ni V r ij i=1 j=1

PAGE 88

88 where im are the m input items of Rnew, rijjni Ri, are the ni rules that provide can provide item i as input to Rnew, is the Boolean AND operator, and V is the Boolean OR operator. Once the host computes the above expression, it examines all processing paths stored for every event, and checks if this rule expression satisfies any of them. If so, the processing of this event may likely include Rnew. Once all such affected events are determined, the host goes through the algorithm shown in Figure 6-2 again to determine the processing and cyclic paths for each event. The algorithm for the above process is shown in Figure 6-4. The most expensive step in Algorithm 3 is step 22, where Algorithm 2 is invoked for every affected event. In the worst case, all of the e events can be affected by a rule, and hence the complexity of the algorithm is of the order O(er3n(r+n)), where e is the number of registered events. At runtime, when an event occurs at a collaborating site, this site, now called the coordinator, downloads the cyclic path information for the event from the host site. Every applicable collaborating site needs to return the rules that were executed in a given round of event and rule processing back to the coordinator. The coordinator then examines the rules that were actually executed and compares it with the cyclic path information to determine if the next round of event and rule processing will lead to a rule cycle. If so, the site where the cyclic rule will be executed is asked to deactivate the rule. For example, assume that the event E with the possible rule processing scenario mentioned in (1) occurred and R1 and R3 were executed in round 1. In round 2, assume that only R5 was executed. With this information, the coordinator determines that the expression shown in (3) is not satisfied. If, on the other hand, during the processing of round 2, rule R4 was also executed, the coordinator would know that R1 will be

PAGE 89

89 executed in the third round causing a cycle. Thus, R1 is deactivated for that particular round to avoid the cycle. Claim: Any rule processing initiated for a given event terminates. Proof: For a given event, there are three processing scenarios: (1) The host determines that the rules processed for this event can never get locked into a cycle. Thus, event processing eventually terminates. (2) The host determines possible cyclic paths of execution. In every round, the coordinator for an event examines these possibly cyclic paths and determines whether or not a particular rule will be executed in the following round. If a cyclic rule is predicted to execute in the following round, it is deactivated for that round. Thus, cycles are avoided and event processing eventually terminates. (3) During event processing, one or more new global rules that can cause cycles are introduced into the system. Whenever rules are defined at a collaborating site, they are inactive until registered with the host site. During registration, the host site computes the possible cyclic paths as explained in Algorithm 3. Thus, when the host registration is completed, possible cyclic paths for this rule have been updated. The rule now becomes active and can take part in the event processing. The coordinator requests cyclic path information at the beginning of each round of event processing. Thus, in the next round after the rule registration, the coordinator receives the updated possible cyclic paths. The new rule can be executed at most once before the coordinator becomes aware of the possible cyclic paths. From now on, this becomes similar to case 2, and event processing eventually terminates. The above approach is better than static termination analysis methods because it takes into consideration the fact that rules are dynamically introduced and updated, and also takes runtime data values into account when determining likely rule cycles. However, the general problem of rule termination is undecidable [4], and so the best we can do is to take a conservative approach and treat every second occurrence of a rule in a given event processing scenario as the beginning of a cycle. Since correctness is more important than performance, the proposed algorithms represent a useful step towards achieving rule termination. As the performance data (Table 6-1) shows, a huge percentage of the build time process is spent in pre-computing possible cyclic paths, even as high as over 90%. However, the run time overhead is less than 1% at all times. This is acceptable since the build-time performance drop is a one-time occurrence.

PAGE 90

90 It is possible to have self-terminating rule cycles, which are not handled by our approach. To understand this, consider the situation where we have the following rule cycle, R1 R2 R3 R1. It is possible that after a few rounds, the output item produced by R3 does not satisfy the input condition of rule R1, and hence it is no longer executed, i.e. the cycle has been broken. It is unreasonable to expect that the system should predict such self-terminating cycles. A better approach would be to enable operation-level sharing and powerful looping constructs, so that a -the scope of this work. Table 6-1. Build time and run time overhead of the cyclic rule avoidance strategy Number of rules (% cyclic) Build time overhead (total) ms Run time overhead (total) ms 10 (10) 121 (155) 16 (4890) 10 (50) 153 (165) 15 (4828) 10 (90) 189 (196) 15 (474 5) 20 (10) 123 (159) 21 (5170) 20 (50) 171 (212) 15 (5216) 20 (90) 212 (250) 18 (5240) 50 (10) 137 (178) 15 (11941) 50 (90) 541 (593) 15 (11648) 100 (10) 212 (237) 15 (22268) 100 (50) 674 (744) 18 (22030) 100 (90) 1514 (2229) 17 (22733) 250 (10) 1 25 (515) 15 (56371) 250 (50) 139 (3498) 29 (56804) 250 (90) 139 (8583) 40 (57300)

PAGE 91

91 Figure 6-1. Algorithm to aggregate event data and identify conflicts Algorithm 1 aggregateAndIdenti fyConflicts (1) E 0 = D 0 = initial event data, U A (2) i = 1; (3) do { (4) U A (5) determine applicable sites and send event data for rule processing ( 6 ) E i = E i 1 U D i D i UC AC ; ( 7 ) for s from 1 to n i ( 8 ) if U is ( 9 ) for each d s U is ( 10 ) if ( d s D i d s v d s (D i ) v ) UC = UC + d s ; (11) end if (1 2 ) if ( d s D i ) D i = D i U d s ; (13) E i = E i d s ; (14) end if (1 5 ) end for (1 6 ) end if (1 7 ) if A is (1 8 ) for each d s A is (1 9 ) if ( d s D i d s v d s (D i ) v ) AC = AC + d s ; (20) end if ( 21 ) if ( d s D i ) D i = D i U d s ; (22) end if ( 23 ) end for (2 4 ) end if (2 5) end for (26) D i = D i ( UC U AC ) ; (2 7 ) for each u UC (2 8 ) if (global_res_ policy( u ) = true) D i = D i U resolve( u ) ; (2 9 ) else D i = D i U u s ; ( 30 ) end for ( 31 ) for each a AC ( 32 ) if (global_res_policy(a) = true) D i = D i U resolve( a ) ; (3 3 ) else D i = D i U a s ; (3 4 ) end for (3 5 ) U = U U U is ; (3 6 ) A = A U A is ; (3 7 ) i ++ ; (38) } while ( U U A );

PAGE 92

92 Figure 6-2. Algorithm to find possible cyclic paths on registration of an event Algorithm 2 findCyclicPaths (1) D = set of event data, ND = R e = R 0 = (2) R p = all rules r s.t. r .input D (3) initialize p ath to a blank string; ( 4 ) for each r R p (5) R e = R e U r ; (6) R 0 = R 0 U r ; (7) ND = ND U r .output ( 8 ) end for (9) f or each r R 0 (10) add r to path (11) end for path ; (13) R p = ; (14) i = 1; (1 5 ) do (16) R i = ; (17) R p = all rules r s.t. r .input ( D U ND ) and r .input not all in D (18 ) D = ND U D ND = (1 9 ) for each r R p ( 20 ) if r R e (21) computeCyclicExpression( r R i 1 ); ( 22 ) else (23) R e = R e U r ; (24) R i = R i U r ; (25) ND = ND U r .output ; (2 6 ) end else (2 7 ) end for (28) i ++; (29) for each r R i (30) add r to path (31) end for path ; ( 33 ) while R p

PAGE 93

93 Figure 6-3. Algorithm to compute the rule expression for a possibly cyclic rule Figure 6-4. Algorithm to update possible cyclic paths on addition of a global rule Function: computeCyclicExpression( r c R prevRound ) (1) R expr (2) for each i r c .input (3) for each rule r p R prevR ound (4) if i r p r p R expr (5) R expr = R expr U r p ; (6) end if (7) end for (8) end for (9) init ialize expr to a blank string; (10) for each rule r R expr (11) add r to expr using the Boolean OR operator ; (12) end for (13) store expr for cyclic rule r c ; Algorithm 3 updateCyclicPathsForRule (1) r new = newly added globa l rule; (2) R = set of defined global rules; (3) for each input item i r new .input (4) R i (5) for each rule r R (6) if i r .output R i = R i U r ; (7) end if (8) end for (9) expr R i = Boolean OR expression linking rules in R i ; (10) end for (11) exprR new = Boolean AND expression linking all exprR i ; (12) E = set of defined events; (13) AE (14) for each event e E (15) if r new .input e .data AE = AE U e ; (16) else (17) path = execution path for this event; (18) if exprR new is satisfied by path AE = AE U e ; (19) end else (20) end for (21) for each event e AE (22) invoke algorithm findCyclicPaths for e ; (23) end for

PAGE 94

94 CHAPTER 7 SUMMARY, CONTRIBUTIONS, AND FURTHER RESEARCH In this dissertation, we have presented the basic problem of resource sharing among collaborating organizations. Complex problems faced by government organizations and business enterprises can be more effectively solved if organizations that form a collaborative federation are given the following facilities, system and infrastructure to effectively and efficiently define and share not only data, but also knowledge and application operations: A knowledge specification language and user interface tools for defining events of common interests, knowledge rules to capture organizational and inter-organizational policies, regulations and constraints, rule structures to model processes and operational procedures, triggers to link distributed events with rules and rule structures, and sharable application operations (automated and manual) to perform the needed tasks. A distributed, eventand rule-based system capable of delivering and aggregating data associated with event occurrences, and triggering the processing of applicable knowledge rules, rule structures, and application system operations (automated and manual). A web service-based infrastructure to achieve the uniform processing and interoperation of knowledge rules of different types and application (automated and manual) operations. In this dissertation, we have presented our idea of managing dynamic event data and sharing multi-faceted knowledge and application operations among collaborating organizations. Different aspects of knowledge are specified in three different types of rules and rule structures. When an event of interest to a federation occurs, the initial event data serve as input to applicable rules and rule structures. These rules and rules structures may add to or modify the event data, and activate application operations, which may also add to or modify the event data. The new event data may make some other rules and rule structures applicable. Thus, multiple rounds of event data transmission and aggregation, and rule and rule structure processing would be carried out by the system until all the collaborating organizations have processed their applicable rules and rule structures and received all the data that are relevant to the event occurrence. Techniques and algorithms for the distributed processing and interoperation of events, rules, rule structures,

PAGE 95

95 triggers and application operations for supporting decision-making and problem-solving are the main focuses of this research. The approach taken for achieving their interoperation is to translate rules and rule structures into code and wrap them as web services for their discovery, invocation and interoperation in a web service infrastructure. A knowledge specification language, and the architecture and implementation of an eventand rule-based system have been described. We have also discussed the research issues of event data aggregation, detecting event data inconsistencies, and avoiding cyclic rule execution and presented our solution approaches for them. The specific contributions of this work are as follows: We have developed an XML-based knowledge specification language for organizations to specify their knowledge in terms of three types of rules and rule structures. As yet, there exists no standard markup language which allows the specification of all three types of knowledge rules. Our knowledge specification language integrates the syntax of each different rule type and is a step towards achieving a markup language capable of capturing multifaceted knowledge. We have developed algorithms for converting different types of rules to web services and the strategy for processing a rule structure to demonstrate the interoperation of heterogeneous rules. Instead of using three different types of rule engines to process the corresponding type of rule, we convert rules to code and wrap them as web services. This is a compilation approach which is more efficient than the interpretive rule engine approach. Also, conversion to a web service exposes each rule in a uniform manner making it more open to interoperability. We have researched techniques for managing dynamic event data and processing distributed knowledge rules, rule structures and application operations. Any collaborating site can be a potential event provider. Each site should thus have the capability of coordinating a particular event occurrence. This is achieved by developing a peer-to-peer server system rather than a client-server system. We have developed a distributed eventand rule-based system to achieve inter-organizational event data and knowledge and operation sharing. Business or knowledge rules exposed as web services lend themselves easily to sharing. We have developed and implemented algorithms for aggregating distributed event data, avoiding non-terminating processing of cyclic rules as well as techniques for handling inconsistent and contradictory data introduced by different organizations.

PAGE 96

96 We have applied the knowledge specification language, the distributed, eventand rule-based system and the web service infrastructure in two application domains (e-business and agriculture homeland security) to demonstrate their utilities to achieve resource sharing among collaborating organizations. Through this R&D work, we have laid the foundation of a distributed knowledge sharing system. Further work needs to be carried out to make the system deployable in real world environments. For example, when different organizations interact, there is always the issue of semantic heterogeneity in the language terms used to define data, events, rules and operations. Thus, there needs to be an ontology and an ontology management system to reason over the underlying concepts of these terms, and resolve their semantic discrepancies. Also, our rule language captures a very basic form of the CAA rules. The action and alternative action clauses complex structures of operations found in workflows. An event occurrence marks the beginning of a new transaction. It triggers the processing of rules, rule structures and application operations. The applicability of ACID properties of transaction in this event-triggered rule processing environment needs to be examined, and techniques of transaction management need to be investigated. Trust and security management in a collaborative environment is also an important topic of further research.

PAGE 97

97 APPENDIX A XML SCHEMA DOCUMENTS RuleBase.xsd

PAGE 98

98


PAGE 99

99


PAGE 100

100


PAGE 101

101


PAGE 102

102

PAGE 103

103

PAGE 104

104

PAGE 105

105


PAGE 106

106
RuleStruc.xsd

PAGE 107

107


PAGE 108

108
EventData.xsd

PAGE 109

109
Events.xsd

PAGE 110

110
Operations.xsd

PAGE 111

111


PAGE 112

112


PAGE 113

113 APPENDIX B EVENTS AND RULES IN THE EU-RENT DOMAIN Description of entities used the screen when a user logs in. Customer: custID of type integer licenseExpiry of type date insured of type boolean blacklisted of type Boolean age of type integer rented of type boolean points of type integer oneYearLicenseHeld of type Boolean numRented of type integer numRes ervations of type integer numYearlyRentals of type integer eligible of type Boolean pointsYear of type integer Car: carID of type integer rented of type boolean mechanicalCondition of type string emissionsLevelMet of type boolean owningBranch of type inte ger assigned of type boolean scheduled of type b oolean model of type string group of type string reserved of type boolean serviceDate of type date serviceMileage of type float threeMonthsServiceDate of type date needsService of type boolean scheduledDate o f type date mileage of type float year of type integer toBeSold of type boolean Rental: rentalID of type integer driverID of type integer group of type string model of type string startDate of type date endDate of type date numCars of type integer mode o f type string driverName of type string creditCardName of type string driverSigned of type b oolean addDriversSigned of type boolean extendedEndDate of type date driverOK of type boolean carOK of type boolean guarantee of type boolean dropOffBranch of type integer extension of type boolean mileage of type float oneWay of type boolean free of type boolean bookDate of type date Group: groupID of type string quota of type integer numRemainingCars of type integer Branch: branchID of type integer numReservation s of type integer capacity of type integer

PAGE 114

114 The EU-Rent rules used to derive the ETKnet rules and operations are also included. EU-Rent Rules EU-Rent Rule: Each driver authorized to drive the car during a rental must be over 25 and have held a license for at least one year. EU-Rent Rule: Each driver authorizelicense. EU-Rent Rule: Each driver authorized to drive the car during a rental must be insured to the level required by the law of each country that may be visited during the rental. EU-Rent Rule: If the customer requesting the rental has been blacklisted, the rental must be refused. EU-Rent Rule: The driver who signs the rental agreement must not currently have an EU-Rent car on rental. The rules shown above can be implemented by the following constraint rule. Name: driverCheck if(Rental.driverID = = Cusomter.custID) then (Customer.licenseExpiry >= currentDate AND Customer.oneYearLicenseHeld == true AND Customer.insured == true AND Customer.blackListed == false AND Customer.age > 25 AND Customer.rented == false) Type: Integrity Constraint EU-Rent Rule: Rented cars must meet local legal requirements for mechanical condition and emissions for each country that may be visited during the rental. Name: mechanicalConditionAndEmissionCheck if(Car.rented = = true) Type: Integrity Constraint EU-Rent Rule: If a rental request does not specify a particular car group or model, the default is group A (the lowest-cost group). Name: noGroupAndModelSpecified if (Rental.group == null AND Rental.model == null) Type: Derivation Rule EU-Rent Rule: Reservations may be accepted only up to the capacity of the pick-up branch on the pickup day. Name: capacityCheck Branch.numReservations <= Branch.capacity Type: Integrity Constraint EU-Rent Rule: A customer may have multiple future reservations, but may have only one car at any time.

PAGE 115

115 Name: noMultipleCars if(Customer.numReservations > 1) then (Customer.numRented == 1) Type: Integrity Constraint EU-Rent Rule: Only cars that are physically present in EU-Rent branches may be assigned. The rule shown above can be implemented as the following four constraint rules Name: checkOwningBranch Car.owningBranch == Branch.branchID Type: Integrity Constraint Name: checkNotAssigned Car.assigned == false Type: Integrity Constraint Name: checkNotRented Car.rented == false Type: Integrity Constraint Name: checkNotScheduled Car.scheduled == false Type: Integrity Constraint EU-Rent Rule: If a specific model has been requested, a car of that model should be assigned if one is available. Otherwise, a car in the same group as the requested model should be assigned. EU-Rent Rule: If no specific model has been requested, any car in the requested group may be assigned. The rules shown above can be implemented using the following CAA rule. Name: assignCarOnModelOrGroup Condition: Car.model != null Action: 1. Car.group = getGroup(Car.model) 2. Car.carID = assignCarOnModel(Car.model, Car.group) Alternative Action: 1. Car.carID= assignCarOnGroup(Car.group) Type: CAA Rule Operation getGroup definition: Input: Car.model Output: Car.group Query the database for the group of the given model and return it.

PAGE 116

116 Operation assignCarOnModel definition: Input: Car.model, Car.group Output: Car.carID Query the database for a suitable car by model, if no results, query by group and return the carID. Operation assignCarOnModel definition: Input: Car.group Output: Car.carID Query the database for a suitable car by group and return the carID. EU-Rent Rule: After all assignments within a group have been made, 10% of the group quota for the branch (or all remaining cars in the group, whichever number is lower) must be reserved -in rentals. Surplus capacity may be used for upgrades. Name: reserveForWalkIn Condition: 0.1 Group.quota < Group.numRemainingCars Action: 1. reserveGroupByQuota(Group.groupID, Group.quota) Alternative Action: 1. reserveGroupByRemCars(Group.groupID, Group.numRemainingCars) Type: CAA Rule Operation reserveGroupByQuota definition: Input: Group.groupID, Group.quota Output: Find the first 0.1 Group.quota cars for Group.groupID that have not been assigned, scheduled, rented, or reserved, and reserve them. Operation reserveGroupByQuota definition: Input: Group.groupID, Group.numRemainingCars Output: Find all remaining cars for Group.groupID that have not been assigned, scheduled, rented, or reserved, and reserve them. EU-Rent Rule: If there are not sufficient cars in a group to meet demand, a one-group free upgrade may be given (i.e. a car of the next higher group may be assigned at the same rental rate) if there is capacity. EU-Rent Rule: Customers in the loyalty incentive scheme have priority for free upgrades. The two rules shown above can be implemented as the following CAA rule. Name: giveUpgrade Condition: Group.numRemainingCars == 0 OR Customer.points > 0 Action: 1. Car.carID = upgrade(Group.groupID, Group.numRemainingCars, Rental.rentalCharge, Customer.points) Alternative Action: None

PAGE 117

117 Type: CAA Rule Operation upgrade definition: Input: Group.groupID, Group.numRemainingCars, Rental.rentalCharge, Customer.points Output: Car.carID loyalty incentive scheme, please assign an upgrade. If the number of cars remaining in a group is zero, please assign an upgrade. When you have done so, please log on to the system and indicate output of the operation, which is entered through the user interface. EU-Rent Rule: -ins EU-Rent Rule: A car due for return the next day may be allocated, if there is a suitable car available and there is time to transfer it to the pick-up branch. The two rules shown above can be implemented as the following CAA rule. Name: allocateNextDay Condition: Car.carID == -1 Action: 1. Car.carID = assignFromReservedOrNextDay(Rental.startDate) Alternative Action: None Type: CAA Rule Operation assignFromReservedOrNextDay definition: Input: Rental.startDate Output: Car.carID -in or if a car due to be returned the next day can be allocated, provided there is time to prepare it for servicing. EU-Rent Rule: Name: bumpedUpgrade Condition: Car.carID == Action: 1. Car.carID = findHigherGroup(Group.groupID) Alternative Action: None Type: CAA Rule Operation findHigherGroup definition: Input: Group.groupID Output: Car.carID Find an available car from the next group and return the ID. EU-Rent Rule: A downgrade (a car of a lower group) may be made. Name: downgrade Condition: Car.carID ==

PAGE 118

118 Action: 1. Car.carID = findLowerGroup (Group.groupID) Alternative Action: None Type: CAA Rule Operation findLowerGroup definition: Input: Group.groupID Output: Car.carID Find an available car from the next lower group and return the ID. EU-Rent Rule: A car from another branch may be allocated, if there is a suitable car available and there is time to transfer it to the pick-up branch (This is best expressed as an event and rule processing scenario) Name: findCarInOtherBranch Condition: Car.carID == -1 Action: Alternative Action: None Type: CAA Rule Operation getCarID definition: EU-Rent Rule: A car scheduled for service may be used, provided that the rental would not take the mileage more than 10% over the normal mileage for the service. The rule show above is implemented as assignScheduledCar for a later similar EU-Rent rule EU-Rent Rule: Pick-up may have to be delayed until a car is returned and prepared Name: delayPickUp Condition: Car.carID == -1 Action: 1. Car.carID, Rental.startDate= findFirstAvailable() Alternative Action: None Type: CAA Rule Operation findFirstAvailable definition: Input: Output: Car.carID, Rental.startDate Find the first available car and return it. Return the date it will be available EU-Rent Rule: A car may have to be rented from a competitor Name: rentFromCompetitor Condition: Car.carID == -1 Action: 1. Car.carID = findFromCompetitor(Rental.startDate, Rental.endDate)

PAGE 119

119 Alternative Action: None Type: CAA Rule Operation findFromCompetitor definition: from a competitor. When you have done so, please log on to the system and indicate that ID as the output of the operation, which is entered through the user interface. EU-Rent Rule: The end date of the rental must be before any scheduled booking of the assigned car for maintenance or transfer. Name: checkCarNotScheduled Rental.endDate < Car.serviceDate Type: Integrity Constraint EU-Rent Rule: If there are several available cars of the model or group requested, the one with the lowest mileage should be allocated. Name: findAvailableCars Condition: Rental.numCars > 0 Action: 1. Car.carID = allocateWithLowestMileage(Car.model, Car.group) Alternative Action: None Type: CAA Rule Operation allocateWithLowestMileage definition: Input: Car.model, Car.group Output: Car.carID Find the number of available cars for the specified model or group and return its ID. EU-Rent Rule: The credit card used to guarantee a rental must belong to one of the authorized Name: authorizedDrivers Type: Integrity Constraint EU-Rent Rule: Before releasing the car, a credit reservation equivalent to the estimated rental cost must be made against the guaranteeing credit card. EU-Rent Rule: A customer may request a rental extension by phone the extension should be granted unless the car is scheduled for maintenance. The above two rules can be implemented as the following CAA rule. Name: beforeRelease

PAGE 120

120 Condition: None Action: 1. makeCardReservation(Rental.rentalCharge) 2. notifyExtensionProcedure(Rental.startDate, Rental.endDate) Alternative Action: None Type: CAA Rule Operation makeCardReservation definition: Input: Rental.rentalCharge Output: Operation notifyExtensionProcedure definition: Input: Rental.startDate, Rental.endDate Output: Rental.extendedEndDate EU-Rent Rule: The car must not be handed over to a driver who appears to be under the influence of alcohol or drugs. EU-Rent Rule: The driver must be physically able to drive the car safely must not be too tall, too short or too fat; if disabled, must be able to operate the controls. The above two rules can be implemented as the following CAA rule. Name: checkDriver Condition: None Action: 1. Rental.driverOK = checkDriverOK() Alternative Action: None Type: CAA Rule Operation checkDriverOK definition: Input: Output: Rental.driverOK does not appear to be under the influence of alcohol or drugs, and is physically able to drive the car safely must not be too tall, too short or too fat; if disabled, must be able to operate the controls. When you have done so, please log on to the system and indicate that operation if the driver seems OK as the output of the operation, which is entered through the user interface. EU-Rent Rule: The car must have been prepared cleaned, full tank of fuel, oil and water topped up, tires properly inflated. EU-Rent Rule: The car must have been checked for roadworthiness tire tread depth, brake pedal and hand brake lever travel, lights, exhaust leaks, windscreen wipers.

PAGE 121

121 EU-Rent Rule: Cars needing repairs (other than minor body scratches and dents) must not be used for rentals. The above three rules can be implemented as the following CAA rule. Name: checkCar Condition: None Action: 1. Rental.carOK = checkCarOK() Alternative Action: None Type: CAA Rule Operation checkCarOK definition: Input: Output: Rental.carOK The system will has been cleaned, has a full tank of fuel, oil and water topped up, tires properly inflated. Please check the car for roadworthiness tire tread depth, brake pedal and hand brake lever travel, lights, exhaust leaks, windscreen wipers. Please make sure that the car does not need repairs. When you have done so, please log on to the system and indicate that operation checkCarOK has car seems OK as the output of the operation, which is entered through the user interface. EU-Rent Rule: If an assigned car has not been picked up 90 minutes after the scheduled pick-up time, it may be released for walk-in rental, unless the rental has been guaranteed by credit card. Name: noShowNoGuarantee Condition: ninetyMinuteDelay == true AND Rental.guarantee = false Action: 1. releaseCar (Car.carID) Alternative Action: None Type: CAA Rule Operation releaseCar definition: Input: Car.carID Output: Set assigned, rented to false and set reserved to true EU-Rent Rule: If a rental has been guaranteed by credit card and the car has not been picked up by the end of the scheduled pick-ental is charged to the credit card and the car is released for use the following day. Name: noShowWithGuarantee Condition: Rental.endDate < endOfDay AND Rental.guarantee = true Action: 1. releaseCar (Car.carID) Alternative Action: None Type: CAA Rule

PAGE 122

122 EU-Rent Rule: If a car is returned to a location other than the agreed drop-off branch, a drop-off penalty is charged. Name: chargeDropOffPenalty Condition: Rental.dropOffBranch != Branch.branchID Action: 1. Rental. rentalCharge = addDropOffPenalty(Rental. rentalCharge) Alternative Action: None Type: CAA Rule Operation addDropOffPenalty definition: Input: Rental. rentalCharge Output: Rental.rentalCharge Add the drop off penalty to the rental charge and return the new charged amount. EU-Rent Rule: At the end of a rental, the customer may pay by cash, or by a credit card other than the one used to guarantee the rental. EU-Rent Rule: Local tax must be collected (at the drop-off location) on the rental charge. EU-Rent Rule: The car must be checked for wear (brakes, lights, tires, exhaust, wipers etc.) and damage, and repairs scheduled if necessary. EU-Rent Rule: If the car has been damaged during the rental and the customer is liable, the The above rules can be implemented as the following CAA rule. Name: checkCarOnReturn Condition: None Action: 1. acceptableModeOfPayment() 2. Rental.rentalCharge = collectLocalTax(Rental.dropOffBranch, Rental.rentalCharge) 3. Rental.rentalCharge = checkForWear(Rental.rentalCharge) Alternative Action: None Type: CAA Rule Operation acceptableModeOfPayment definition: Input: Output: the end of a rental, the customer may pay by cash, or by a credit card other than the one used to guarantee the rental. Operation collectLocalTax definition: Input : Rental.dropOffBranch, Rental.rentalCharge Output : Rental.rentalCharge float localTax = access the database to get the local tax at the drop-off branch Rental.rentalCharge = localTax Rental.rentalCharge/100 + Rental.rentalCharge;

PAGE 123

123 Operation checkForWear definition: Input: Rental.rentalCharge Output: Rental.rentalCharge wear (brakes, lights, tires, exhaust, wipers etc.) and damage, and schedule repairs if necessary. If the car has been damaged during the rental and the customer is liable, return the new amount done so, please log on to the system and indicate that operation checkCarOK has been which is entered through the user interface. EU-Rent Rule: If a car is returned early, the rental charge is calculated at the rate appropriate to the actual period of rental (e.g., daily rate rather than weekly). Name: adjustOnEarlyReturn Condition: Rental.endDate > currentDate Action: 1. Rental.rentalCharge = adjustCharge(Rental.rentalCharge, Rental.startDate, Rental.endDate) Alternative Action: None Type: CAA Rule Operation adjustCharge definition: Input: Rental.rentalCharge, Rental.startDate, Rental.endDate Output: Rental.rentalCharge The sycharge at the rate appropriate to the actual period of rental. When you have done so, please log on to the system and indicate that operation adjustCharge has been pto provide the new amount charged as the output of the operation, which is entered through the user interface. EU-Rent Rule: hours a whole day is charged. Name: calculateLateCharge Condition: Rental.endDate < currentDate Action: 1. Rental.rentalCharge = lateCharge(Rental.rentalCharge, Rental.startDate, Rental.endDate) Alternative Action: None Type: CAA Rule Operation lateCharge definition: Input: Rental.rentalCharge, Rental.startDate, Rental.endDate Output: Rental.rentalCharge Determine the delay, if less than 6 hours, add hourly rate and return the new amount, else charge for the whole day.

PAGE 124

124 EU-Rent Rule: If a car is not returned from rental by the end of the scheduled drop-off day and the customer has not arranged an extension, the customer should be contacted. Name: lateNoExtension Condition: Rental.endDate < endOfDay AND Rental.extension == False Action: 1. contactCustomer(Rental.custID) Alternative Action: None Type: CAA Rule Operation contactCustomer definition: Input: Output: The system will notify the rental agent with the followin EU-Rent Rule: If a car is three days overdue and the customer has not arranged an extension, insurance cover lapses and the police must be informed. Name: threeDaysOverdue Condition: Rental.endDate < endOfThreeDays AND Rental.extension == false Action: 1. contactPolice() Alternative Action: None Type: CAA Rule Operation contactPolice definition: Input: Output: EU-Rent Rule: Each car must be serviced every three months or 10,000 kilometers, whichever occurs first. Name: checkServiceNeeded if(Car.serviceMileage >= 10000 OR Car.threeMonthsServiceDate <= currentDate) then (Car.needsService == true) Type: Integrity Constraint EU-Rent Rule: If there is a shortage of cars for rental, routine maintenance may be delayed by up to 10% of the time or distance interval (whichever was the basis for scheduling maintenance) to meet rental demand. Name: assignScheduledCar Condition: Car.carID == -1 Action: 1. Car.carID = assignFromScheduled(Rental.mileage, Car.serviceMileage, Car.serviceDate, Car.scheduledDate, Rental.endDate) Alternative Action: None

PAGE 125

125 Type: CAA Rule Operation assignFromScheduled definition: Input: Rental.mileage, Car.serviceMileage, Car.serviceDate, Rental.endDate Output: Car.carID Find if a scheduled car can be assigned, provided the rental mileage would not take it more than 10% of approved service mileage, or the delay is no more than 10% of the interval between the service date and the scheduled date. EU-Rent Rule: Only cars on the authorized list can be purchased. Name: checkAuthorizedCar Car.model in {list of authorized models} Type: Integrity Constraint EU-Rent Rule: Cars are to be sold when they reach one year old or 40,000 kilometers, whichever occurs first. Name: isToBeSold if(Car.year < currentYear + 1 OR Car.mileage >= 40000) then (Car.toBeSold = true) Type: Derivation Rule EU-Rent Rule: A branch cannot refuse to accept a drop-off of a EU-Rent car, even if a one-way rental has not been authorized. EU-Rent Rule: When a car is dropped off at a branch other than the pick-ownership (and, hence, responsibility for it) switches to the drop-off branch when the car is dropped off. The above two rules can be implemented as the following CAA rule. Name: noAuthorizedOneWay Condition: Rental.dropOffBranch != Branch.branchID AND Rental.oneWay == false Action: 1. adviseNoRefusal(Rental.rentalID) 2. assignOwner(Branch.branchID, Car.carID) Alternative Action: None Type: CAA Rule Operation adviseNoRefusal definition: Input: Output: The system will notify the rental agent waccept a drop-off of a EU-Rent car, even if a oneOperation assignOwner definition: Input: Branch.branchID, Car.carID Output:

PAGE 126

126 EU-Rent Rule: Name: switchOwner Condition: None Action: 1. Car.owningBranch = assignOwner(Branch.branchID) Alternative Action: None Type: CAA Rule EU-Rent Rule: In each car group, if a branch accumulates cars to take it more than 10% over its quota, it must reduce the number back to within 10% of quota by transferring cars to other branches or selling some cars. Name: adjustQuotaDown Condition: 1. Group.numRemainingCars > Group.quota + 0.1 Group.quota Action: 1. sellOrTransfer(Group.groupID) Alternative Action: None Type: CAA Rule Operation sellOrTransfer definition: Input: Group.groupID Output: EU-Rent Rule: In each car group, if a branch loses cars to take it more than 10% below its quota, it must increase the number back to within 10% of quota by transferring cars from other branches or buying some cars. Name: adjustQuotaUp Condition: 1. Group.numRemainingCars < Group.quota 0.1 Group.quota Action: 1. buyOrTransfer(Group.groupID) Alternative Action: None Type: CAA Rule Operation buyOrTransfer definition: Input: Group.groupID Output: The system will notify the branch manager with the followin EU-Rent Rule: To join the loyalty incentive scheme, a customer must have made 4 rentals within a year. Name: eligibleForLoyaltyScheme if(Customer.numYearlyRentals >= 4)

PAGE 127

127 then (Customer.eligible = true) Type: Derivation Rule EU-Rent Rule: Each paid rental in the scheme (including the 4 qualifying rentals) earns points Name: earnPoints Condition: Customer.points > 0 AND Rental.free == false Action: 1. Customer.points = addPoints(Rental.rentalID, Cusomter.custID) Alternative Action: None Type: CAA Rule Operation addPoints definition: Calculate the number of points the customer will earn and add that to his total. Return the new points. EU-Rent Rule: Only the basic rental cost of a free rental can be bought with points. Extras, such as insurance, fuel and taxes must be paid by cash or credit card Name: freeRental Condition: Cusomter.points >0 AND Rental.free == true Action: 1. Customer.points, Rental.rentalCharge = getFreeRental(Rental.rentalID, Rental.rentalCharge, Customer.custID) Alternative Action: None Type: CAA Rule Operation getFreeRental definition: Input: Rental.rentalID, Rental.rentalCharge, Customer.custID Output: Customer.points, Rental.rentalCharge Subtract the basic cost of rental from the rental charge, anthe adjusted charge and the new points. EU-Rent Rule: A free rental must be booked at least fourteen days before the pick-up date. Name:checkAdvBooking if(Rental.free == true) then (getBookingGap(Rental.bookDate, Rental.startDate) >= 14) Type: Integrity Constraint Operation getBookingGap definition: Input: Rental.bookDate, Rental.startDate Output: bookingGap Returns the number of days between the book and the start dates EU-Rent Rule: Free rentals do not earn points Name: freeRentalPoints if(Rental.free == true)

PAGE 128

128 then (Rental.points = 0) Type: Derivation Rule EU-Rent Rule: Unused points expire three years after the end of the year in which they were earned. Name: unusedPoints Condition: getDifference(Customer.pointsYear, currentYear) >= 3 Action: 1. Cusomter.points = expireUnusedPoints( Customer.custID, Customer.pointsYear) Alternative Action: None Type: CAA Rule Operation getDifference definition: Input: Customer,pointsYear, currentYear Output: difference Returns the number of years between the year the customer first earned the points and the current year Operation expireUnusedPoints definition: Input: Customer.custID, Customer.pointsYear Output: Cusomter.points Expire unused points of the customer and return the adjusted points ETKnet Rule: Get the branch information Name: getBranch Condition None Action: 1. Branch.* = getBranchInfo(Branch.branchID) Alternative Action: None Type: CAA Rule Operation getBranchInfo definition: Input: Branch.branchID Output:Branch.* Return the information about this branch Events and Triggers On the occurrence of an event, the associated trigger will be processed Event: Reservation Request (Customer.*, Car.*, Branch.branchID) Trigger: driverCheck getBranch (RS1) capacityCheck AND

PAGE 129

129 noGroupAndModelSpecified assignCarOnModelOrGroup giveUpgrade allocateNextDay bumpedUpgrade downgrade assignScheduledCar Event: No Suitable Car Found (Car.*) Trigger: (RS2) delayPickUp rentFromCompetitor Event: Suitable Car Found (Car.*, Customer.*) Trigger: checkOwningBranch (RS3) checkNotAssigned checkNotRented checkNotScheduled noMultipleCars reserveForWalkIn Event: Walk In Request(Customer.*, Car.*) Trigger: (RS4) driverCheck

PAGE 130

130 noGroupAndModelSpecified assignCarOnModelOrGroup findAvailableCars checkCarNotScheduled Event: Handover(Customer.*, Car.*) Trigger: driverCheck (RS5) mechanicalConditionAndEmissionCheck authorizedDrivers beforeRelease checkDriver checkCar AND earnPoints Event: Rental Return (Rental.*) Trigger: (RS6) noAuthorizedOneWay switchOwner chargeDropOffPenalty adjustOnEarlyReturn calculateLateCharge

PAGE 131

131 lateNoExtension threeDaysOverdue Event: No Show (Rental.*, Customer.*) Trigger: Event: Car Transfer(Car.*, Branch.*) Trigger: switchOwner (RS7) adjustQuotaDown adjustQuotaUp Event: Free Rental Request (Customer.*, Rental.*) Trigger: eligibleForLoyaltyScheme (RS8) freeRental freeRentalPoints checkAdvBooking Event: Car Sale And Purchase(Car.*) Trigger: isToBeSold (RS9) checkAuthorizedCar Event: Three Month Service Check (Car.*) Trigger: Event: Expire Points (Customer.*) Trigger:

PAGE 132

132 Table B-1. Average time to create and execute rules and rule structures in the EU-Rent domain Rule o r rule struc ture name Avg ti me to define(sec.) Avg time to execute(sec.) DriverCheck 8 0.229 MechanicalConditionAndEmissionCheck 7.7 0.099 NoGroupAndModelSpecified 7.8 0.033 CapacityCheck 7.6 0.096 NoMultipleCars 7.7 0.102 CheckOwningBranch 7.6 0.096 CheckNotAssigned 7.7 0.075 CheckNotRented 7.6 0.077 CheckNotScheduled 7.4 0.075 AssignCarOnModelOrGroup 8.3 1.089 ReserveForWalkIn 8.1 1.058 GiveUpgrade 8.1 8.2 AllocateNextDay 7.7 1.023 BumpedUpgrade 7.9 3.5 Downgrade 7.8 3.5 DelayPickUp 9.5 0.181 Re ntFromCompetitor 8.0 2.7 CheckCarNotScheduled 7.5 0.054 FindAvailableCars 7.6 1.004 AuthorizedDrivers 7.7 0.100 BeforeRelease 7.5 4.1 CheckDriver 7.8 2.7 CheckCar 7.6 2.6 NoShowNoGuarantee 7.8 1.072 NoShowWithGuarantee 7.7 1.028 Charg eDropOffPenalty 7.7 1.871 CheckCarOnReturn 7.9 4.6 AdjustOnEarlyReturn 7.9 1.883 CalculateLateCharge 8.0 1.816 LateNoExtension 7.9 4.5 ThreeDaysOverdue 8.0 4.6 CheckServiceNeeded 7.8 0.096 AssignScheduledCar 7.9 2.939 CheckAuthorizedCar 7.6 0.054 IsToBeSold 8.4 0.102 NoAuthorizedOneWay 8.3 1.932 SwitchOwner 8.1 1.986 AdjustQuotaDown 8.4 0.465 AdjustQuotaUp 8.1 0.500 EligibleForLoyaltyScheme 8 0.055 EarnPoints 8 1.491 FreeRental 8.2 1.512 CheckAdvBooking 8 1.7 FreeRental Points 7.8 0.054

PAGE 133

133 UnusedPoints 8 0.5 GetBranch 7.9 0.499 RS1 9.1 2.047 RS2 8.3 2.285 RS3 8.6 8.6 RS4 8.5 7.1 RS5 8.8 23 RS6 8.7 30 RS7 8 4.7 RS8 8.1 4.9 RS9 7.6 2.3

PAGE 134

134 APPENDIX C EVENTS AND RULES IN THE NPDN DOMAIN Note: Operations in the SOP can be either automated or manual. Automated operations are performed by the system automatically. Manual operations are implemented by notifying the proper persons or organizations to perform the operations. All notifications specified in this screen when users log in. The steps of the SOP that the events and rules are derived from are also mentioned. Step 1a Organization: Grower, Pest Advisor, or other Sample Submitting Entity (SSE) Any of the organizations that can be the sample submitting entity can post the event in case a suspect sample is observed. By posting, we mean the occurrence of the following event. Event SSEE1: Suspect Sample Observed (npdn.Sample Sample.*) Rule SSER1: Condition : None Action: 1. time_of_arrival, method_of_delivery = Send_Sample_To_Diagnostician(npdn.Sample Sample.*) 2. Contact_Diagnostician(npdn.Sample Sample.*, time_of_arrival, method_of_delivery) Alternative Action: None The data item Sample (i.e. the entity npdn.Sample) contains the following attributes, which may or may not have any data. As the diagnosis proceeds, the attributes get assigned appropriate values. sampleID of type integer (blank) sampleDate of type date (filled in by Grower, Pest Advisor or other SSE) cropCode of type integer (blank) cropGenus of type string (blank) cropSpecies of type string (blank) pestCode of type string (blank) pestGenus of type string (blank) pestSpecies of type string (blank) classification stateOfOrigin of type string (filled in by Grower, Pest Advisor or other SSE) notes of type string (blank) Send_Sample_To_Diagnostician() definition: The system will notify the Grower, Pest Advisor to an NPDN triage lab. When you have done so, please log on to the system and indicate that operation Send_Sample_To_Diagnostician time_of_delivery (of type date) and the method_of_delivery (of type string) as the output of the operation, which are entered through the user interface.

PAGE 135

135 Contact_Diagnostician definition: The system will notify the Grower, Pest Advisor or other State Department of Agriculture to notify that a suspect sample is enroute with time of arrival and method of delivery. When you have done so, please log on to the system and indicate that operation Contact_Diagnostician Trigger: 1) Step 1b Organization: State Department of Agriculture, APHIS-PPQ, or University Staff (i.e. Any of the organizations that can be the diagnostician can post the event in case a suspect sample is received. By posting, we mean the occurrence of the following event. Event SDAE1: Suspect Sample Received (npdn.Sample Sample.*) The data item Sample contains the following attributes, which may or may not have any data. As the diagnosis proceeds, the attributes get assigned appropriate values. sampleID of type integer (blank) sampleDate of type date (filled in by Grower, Pest Advisor or other SSE) cropCode of type integer (blank) cropGenus of type string (blank) cropSpecies of type string (blank) pestCode of type string (blank) pestGenus of type string (blank) pestSpecies of type string (blank) classification stateOfOrigin of type string (filled in by Grower, Pest Advisor or other SSE) notes of type string (blank) Rule SDAR1: Condition: None Action: 1. Send_Sample_To_NPDN(npdn.Sample Sample.*) Alternative Action: None Send_Sample_To_NPDN() definition: The system will notify the State Department of Agriculture, APHIS-e send the sample to the National Plant Diagnostic Network Triage Lab. When you have done so, please log on to the system and indicate that operation Send_Sample_To_NPDN() Trigger: Steps 2a-2d Organization: NPDN Triage Lab Event NTLE1: Suspect Sample Received (npdn.Sample Sample.*) Rule NTLR1: Condition: None Action: 1. Ack_Receipt(npdn.Sample Sample.*) 2. Sample.sampleID = Assign_ID (npdn.Sample Sample.*)

PAGE 136

136 3. Sample.* = Examine_Sample (npdn.Sample Sample.*) 4. Sample.classification = Classify_As_Presumptive_Positive() 5. Store_Sample(npdn.Sample Sample.*) 6. Request_Confirming_Diagnosis(npdn.Sample Sample.*) 7. distance_diagnosis_capability = Get_Capability() Alternative Action: None Ack_Receipt definition: The system will notify the NPDN Triage Lab staff with the following meUniversity Staff. When you have done so, please log on to the system and indicate that operation Ack_Receipt Assign_ID definition: An automated operation that generates a unique id for the given sample. After this operation is performed, the sample has the sampleID attribute filled in: sampleID of type integer (filled in by Assign_ID) sampleDate of type date (filled in by Grower, Pest Advisor or other SSE) cropCode of type integer (blank) cropGenus of type string (blank) cropSpecies of type string (blank) pestCode of type string (blank) pestGenus of type string (blank) pestSpecies of type string (blank) classification stateOfOrigin of type string (filled in by Grower, Pest Advisor or other SSE) notes of type string (blank) Examine_Sample definition: The system will notify the NPDN Triage Lab staff with the e so, please log on to the system and indicate that operation Examine_Sample provide the updated sample information Sample.* (of type npdn.Sample) as the output of the operation, which is entered through the user interface. Classify_As_Presumptive_Positive definition: An automated operation that fills in the value After this operation the sample may have the remaining attributes filled in: sampleID of type integer (filled in by Assign_ID) sampleDate of type date (filled in by Grower, Pest Advisor or other SSE) cropCode of type integer (possibly filled in by Examine_Sample) cropGenus of type string (possibly filled in by Examine_Sample) cropSpecies of type string (possibly filled in by Examine_Sample) pestCode of type string (possibly filled in by Examine_Sample) pestGenus of type string (possibly filled in by Examine_Sample) pestSpecies of type string (possibly filled in by Examine_Sample)

PAGE 137

137 classification stateOfOrigin of type string (filled in by Grower, Pest Advisor or other SSE) notes of type string (possibly filled in by Examine_Sample) Store_Sample definition: The system will notify the NPDN Triage Lab staff with the following and indicate that operation Store_Sample Request_Confirming_Diagnosis definition: The system will notify the NPDN Triage Lab staff APHIS-PPQ CDD, and NPDN Hub Lab informing them that a presumptive positive sample is in the system. When you have done so, please log on to the system and indicate that operation Request_Confirming_Diagnosis Get_Capability definition: An automated operation that finds out whether or not this lab has the distance diagnosis capability, indicated by the output distance_diagnosis_capability. Step 2e Rule NTLR2: Condition: distance_diagnosis_capability = true Action: Conduct_Web_Based_Diagnosis(npdn.Sample Sample.*) Alternative Action: sample_image = Email_Picture() Conduct_Web_Based_Diagnosis definition: The system will notify the NPDN Triage Lab staff -PPQ CDD, and NPDN Hub Lab to set up a web-based distance diagnosis session. When you have done so, please log on to the system and indicate that operation Conduct_Web_Based_Diagnosis Email_Picture definition: The system will notify the NPDN Triage Lab staff with the following -PPQ CDD, and the NPDN Hub Lab. When you have done so, please log on to the system and indicate that operation Email_Picture sample_image (of type File) as output, which is entered through the user interface. Steps 2f-2h Rule NTLR3: Condition: None Action: 1. Shipment.*, time_of_delivery, method_of_delivery = Divide_And_Ship_Sample(npdn.Sample Sample.*) 2. Contact_About_Shipment (npdn.Shipment Shipment.*, String Sample.stateOfOrigin, time_of_delivery, method_of_delivery, int Sample.sampleID) Alternative Action: None Divide_And_Ship_Sample definition: The system will notify the NPDN Triage Lab staff with consult the CDD on which it should be. If routine sample or if hub lab has provisional approval to ID from CDD then it should go to the hub lab, otherwise if hub lab is not provisionally

PAGE 138

138 approved for the suspect species or if it is very high consequence first occurrence, then it should go to CDD directly. Accordingly, divide the sample into portions and send a portion to the APHIS-PPQ CDD Lab or to the NPDN Regional Hub Lab. Please ensure that the sample is double bagged in zippable bags and sealed in a box with tape, sample submission form is information, Shipment.* (of type npdn.Shipment), time_of_delivery (of type string), and method_of_delivery (of type string) as output, which are entered through the user interface. The data item Shipment (i.e. the entity npdn.Shipment) contains the following attributes. sender of type string (filled in by NPDN Triage Lab) receiver of type string (filled in by NPDN Triage Lab) trackingNumber of type string (filled in by NPDN Triage Lab) doubleBagged of type Boolean (filled in by NPDN Triage Lab) submissionFormIncluded of type Boolean (filled in by NPDN Triage Lab) businessCardIncluded of type Boolean (filled in by NPDN Triage Lab) shippingLabel of type string (filled in by NPDN Triage Lab) Contact_About_Shipment definition: The system will notify the NPDN Triage Lab staff with the following message: -PPQ SPHD, APHIS-PPQ CDD, and NPDN Hub Lab or Expert Lab informing them of the presumptive positive sample shipment time and delivery method, including tracking number. When you have done so, please log on to the system and indicate that operation Contact_About_Shipment Step 2i Rule NTLR4: Condition: None Action: 1. Contact_Campus_Safety_Officer(npdn.Sample Sample.*) Alternative Action: None Contact_Campus_Safety_Officer definition: The system will notify the NPDN Triage Lab staff presumptive positive sample in the system. When you have done so, please log on to the system and indicate that operation Contact_Campus_Safety_Officer Trigger: NTLR2 NTLR3 NTLR4

PAGE 139

139 (i.e. Event NTLE1 will trigger the processing of rule NTLR1, followed by rule NTLR2. Once rule NTLR2 completes execution, rules NTLR3 and NTLR4 are executed in parallel) Steps 3a-3b Organization: State of Origin SPRO Event SPROE1: Presumptive Positive Sample Recorded (npdn.Sample Sample.*) Rule SPROR1 : Condition: None Action: 1. ResponsePlan.* = Contact_SPHD(npdn.Sample Sample.*) Alternative Action: None Contact_SPHD definition: The system will notify the State of Origin SPRO with the following presumptive positive sample is confirmed positive by the APHIS-PPQ CDD. You can communicate with other regulatory officials in neighboring states to plan and/or activating the strategy. When you have done so, please log on to the system and indicate that operation Contact_SPHD response plan, ResponsePlan.* (of type npdn.ResponsePlan) as output, which is entered through the user interface. The data item ResponsePlan (i.e. the entity npdn.ResponsePlan) contains the following attributes: officialsToBeNotified of type string pestGenus of type string pestSpecies of type string pressRelease of type string Trigger: (i.e. Event SPROE1 will trigger the processing of rule SPROR1) Steps 4a-4b Organization: NPDN Regional Hub Lab Event NHLE1: Presumptive Positive Sample Received (npdn.Sample Sample.*) Rule NHLR1: Condition: (Shipment.doubleBagged == true) && (Shipment.submissionFormIncluded == true) && (Shipment.businessCardIncluded == true) && (Shipment.shippingLabel Action: 1. Ack_Receipt (npdn.Sample Sample.*) 2. Sample.* = Examine_Sample(npdn.Sample Sample.*) 3. contact_local_expert = Is_OK_To_Contact_Local_Expert() Alternative Action: 1. Contact_NPDN_Triage_Lab(Boolean Shipment.doubleBagged, boolean Shipment.submissionFormIncluded, boolean Shipment.businessCardIncluded, String Shipment.shippingLabel, npdn.Sample Sample.*)

PAGE 140

140 Ack_Receipt definition: The system will notify the NPDN Hub Lab staff with the following eipt of the sample to the NPDN Triage Lab. When you have done so, please log on to the system and indicate that operation Ack_Receipt has been Examine_Sample definition: The system will notify the NPDN Regional Hub Lab staff with the following system and indicate that operation Examine_Sample provide updated information about the sample, Sample.* (of type npdn.Sample) as output, which is entered through the user interface. After this operation is performed, the sample may have some changes to the values of some of its attributes: sampleID of type integer (filled in by Assign_ID) sampleDate of type date (filled in by Grower, Pest Advisor or other SSE) cropCode of type integer (possibly changed by Examine_Sample) cropGenus of type string (possibly changed by Examine_Sample) cropSpecies of type string (possibly changed by Examine_Sample) pestCode of type string (possibly changed by Examine_Sample) pestGenus of type string (possibly changed by Examine_Sample) pestSpecies of type string (possibly changed by Examine_Sample) classification stateOfOrigin of type string (filled in by Grower, Pest Advisor or other SSE) notes of type string (possibly changed by Examine_Sample) Is_OK_To_Contact_Local_Expert definition: The system will notify the NPDN Regional Hub OK to bring in a local expert. When you have done so, please log on to the system and indicate that operation Is_OK_To_Contact_Local_Expert contact_local_expert (of type boolean) as output, which is entered through the user interface. Contact_NPDN_Triage_Lab definition: The system will notify the NPDN Regional Hub Lab shipping procedures were not followed. When you have done so, please log on to the system and indicate that operation Contact_NPDN_Triage_Lab Step 4c Rule NHLR2: Condition: (contact_local_expert == true) Action: 1. results_received = Contact_Local_Expert(npdn.Sample Sample.*) Alternative Action: None Contact_Local_Expert definition: The system will notify the NPDN Hub Lab with the following please log on to the system and indicate that operation Contact_Local_Expert has been indicate that the local expert provided the results), which is entered through the user interface.

PAGE 141

141 Steps 4g-4i Rule NHLR3: Condition: None Action: 1. Contact_NPDNDirector_And_APHIS(npdn.Sample Sample.*) 2. Contact_SPRO_SPHD(String Sample.classification) 3. Contact_CS_Officer(String Sample.classification) 4. to_send_to_APHIS = Contact_APHIS(npdn.Sample Sample.*) Alternative Action: None Contact_NPDNDirector_And_APHIS definition: The system will notify the NPDN Hub Lab -PPQ-Confirming Diagnosis Designate with preliminary conclusions/results. When you have done so, please log on to the system and indicate that operation Contact_NPDNDirector_And_APHIS has Contact_SPRO_SPHD definition: The system will notify the NPDN Hub Lab with the following sample is housed in NPDN Regional Hub until shipment to APHIS-PPQ Confirming Designate or until it is destroyed following diagnosis. Do not disclose the state of origin to SPRO or SPHD. When you have done so, please log on to the system and indicate that operation Contact_SPRO_SPHD Contact_CS_Officer definition: The system will notify the NPDN Hub Lab staff with the positive sample in the system. Do not disclose state of origin. When you have done so, please log on to the system and indicate that operation Contact_CS_Officer Contact_APHIS definition: The system will notify the NPDN Hub Lab with the following -PPQ Confirming Diagnosis Designate and ask if they request sending sample for confirmation, When you have done so, please log on to the system and indicate that operation Contact_APHIS to_send_to_APHIS (of type boolean) as output, which is entered through the user interface. Steps 4j-4k Rule NHLR4: Condition: to_send_to_APHIS == true Action: 1. Shipment.*, time_of_delivery, method_of_delivery = Send_Sample_To_APHIS(npdn.Sample Sample.*) 2. Contact_APHIS_With_ShipmentDetails(npdn.Shipment Shipment.*) Alternative Action: None Send_Sample_To_APHIS definition: The system will notify the NPDN Hub Lab with the the APHIS-PPQ CDD. When you have done so, please log on to the system and indicate that operation Send_Sample_To_APHIS() has been

PAGE 142

142 npdn.Shipment), time_of_delivery (of type date), and method_of_delivery (of type string) as output, which are entered through the user interface. Contact_APHIS_With_ShipmentDetails definition: The system will notify the NPDN Hub Lab -PPQ CDD to notify that a presumptive positive sample is enroute with time of arrival and method of delivery. When you have done so, please log on to the system and indicate that operation Contact_APHIS_With_ShipmentDetails Trigger: The NHLE1 NHLR1 NHLR2 NHLR3 AND NHLR4 (i.e. Event NHLE1 will trigger the processing of rule NHLR1. Once rule NHLR1 completes processing, rules NHLR2 and NHLR3 will be executed in parallel. Once both these rules finish processing, rule NHLR4 will be executed) Steps 4d-4f Organization: Local Expert Event LEE1: Presumptive Positive Sample Received (npdn.Sample Sample.*) Rule LER1: Condition: None Action: 1. Sample.* = Examine_Sample(npdn.Sample Sample.*) 2. Contact_NPDN_With_Results(npdn.Sample Sample.*) Alternative Action: None Examine_Sample definition: The system will notify the Local Expert with the following the preliminary diagnosis in collaboration with NPDN Regional Hub staff. When you have done so, please log on to the system and indicate that operation Examine_Sample sample, Sample.* (of type npdn.Sample) as output, which is entered through the user interface. Contact_NPDN_With_Results definition: The system will notify the Local Expert with the conclusions/results. When you have done so, please log on to the system and indicate that operation Contact_NPDN_With_Results Trigger: (i.e. Event LEE1 will trigger the processing of rule LER1)

PAGE 143

143 Step 5 Organization: NPDN Regional Director from state of origin Event NRDE1: Presumptive Positive Sample Under Diagnosis (npdn.Sample Sample.*) Rule NRDR1: Condition: None Action: 1. Contact_NPDN_Program_Leader(npdn.Sample Sample.*) Alternative Action: None Contact_NPDN_Program_Leader definition: The system will notify the NPDN Regional the presumptive positive sample is under diagnosis. Do not disclose state of origin except to Program Leader. When you have done so, please log on to the system and indicate that operation Contact_NPDN_Program_Leader Trigger: (i.e. Event NRDE1 will trigger the processing of rule NRDR1) Step 6a Organization: APHIS-PPQ CDD Event ACDDE1: Presumptive Positive Sample Received (npdn.Sample Sample.*) Rule ACDDR1: Condition: None Action: 1. Ack_Receipt(npdn.Sample Sample.*) 2. expected_date, more_than_seven_days = Date_Of_Result_Notification(npdn.Sample Sample.*) 3. ok_to_contact_NPDN = Is_OK_To_Contact_NPDN() Alternative Action: None Ack_Receipt definition: The system will notify the APHIS-PPQ CDD staff with the followings NPDN Triage Lab. When you have done so, please log on to the system and indicate that operation Ack_Receipt has been Date_Of_Result_Notification definition: The system will notify the APHIS-PPQ CDD staff with the following messanotification When you have done so, please log on to the system and indicate that operation Date_Of_Result_Notification type date) of confirmation information as well as whether confirmation it will be more than seven days after submission, more_than_seven_days (of type boolean) as output, which are entered through the user interface. Is_OK_To_Contact_NPDN definition: The system will notify the APHIS-PPQ CDD staff with -PPQ Program Manager to consult with the NPDN Program Leader and determine if it is OK to inform other NPDN Regional Directors and their diagnosticians. When you have done so, please log on to the system and indicate that operation Is_OK_To_Contact_NPDN ok_to_contact_NPDN (of type boolean) as output, which is entered through the user interface.

PAGE 144

144 Steps 6b-6c Rule ACDDR2: Condition: (more_than_seven_days == true) && (ok_to_contact_NPDN == true) Action: 1. Contact_Other_Directors() 2. Contact_Diagnosticians() Alternative Action: None Contact_Other_Directors definition: The system will notify the NPDN Regional Director of inform them that a presumptive positive sample is in the system. Kindly do not disclose origin of sample. When you have done so, please log on to the system and indicate that operation Contact_Other_Directors Contact_Diagnosticians definition: The system will notify all NPDN Regional Directors with the act diagnosticians in your region at NPDN labs in each state to inform them that a presumptive positive sample is under diagnosis in an unknown location in the nation and to be alert for similar samples that may be appearing in other labs. When you have done so, please log on to the system and indicate that operation Contact_ Diagnosticians has Steps 6d-6g, Step 7a Rule ACDDR3: Condition: None Action: 1. Result.* = Conduct_Confirming_Diagnosis(npdn.Sample Sample.*) 2. Contact_Administrator(npdn.Result Result.*) 3. Contact_Regional_APHIS_Staff(npdn.Result Result.*) 4. Contact_SPHD(npdn.Result Result.*) 5. Contact_TriageLab(npdn.Result Result.*) Alternative Action: None The data item Result (i.e. the entity npdn.Result) contains the following attributes. sampleID of type integer sampleDate of type date cropCode of type integer cropGenus of type string cropSpecies of type string pestCode of type string pestGenus of type string pestSpecies of type string classification of type string confirmedDiagnosisDate of type date expectedDateTime of type date notes of type string Conduct_Confirming_Diagnosis definition: The system will notify the APHIS-PPQ CDD Staff

PAGE 145

145 please log on to the system and indicate that operation Conduct_Confirming_Diagnosis has been eds to provide the diagnosis results, Result.* (of type npdn.Result) as output, which is entered through the user interface. Contact_Administrator definition: The system will notify the APHIS-PPQ CDD Staff with the PHIS-PPQ Administrator to inform him of the final results. When you have done so, please log on to the system and indicate that operation Contact_Administrator Contact_Regional_APHIS_Staff definition: The system will notify the APHIS-PPQ them of the final results. When you have done so, please log on to the system and indicate that operation Contact_Regional_APHIS_Staff Contact_SPHD definition: The system will notify the APHIS-PPQ Administrator with the inform him of the final results. When you have done so, please log on to the system and indicate that operation Contact_SPHD Contact_TriageLab definition: The system will notify the APHIS-CDD Staff with the following after enough time has passed that state of origin SPHD and SPRO and Triage Lab Diagnostician should have been informed of the confirmed diagnosis results by regional APHIS-PPQ office. When you have done so, please log on to the system and indicate that operation Contact_TriageLab has been Trigger: ACDDE1 ACDDR1 ACDDR2 ACDDR3 (i.e. Event ACDDE1 will trigger the sequential processing of rules ACDDR1, ACDDR2, and ACDDR3) Step 6h Organization: SPHD from State of Origin Event SPHDE1: Results Received(npdn.Result Result.*) Rule SPHDR1: Condition: None Action: 1. Contact_SPRO(npdn.Result Result.*) Alternative Action: None

PAGE 146

146 Contact_SPRO definition: contact the State Plant Regulatory Official of the state of origin to inform him of the final results. When you have done so, please log on to the system and indicate that operation Contact_SPRO Trigger: (i.e. Event SPHDE1 will trigger the processing of rule SPHDR1) Step 6i, Step 9b Organization: SPRO from State of Origin Event SPROE2: Results Received from SPRO(npdn.Result Result.*) Rule SPROR2: Condition: None Action: 1. Contact_TriageLab(npdn.Result Result.*) 2. Submit_Record(npdn.Result Result.*) Alternative Action: None Contact_TriageLab definition: The system will notify the SPRO with the following message: e Lab to inform them of the final results. When you have done so, please log on to the system and indicate that operation Contact_TriageLab Submit_Record() definition: The system will notify the SPRO with the following message: e submit the record to the NAPIS CAPS database. When you have done so, please log on to the system and indicate that operation Submit_Record Trigger: (i.e. Event SPROE2 will trigger the processing of rule SPROR2) Steps 7b-7c, Steps 7g-7h Organization: NPDN Triage Lab Event NTLE2: Results Received from APHIS(npdn.Result Result.*) Rule: NTLR5: Condition: None Action: 1. Contact_Relevant_Organizations(npdn.Result Result.*) 2. Contact_NPDNHub(npdn.Result Result.*) 3. Contact_SSE(npdn.Result Result.*, npdn.ResponsePlan ResponsePlan.*) 4. Contact_Campus_Officer(npdn.Result Result.*) Alternative Action: None Contact_Relevant_Organizations definition: The system will notify the NPDN Triage Lab Staff with the foNPDN Director to acknowledge receipt of results. When you have done so, please log on to the system and indicate that operation Contact_Relevant_Organizations has been perfo Contact_NPDNHub definition: The system will notify the NPDN Triage Lab Staff with the

PAGE 147

147 When you have done so, please log on to the system and indicate that operation Contact_NPDNHub Contact_SSE definition: The system will notify the NPDN Triage Lab Staff with the following results as approved and designated by the state of origin SPRO and SPHD. When you have done so, please log on to the system and indicate that operation Contact_SSE Contact_Campus_Officer definition: The system will notify the NPDN Triage Lab Staff with the followsample destruction. When you have done so, please log on to the system and indicate that operation Contact_Campus_Officer Step 7i Rule: NTLR6: Conditi Action: 1. Destroy_Sample() 2. select_agent = Is_Select_Agent() Alternative Action: None Destroy_Sample() definition: The system will notify the NPDN Triage Lab Staff with the material and the sample in an autoclave for at least 20 minutes. When you have done so, please log on to the system and indicate that operation Destroy_Sample has be Is_Select_Agent definition: The system will notify the NPDN Triage Lab Staff with the have done so, please log on to the system and indicate that operation Is_Select_Agent has been through the user interface. Rule: NTLR7: Condition: select_agent == true Action: 1. Submit_Form4() Alternative Action: None Submit_Form4() definition: The system will notify the NPDN Triage Lab Staff with the to the system and indicate that operation Submit_Form4 has been perform Step 9a Rule: NTLR8: Condition: None Action: 1. Submit_Record(npdn.Result Result.*) Alternative Action: None Submit_Record definition: The system will notify the NPDN Triage Lab Staff with the following NPDN database. When you have done so, please log on to the system and indicate that operation Submit_Record

PAGE 148

148 Trigger: NTLE2 NTLR5 NTLR6 NTLR7 NTLR8 (i.e. Event NTLE2 will trigger the sequential processing of rules NTLR5, NTLR6, NTLR7, and NTLR8) Step 7d, Steps 8a-8b Organization: NPDN Regional Hub Lab Event NHLE2: Results Received from NPDN Triage Lab (npdn.Result Result.*) Rule: NHLR5: Condition: None Action: 1. Contact_Program_Leader(npdn.Result Result.*) 2. Contact_SPRO_And_SPHD (npdn.Result Result.*) 3. Contact_Campus_Officer (npdn.Result Result.*) 4. select_agent = Is_Select_Agent() Alternative Action: None Contact_Program_Leader definition: The system will notify the NPDN Hub Lab Staff with the Program Leader to notify him/her of the results. When you have done so, please log on to the system and indicate that operation Contact_Program_Leader Contact_SPRO_And_SPHD definition: The system will notify the NPDN Hub Lab Staff with the destruction. Do not disclose state of origin. When you have done so, please log on to the system and indicate that operation Contact_SPRO_And_SPHD has been per Contact_Campus_Officer definition: The system will notify the NPDN Hub Lab Staff with the destruction. Do not disclose state of origin. When you have done so, please log on to the system and indicate that operation Contact_Campus_Officer Is_Select_Agent definition: The system will notify the NPDN Hub Lab Staff with the following a select agent. When you have done so, please log on to the system and indicate that operation Is_Select_Agent has been

PAGE 149

149 through the user interface. Rule: NHLR6: Condition: select_agent == true Action: 1. Submit_Form4() Alternative Action: None Submit_Form4() definition: The system will notify the NPDN Hub Lab Staff with the following ase log on to the system and indicate that operation Submit_Form4 Trigger: NHLE2 NHLR5 NHLR6 (i.e. Event NHLE2 will trigger the sequential processing of rules NHLR5 and NHLR6) Step 7e Organization: NPDN Regional Director from state of origin Event NRDE2: Results Received from NPDN Triage Lab (npdn.Result Result.*) Rule: NRDR2: Condition: None Action: 1. Contact_Other_Dirs(npdn.Result Result.*) Alternative Action: None Contact_Other_Dirs definition: The system will notify the NPDN Regional Director with the of APHIS-PPQ in consultation with NPDN Program Leader, with the results. Do not disclose state of origin. When you have done so, please log on to the system and indicate that operation Contact_Other_Dirs (i.e. Event NRDE2 will trigger the processing of rule NRDR2) Step 7f Organization: Other NPDN Regional Directors Event ONRDE1: Results Received from NPDN Regional Director in state of origin (npdn.Result Result.*) Rule: ONRDR1: Condition: None Action: 1. Contact_Regional_Labs (npdn.Result Result.*) Alternative Action: None Contact_Regional_Labs definition: The system will notify the NPDN Regional Director with the APHIS-PPQ in consultation with NPDN Program Leader, with the results. Do not disclose state

PAGE 150

150 of origin. When you have done so, please log on to the system and indicate that operation Contact_Regional_Labs (i.e. Event ONRDE1 will trigger the processing of rule ONRDR1) Table C-1. Average time to create and execute rules and rule structures in the NPDN domain Rule or rul e structure n ame Average time to define (sec.) Average time to execute (sec.) SSER1 8.7 44 SDAR1 9.3 22 NTLR1 8.3 29 NTLR2 8 .4 25 NTLR3 8.5 46 NTLR4 8.3 5 NTLRS1 8.4 46 SPROR1 8.2 5 NHLR1 8.7 6.7 NHLR2 8.2 2.7 NHLR3 8.7 30 NHLR4 8.6 54 NHLRS1 8.4 63 LER1 8.6 48 NRDR1 8.5 26 ACDDR1 8.3 16 ACDDR2 8.2 45 ACDDR3 8.4 89 ACDDRS 8.5 54 SPHDR1 8.2 22 SPROR2 8.4 2 NTLR5 8.8 11 NTLR6 8.2 4 NTLR7 8.1 20 NTLR8 8.4 0.3 NHLR5 8.7 16 NHLR6 8.3 4 NHLRS2 8.5 20 NTLRS2 8.5 31 NRDR2 8.5 22 ONRDR1 8.5 28

PAGE 151

151 LIST OF REFERENCES 1. Agrawal, R., Evfimievski, A., Srikant, R.: Information Sharing across Private Databases. In: Proceedings of the ACM SIGMOD Conference, pp. 86-97, 2003 2. Aiken, A., Widom, J., Hellerstein, J.: Behavior of Database Production Rules : Termination, Confluence and Observable Determinism. In: Proceedings of the ACM SIGMOD Conference, pp. 59-68, 1992 3. Aiken, A., Widom, J., Hellerstein, J. Static analysis techniques for predicting the behavior of active database rules. ACM TODS 20(1), 3-41 (1995) 4. Bailey, J., Dong, G., Ramamohanarao, K.: Decidability and Undecidability Results for the Termination Problem of Active Database Rules. In: Proceedings of PODS, pp. 264-273, 1998 5. Baralis, H., Widom, J.: An Algebraic Approach to Rule Analysis in Expert Database Systems. In: Proceedings of the 20th VLDB Conference, pp. 475-486, 1994 6. Baralis, E., Ceri, S., Paraboschi, S.: Modularization Techniques for Active Rules Design. ACM Transactions on Database Systems 2l(l), 1-29 (1996) 7. Baralis, E., Ceri, S., Paraboschi, S.: Compile-Time and Runtime Analysis of Active Behaviors. IEEE Transactions on Knowledge and Data Engg. 10(3), 353-370 (1998) 8. Bassiliades, N., Vlahavas, I., Elmagarmid, A.: E-DEVICE: An Extensible Active Knowledge Base System with Multiple Rule Type Support. IEEE Transactions on Knowledge and Data Engg. 2(5), 824-844 (2000) 9. Bieber, M., et al.: Towards Knowledge-Sharing and Learning in Virtual Professional Communities. In: Proceedings of the 35th Annual Hawaii International Conference on System Sciences, pp. 2843-2852, 2002 10. Boley, H., Kifer. M.: RIF Core Design. W3C Working Draft, 2007. Accessed March 2007, http://www.w3.org/TR/rif-core/ 11. Booth, D., et al. (eds.).: Web Services Architecture. W3C Working Group, 2004. Accessed May 2005, http://www.w3.org/TR/2004/NOTE-ws-arch-20040211 12. Brownston, L., Farrell, R., Kant, E.: Programming Expert Systems in OPS5. Addison-Wesley, Massachusetts (1985) 13. Buchmann, A., et al.: DREAM: Distributed Reliable Event-Based Application Management. In: Levene, M., Poulovassilis, A. (eds.), Web Dynamics, Springer-Verlag, pp. 319-352, 2004 14. Cabrera, L., Jones, M., Theimer, M.: Herald: Achieving a Global Event Notification Service. In: Proceedings of the Eighth Workshop on Hot Topics in Operating Systems, pp. 87-92, 2001

PAGE 152

152 15. Caldwell, N. et al.: Web-Based Knowledge Management for Distributed Design. IEEE Intelligent Systems 15(3), 40-47 (2000) 16. Carzaniga, A., Rosenblum, D., Wolf, A.: Achieving Scalability and Expressiveness in an Internet-Scale Event Notification Service. In: Proceedings of the 19th ACM Symposium on Principles of Distributed Computing, pp. 219-227, 2000 17. Ceri, S., Widom, J.: Deriving Production Rules for Constraint Maintenance. In: Proceedings of the 16th VLDB Conference, 566-577, 1990 18. Chen, H., et al.: COPLINK: Managing Law Enforcement Data and Knowledge. Commun. ACM 46(1), 28-34, (2003) 19. Couchot, A.: Termination analysis of active rules modular sets. In: Proceedings of the International Conference on Information and Knowledge Management, pp. 326-333, 2001 20. Cover, R. (ed.).: Business Rules Markup Language. Cover Pages, 1998. Accessed May 2005, http://xml.coverpages.org/brml.html 21. Cover, R. (ed.).: Simple Rule Markup Language. Cover Pages, 2001. Accessed May 2005, http://xml.coverpages.org/srml.html 22. Dhamankar, R. et al.: iMAP: Discovering Complex Semantic Matches between Database Schemas. In: Proceedings of the ACM SIGMOD Conference, pp. 383-394, 2004 23. Filho, R., De Souza, C., Redmiles, D.: The Design of a Configurable, programmable and Dynamic Notification Service. In: Proceedings of the 2nd International Workshop on Distributed Event-Based Systems, pp. 1-8, 2003 24. Friedman-Hill, E.: Java Expert System Shell. Sandia National Laboratories, 2007. Accessed May 2005, http://www.jessrules.com/jess/index.shtml 25. Gandon, F., Sheshagiri, M., Sadeh, N.: Rule Language in OWL. Carnegie Mellon University, 2004. Accessed May 2005, http://mycampus.sadehlab.cs.cmu.edu/public_pages/ROWL/ROWL.html 26. Ginsberg, A., et al. (eds.).: RIF Use Cases and Requirements. W3C Working Draft, 2006. Accessed Jan 2007, http://www.w3.org/2005/rules/ 27. He, B., Chang, K.: A holistic paradigm for large scale schema matching. In: Proceedings of the ACM SIGMOD Conference, pp. 20-25, 2004 28. Heimrich, T., Specht, G.: Enhancing ECA Rules for Distributed Active Database Systems. In: Proceedings of Web, Web-Services, and Database Systems, pp. 199-205, 2002 29. Hill, M., et al.: Required Fields for the NPDN National Database, NPDN Handout, July 2006

PAGE 153

153 30. Hirtle, D., et al.: Schema Specification of RuleML 0.91. The Rule Markup Initiative, 2006. Accessed Jan 2007, http://www.ruleml.org 31. Horrocks, I., et al. SWRL: A Semantic Web Rule Language Combining OWL and RuleML. Defense Advanced Research Projects Agency, 2003. Accessed May 2005, http://www.daml.org/2003/11/swrl/ 32. Hovy, E., Philpot, A. Falke, S.: Automating the Integration of Heterogeneous Databases. In: Proceedings of the National Conference on Digital Government Research, pp. 24-26, 2004 33. ILOG Inc.: ILOG JRules. ILOG, 2007. Accessed May 2005, http://www.ilog.com/products/jrules/ 34. Iowa State University, Iowa Soybean Association and Iowa Soybean Promotion Board, Iowa Department of Agriculture and Land Stewardship, & United States Department of Agriculture Animal and Plant Health Inspection Service Plant Protection and Quarantine, Iowa Response and Action Plan for Asian Soybean Rust, Draft 1.5, 2004 35. Kantere, V. et al.: Coordinating Peer Databases Using ECA Rules. In: Proceedings of the International Workshop on Databases, Information Systems and Peer-to-Peer Computing, pp. 108-122, 2003 36. Kantere, V., Mylopoulos, J., Kiringa, I.: A Distributed Rule Mechanism for Multidatabase Systems. In: Proceedings of the International Conference on Cooperative Information Systems, pp. 56-73, 2003 37. Karadimce, A., Urban, S.: Refined Triggering Graphs: a Logic-Based Approach to Termination Analysis in an Active Object-Oriented Database. In: Proceedings of the Intl. Conf. on Data Engineering, pp. 384-391, 1996 38. Kolber, A., et al.: Defining Business Rules What Are They Really? Business Rules Group, 2000. Accessed May 2005, http://www.businessrulesgroup. org/first_paper/BRG-whatisBR_3ed.pdf 39. Krishnamurthy, B., Rosenblum, D.S.: Yeast: A general purpose Event-Action System. IEEE Transactions on Software Engineering 21(10), 845-857 (1995) 40. Lee, J., Sohn, M.: Enhanced Knowledge Management with eXtensible Rule Markup Language. In: Proceedings of the 36th Hawaii International Conference on System Sciences Hawaii, 8 pp., 2003 41. Lee, M., Su, S Y. W., Lam, H.: A Web-based Knowledge Network for Supporting Emerging Internet Applications. WWW Journal 4(1/2), 121-140 (2001) 42. Lee, S., Ling, T.: Unrolling Cycle to Decide Trigger Termination. In: Proceedings of the 25th VLDB Conference, pp. 483-493, 1999

PAGE 154

154 43. Linehan, M., and Ferguson, D.: Business Rules Standards Interoperability and Portability. In: Proceedings of the W3C Workshop on Rule Interoperability, 7 pp., 2005 44. Loucopoulos, P., Katsouli, E.: Modelling business rules in an office environment. ACM SIGOIS Bulletin 13(2), 28-37 (1992) 45. McGuinness, D., Van Harmelan, F. (eds.) .: OWL Web Ontology Language, W3C Recommendation, 2004. Accessed May 2005, http://www.w3.org/TR/owl-features/ 46. Matena, V., et al.: Applying Enterprise JavaBeans, 2nd Ed. Addison-Wesley, Massachusetts (2003) 47. Merali, Y., Davies, J.: Knowledge Capture and Utilization in Virtual Communities. In: Proceedings of the First International Conference on Knowledge Capture, pp. 92-99, 2001 48. MySQL AB.: MySQL Server 5.0. MySQL AB, 2005. Accessed Jun 2005, http://dev.mysql.com/downloads/mysql/5.0.html 49. National Plant Diagnostic Network (NPDN), 2002, http://www.npdn.org 50. National Plant Diagnostic Network.: The National Plant Diagnostic Network Standard Operating Procedure for APHIS-PPQ Pest of Concern Scenario General SOP, June 2005 51. Nonaka, I., Takeuchi, H.: The Knowledge Creating Company. Oxford University Press, New York (1995) 52. Pantel, P., Philipot, A., Hovy, E.: Aligning Database Columns using Mutual Information. In: Proceedings of the National conference on Digital Government Research, pp. 205-210, 2005 53. Preece, A. et al.: KRAFT: An Agent Architecture for Knowledge Fusion. International Journal on Intelligent Cooperative Information Systems 10(1/2) 171-195 (2001) 54. Production Systems Technologies.: OPS/J. Production Systems Technologies, 2003. Accessed May 2005, http://www.pst.com/opsj.htm 55. Riley, G.: C Language Integrated Production System. CLIPS Expert System Group, 2007. Accessed May 2005, http://www.ghg.net/clips/CLIPS.html 56. Rosenberg, F., Dustdar, S.: Business Rules Integration in BPEL A Service-Oriented Approach. In: Proceedings of the 7th International IEEE Conference on E-Commerce Technology, pp. 476-479, 2005 57. Rosenberg, F., Dustdar, S.: Towards a Distributed Service-Oriented Business Rules System. In: Proceedings of the 3rd European Conference on Web Services, IEEE, pp. 14-24, 2005 58. Rouvellou, I., et al.: Combining Different Business Rules Technologies: A Rationalization. In: Proceedings of the OOPSLA 2000 Workshop on Best-practices in Business Rule Design and Implementation, 2000

PAGE 155

155 59. Rowstron, A,. et al.: SCRIBE: The Design of a Large-scale Event Notification Infrastructure. In: Proceedings of The 3rd International Workshop on Networked Group Communication, pp. 30-43, 2001 60. Schlimmer, J. (ed.).: Web Services Description Requirements. W3C Working Draft, 2002. Accessed May 2005, http://www.w3.org/TR/ws-desc-reqs 61. Southern Plant Diagnostic Network (SPDN), 2002, http://spdn.ifas.ufl.edu 62. Sowa, J.: Knowledge Representation: Logical, Philosophical and Computational Foundations. Brooks Cole, California (2000) 63. Stack, J. et al.: The National Plant Diagnostic Network. Plant Disease 90(2), 128-136 (2006) 64. Su, S.Y.W., et al.: An Internet-based Negotiation Server for E-Commerce. VLDB Journal 10(1), 72-90 (2001) 65. Su, S.Y.W., et al.: Transnational Information Sharing, Event Notification, Rule Enforcement and Process Coordination. Intl. J. of Electronic Government Research 1(2), 1-26 (2005) 66. Sun Microsystems.: The Sun Java System Application Server. Sun Microsystems, 2005. Accessed May 2005, http://developers.sun.com/prodtech/appserver/index.html 67. Tidwell, D.: UDDI4J: Matchmaking for Web services. IBM Inc., 2001. Accessed May 2005, http://www-128.ibm.com/developerworks/webservices/library/ws-uddi4j.html 68. Todd, J. (ed.).: Sudden Oak Death. United States Department of AgricultureCooperative State Research Education and Extension Service, 2004. Accessed May 2005, http://www.aphis.usda.gov/plant_health/plant_pest_info/pram/downloads/pdf_files/nationalpestalert_.pdf 69. Tucker, J.: Historical Trends Related to Bioterrorism: An Empirical Analysis. Emerging Infectious Diseases, Centers for Disease Control and Prevention, 5(4), 498 504 (1999) 70. Ullman, J.: Principles of Database Systems, 2nd Ed. Computer Science Press, Maryland, (1982) 71. Ullman, J.: Principles of Database and Knowledge-Base Systems, Vols I and II. Computer Science Press, Maryland (1988) 72. U.S. Congress.: Office of Technology Assessment, Harmful Non-Indigenous Species in the United States, OTA-F-565 Washington, DC, U.S. Government Printing Office, 3-5, 1993 73. Viens, S., et al.: The Apache jUDDI Project. Apache Software Foundation, 2003. Accessed Jun 2005, http://ws.apache.org/juddi/ 74. Wagner, G.: The Agent-Object-Relationship Metamodel: Towards a Unified View of State and Behavior. Inf. Syst. 28(5), 475-504 (2003)

PAGE 156

156 75. Warmer, J., Kleppe, A.: The object constraint language: precise modeling with UML. Addison-Wesley Longman, Massachusetts (1998) 76. Wenger, E.: Communities of practice: The social fabric of a learning organization. Cambridge University Press, New York (1998) 77. White, S., Sleeman, D.: A Grammar-Driven Knowledge Acquisition Tool that Incorporates Constraint Propagation. In: Proceedings of the International Conference On Knowledge Capture, pp. 187-193, 2001 78. Widom, J., Ceri, S.: Active Database Systems, Triggers and Rules for Advanced Database Processing. Morgan Kaufmann, California (1996) 79. Yu, C., and Popa, L.: Semantic Adaptation of Schema Mappings when Schemas Evolve. In: Proceedings of the 31st VLDB Conference, pp. 1006-1017, 2005 80. Zhang, N., Zhao, W.: Distributed Privacy Preserving Information Sharing. In Proceedings of the 31st VLDB Conference, pp. 889-900, 2005

PAGE 157

157 BIOGRAPHICAL SKETCH Seema Degwekar was born in Thane, India on November 10, 1978. She received her Bachelor of Engineering Institute of Technology, affiliated with University of Mumbai, in June 2000. She joined the Computer and Information Science and Engineering (CISE) graduate program at the University of Florida in August 2000. She has been a part of the Database Research and Development Center from August 2001. She graduated in December 2002 with a Master of Science in Computer Engineering. At University of Florida, she has worked as a research assistant, a teaching assistant, and has taught an undergraduate course for around two years. She is graduate student association. She is also the recipient of the Outstanding International Student award from the College of Engineering for her academic achievements, and the Alec Courtelis award in recognition of academic excellence and University and community service. Her research areas include event and rule based systems, knowledge management and sharing, distributed computing, indexing large databases, web services, peer-to-peer systems, XML and web databases.


xml version 1.0 encoding UTF-8
REPORT xmlns http:www.fcla.edudlsmddaitss xmlns:xsi http:www.w3.org2001XMLSchema-instance xsi:schemaLocation http:www.fcla.edudlsmddaitssdaitssReport.xsd
INGEST IEID E20101206_AAAAEC INGEST_TIME 2010-12-06T20:53:02Z PACKAGE UFE0021359_00001
AGREEMENT_INFO ACCOUNT UF PROJECT UFDC
FILES
FILE SIZE 1053954 DFID F20101206_AACHFO ORIGIN DEPOSITOR PATH degwekar_s_Page_105.tif GLOBAL false PRESERVATION BIT MESSAGE_DIGEST ALGORITHM MD5
0956b71f867bbf972a73071d038547a9
SHA-1
7bfcd2d00ee0fe44cb780a2ad43697cfebe5d586
118067 F20101206_AACGZU degwekar_s_Page_065.jp2
b5cd8179d80e781b3197da00170d964c
3ecf15f51d005a3029ea1a227129db85e8618079
F20101206_AACHGD degwekar_s_Page_125.tif
7c300ae7756c8b1e9c5060e37d909db4
ee3e483a29658a31b1b714c01e3af36518e3797a
F20101206_AACHFP degwekar_s_Page_106.tif
a608ce35f9a05571b7e7b080b9f2258b
207038643753df5299d183591c52907f6a00c084
120546 F20101206_AACGZV degwekar_s_Page_068.jp2
4dd55f85bf7057ee0536b60bcb953eb5
72f7b846fd5f563d2db6aa94a743930b1bd0356f
F20101206_AACHGE degwekar_s_Page_127.tif
09846bbe3efb7f81dccd7d33f82c2f63
d2afdd3294fdfbc091aa8056a544d63a5a02f3e7
F20101206_AACHFQ degwekar_s_Page_108.tif
855d16501a960f55a0a4286f20626959
6be4a2d18d12e7f25b593ff1578b35d6663d44c2
103023 F20101206_AACGZW degwekar_s_Page_071.jp2
11954a0b3c432425072179334f3c8702
9e99608ae79e44ea2d6305fdd055062933b0a9f0
F20101206_AACHGF degwekar_s_Page_128.tif
19fe71dd9432410682e522e952379347
be4de98ab25df065d4c5327def3f1bd9d55608f5
F20101206_AACHFR degwekar_s_Page_109.tif
35b34e73a477a0e51a76ebbf9dabebb3
76e49a8679994b5417088d2b2abf1d54dbfad8db
133081 F20101206_AACGZX degwekar_s_Page_072.jp2
deac955100f6bbd52f550a06a932d3f8
30b6e628f52cb7f85034835a1a6e6bd07c9a1af5
F20101206_AACHGG degwekar_s_Page_129.tif
3a9252b82f0e68d9b48dc89f2b22d139
e97636564f9101dd8d35b03199bf59a5e1a043f4
F20101206_AACHFS degwekar_s_Page_110.tif
6b525c6d031d92f83957db8a4acabd94
74c3117185ca1f4c55793616e121edacc728a191
70921 F20101206_AACGZY degwekar_s_Page_075.jp2
72a6c44ec3fc69573ffa1b04824d4ac7
ea4e38caf4f434f2fde4780da7987cb956134d07
F20101206_AACHGH degwekar_s_Page_130.tif
1f7aa48066e8fbd7478c3c18d2d8cb55
c1b0c4c181e9e7dca894e71ca5270931943a2ef3
F20101206_AACHFT degwekar_s_Page_111.tif
5527ee6e9504974dee754fddf5dfb97e
c1b6ee4019218ee4f69f86d821ae9c9eaa4fadbd
36142 F20101206_AACGZZ degwekar_s_Page_076.jp2
eb88e7573f5d8d81b0f2c95f97e6e801
f47ceb7fdc52cd91230b5f8c44abdff71ec74f5f
F20101206_AACHGI degwekar_s_Page_133.tif
786de52a80957068c1c96b12183918fd
314b4b4d00520e7e63863ad764d8be979007f9b8
F20101206_AACHFU degwekar_s_Page_112.tif
f57e5bb824777963ff966b1d1458c740
f1f1b9ef332351bd62cc62d768196224e7727361
F20101206_AACHGJ degwekar_s_Page_134.tif
b18d9ab1ab6351189c2f96db3a981282
8dfbacd52e1d08e154c774a6f83ecd407db860e3
F20101206_AACHFV degwekar_s_Page_113.tif
18518720a34e09fec5bbe789d560ddda
6f12223534f7ded2a52f9ac5414ac8d86cc88b49
F20101206_AACHGK degwekar_s_Page_137.tif
d26238fe0822be1345a12c93b502a207
892284a0dac9240be3e73dd65a7c9904ea86ec2d
F20101206_AACHFW degwekar_s_Page_114.tif
7358543980a37ec5e358c741e1828259
710575153d8bb0eb5f3b9fe005594265ccd8c6ea
F20101206_AACHGL degwekar_s_Page_139.tif
9117e6d4ecf6ca7101d7b0c5235686b2
e274c875b2a31ceed2706a5052af64d7bbce2a9b
F20101206_AACHFX degwekar_s_Page_116.tif
9e0e6cc0ae47baa4b33e0112b3c4e58a
f433c7a91a6786ee4135d1bc107fac1e4084e26a
1248 F20101206_AACHHA degwekar_s_Page_003.pro
a0cecc36c721625f1911cc9889783348
7955886645f908a3f516f1e4aef7b27b68f2c8c4
F20101206_AACHFY degwekar_s_Page_117.tif
b6768f7352dbf614ce353a1051373b72
7f1cfdc5c940b67efa1234f209debdda1047c4e2
51221 F20101206_AACHHB degwekar_s_Page_004.pro
a47d60fa7a482e6b3ddcae4aa341f7b7
a0c4344521fa9c7ab9a0f683f1043f1db09d302b
F20101206_AACHGM degwekar_s_Page_140.tif
29fcad96bb42080e1e394df2d7ec905c
78bf2b2d948fe02e7b7b7740ede0dbb9cec5f6dd
10642 F20101206_AACHHC degwekar_s_Page_005.pro
d7321498b38bea98b5976ec2e830aa5f
337e709041c4d26167cb881c21eae4e68afe1823
F20101206_AACHGN degwekar_s_Page_141.tif
c5fae182aeb76d2ab82e688a1d3dd2a7
51b84724ecabe5b83d4133031af4f6e070cb3e37
F20101206_AACHFZ degwekar_s_Page_119.tif
8dc3a6079127f3cdc359269eadbb0e78
06f46f9221b60c7fc3c2da7db2167ccf6ba78a02
78319 F20101206_AACHHD degwekar_s_Page_006.pro
b285f75bef5a98da32fbd885d1cdea1c
268725360d4d6746da64b071e3ee1df6a15d1698
F20101206_AACHGO degwekar_s_Page_143.tif
05c51df6a115baa1ac457851c01a9538
37a7358029685f9f0c8b03f5d71ef77cfddeba57
8647 F20101206_AACHHE degwekar_s_Page_009.pro
eae138948a41eb700f9fea20ea9d50a2
964f962ff622afefbbd5ea5af6ad0052e1685a67
F20101206_AACHGP degwekar_s_Page_144.tif
db5e41d0611946a3333c677ce41ccfe6
55009aed65554af5b1df36d82f9c237b4e6fe7fc
33645 F20101206_AACHHF degwekar_s_Page_010.pro
5e835b646071c44d1a19ebbf0319deec
42ffe7e03f227b31f96a5de127a8f0983dd50163
F20101206_AACHGQ degwekar_s_Page_145.tif
f0a39bae1c6c6aa0c613ff5322953848
7a4546f38bf001e343865f3ae3a58f9e5d899552
23421 F20101206_AACHHG degwekar_s_Page_012.pro
04a3777863fc0b9d381f79e065760e86
1edfd8a4e320cad3690a8ed73523c94c7c6a7879
F20101206_AACHGR degwekar_s_Page_146.tif
48217a04c7cd76fc68612bb23cb6e5e9
b0dcb2d20f61b2a53138d5cbed08e96cdca1b936
50886 F20101206_AACHHH degwekar_s_Page_013.pro
3d41735bc13903e55fbe70ed478376c0
6b73ac26d639db327897d3bcfbcf6e0fe0f157ef
F20101206_AACHGS degwekar_s_Page_150.tif
6f16c3eb7001a573a3cbbbd9a642cb7a
da77f2fab4723de621cb450afb225b1ec814230d
52086 F20101206_AACHHI degwekar_s_Page_014.pro
7285fa36d55d0e0422c6b6319a6996d6
c85e223e25ff0f217b6ecf5ad233f230951389b5
F20101206_AACHGT degwekar_s_Page_151.tif
798d97ccb4bedb2dd3e77cc12b16a0f3
fb533b69d21f514d0ba6a624aa7be30e9035534e
56293 F20101206_AACHHJ degwekar_s_Page_015.pro
2aefd6df09f378c7a1a1e6e250cfc98f
ff733313b46d175f501f903c2aeb0b0702dcd731
F20101206_AACHGU degwekar_s_Page_152.tif
45358a4282ecd2afa52b4d2cbe9b6046
1ea48518c5079f6a6337984a5d23c2cdef0bc9ff
56026 F20101206_AACHHK degwekar_s_Page_017.pro
1e4d74d91c6528781f88f475184b5020
53b49c60e39848b71199e7746fbc33450e84ed4f
F20101206_AACHGV degwekar_s_Page_153.tif
87f36547eb1861015d4606e85199cd2d
ebfef719446504bd7de861e0ef0fbaf7fa46aefe
20397 F20101206_AACHHL degwekar_s_Page_018.pro
0df8794432a76aefcbef58c38bd3849f
2bc80c427870dbfc12275777a3307058809c5641
F20101206_AACHGW degwekar_s_Page_154.tif
faea39334e491fde93455b81f52d1981
8ac1e5a94ef836ffcf0f3a4b0813f581075a33ea
41457 F20101206_AACHHM degwekar_s_Page_019.pro
b2854353127e4018e4e72eabfe4140f4
d32c7cf5e08746d995646e95f8bfb91a7c9656ae
F20101206_AACHGX degwekar_s_Page_155.tif
daa2a4801c12ef555d6110f99be0859a
6c2ad51632392eec5dbc21794ff070b291e57832
52915 F20101206_AACHIA degwekar_s_Page_036.pro
3ff1cb948814bb3721a08f592be59a39
22d94e5e1bbfb84050035a621ea44baccca5ad0a
8664 F20101206_AACHGY degwekar_s_Page_001.pro
ee9897aebbda28250a93ff06fef22dc8
b6870e378646b4698ed393f9033aa62eb954fd0e
24445 F20101206_AACHIB degwekar_s_Page_039.pro
37d6a3bfab192422936f8810932f1422
15284ccdcaf78f1a4e814cd39f58ab5875ef4e31
48822 F20101206_AACHHN degwekar_s_Page_020.pro
72623fc9a3af496f14ff42f9b8aa09ac
474e2f03cb545e14757c472d6ee06705af472504
832 F20101206_AACHGZ degwekar_s_Page_002.pro
49d214e95ae53f51637e07a996cf9843
b1f9426885f63b8f1863ab0cb8770aea826a2b3b
31810 F20101206_AACHIC degwekar_s_Page_040.pro
d535bf62bdb4a4051a66dad71da248f7
6e051107d5fe6696c33975e31331eea4271fcc2e
49385 F20101206_AACHHO degwekar_s_Page_021.pro
7f6040ce9b1532bc235d3163af64580a
c0fbbfebed2345f69a13632ca56b9496d6fc96b2
41093 F20101206_AACHID degwekar_s_Page_041.pro
124b8f1fb209be2547c33b88f3a787b1
980ab048b9d3477268404e2d6b4311a30fa1949c
56617 F20101206_AACHHP degwekar_s_Page_022.pro
338262af902f3be71bc7e710750a4d46
e36c8d908162dc288f55a7e256f50bbc4413926f
55233 F20101206_AACHIE degwekar_s_Page_042.pro
d44b473b4023a96864416108a4ff2a10
d1a6b952c208035ff4cbf7c8361be11578165dbc
52243 F20101206_AACHHQ degwekar_s_Page_023.pro
f72b64aa42ade2cc709fb1cb644cbbd8
2aeaa4fc4a4d25056a794e87b3130bc055713617
31909 F20101206_AACHIF degwekar_s_Page_043.pro
86da98ec7720f1d6076edb2d3759281c
d6e667af567888d5b32fdd3df43615170b4cdf0f
57082 F20101206_AACHHR degwekar_s_Page_024.pro
71632ac8b548a459460a137653cb6f37
7588f89c2e678c9d8a94d9e2aa9c017bff814b9c
24088 F20101206_AACHIG degwekar_s_Page_044.pro
ec895ff31ef458a78c3851af4de3b5df
1665e6d77559964a06e5ec072bbcc92883bd0b8b
54929 F20101206_AACHHS degwekar_s_Page_025.pro
b0a7bde4592abdf00a84f07f025a47aa
f6ac07bc23eb74f811a728edcb392329a2b1bd6e
27506 F20101206_AACHIH degwekar_s_Page_045.pro
641d35d3532348e768fd50f643e3afac
2e7055aef8af1f18eb445b9416c498f0c506fa50
36560 F20101206_AACHHT degwekar_s_Page_026.pro
11d9c85e0763332420d9be3cf55259e9
e76d618d061185f305e24e530d2e3da10fd8dcd7
42755 F20101206_AACHII degwekar_s_Page_046.pro
956867f4084dda26df7fefd5b7715f59
f5d398c6eb9733e155d67c691404b9b90e23aeca
53063 F20101206_AACHHU degwekar_s_Page_027.pro
de9b7cb34d93753b8bfe3bf04fecf4d7
a76a2af23b7ef8b103dc7a786b0b98e41dcb840e
38618 F20101206_AACHIJ degwekar_s_Page_047.pro
04a844842849128d6a7376b5a3614480
80a9801e5ff7eca4eceae3c7c1efb53145f39916
48329 F20101206_AACHHV degwekar_s_Page_028.pro
d2234ab2d731c462bfae51fd08dc9c19
25cebad910326070ee536c5d5ddead5dde9ec8db
4692 F20101206_AACHIK degwekar_s_Page_048.pro
043896a1b0b920bd9b4580b83bc7eaf8
4422470ae104b031c80a17832191e63410c45292
39474 F20101206_AACHHW degwekar_s_Page_031.pro
56e9fb4df0a83edb50357f3925956cff
9a9da3d592711d4c06d9f6cb737267c2949afd41
49078 F20101206_AACHIL degwekar_s_Page_049.pro
f6f62d1fc159fde876e2ff494aa8d410
267e27fefbc66329ac7521443b8ae9839b537d69
43473 F20101206_AACHHX degwekar_s_Page_032.pro
21e238c8607b1f6369af76ea0f6e1b69
8a9caa7615656688c1972d7d9b17b570e317a1f7
62922 F20101206_AACHJA degwekar_s_Page_072.pro
c616657f9a887e1d3912efeafe4e8cc9
250811e4cd09654871f9eaf27605c37d721f7fa9
51471 F20101206_AACHIM degwekar_s_Page_050.pro
a07f0cee01aa3a7ac37ca7ba9f860779
dcfc492bfa6e31e96ab655586a3613a3245a6538
47656 F20101206_AACHHY degwekar_s_Page_033.pro
2aca59c62c8b2169a40c5d4d85b419ed
73a83375f1458523825be9676d8b903cad6ae884
55061 F20101206_AACHJB degwekar_s_Page_073.pro
939a498be5973a31b4d8a75e187909d6
3f74c873a974b27439176fee5e8acec5bda7cd62
54216 F20101206_AACHIN degwekar_s_Page_053.pro
dcba72254d6e7eca690db5489eed6832
ebf1dbf9da6d42dcf00d5c299beb15cb0a2265ba
49365 F20101206_AACHHZ degwekar_s_Page_035.pro
b56ea202fa007df1e83bb76b6c076648
07c5d2efdb6642ae4919ad034a8d50e5a9ed15c2
51404 F20101206_AACHJC degwekar_s_Page_074.pro
7ba6c13d79cfad4a49e73a1bfd925d45
334b4d92a57de53202473c99064d52cf45d5c242
25513 F20101206_AACHJD degwekar_s_Page_075.pro
ab6ff7aa5da292bc3836bc2f79a0b5ef
5007d4fb07f3280688de785b0d59150b3765a27d
10574 F20101206_AACHIO degwekar_s_Page_055.pro
f6a76a52e96cd5b74ba47f4bc6a625a4
a290b109d268eaeda658e19af22838e5def05cda
1820 F20101206_AACHJE degwekar_s_Page_076.pro
1730bd3a2be3e39515e8f0a7157c157d
f129b7abbf3a749b9d6e6ec0f981478b4e08be13
29823 F20101206_AACHIP degwekar_s_Page_057.pro
d1ca3f5c28f981c38d8b923172240e00
1170c3a8c3a5b4a5f4fc958b7b12c2533962cbee
10954 F20101206_AACHJF degwekar_s_Page_077.pro
2afc1afc86a34917aa2b861d662ee0bc
928c99582324ad2324d5153e1daa89a01210c9d4
37735 F20101206_AACHIQ degwekar_s_Page_058.pro
391bf535913215e708b0f2b0ffed094b
e7941ea43adb99bee351eb6748c79fa455cd150f
53109 F20101206_AACHJG degwekar_s_Page_078.pro
44fd4f05be52d71fda62746ae70cd575
e5657ba25aff44f402940ddcffa76b86f53fbbbc
43432 F20101206_AACHIR degwekar_s_Page_059.pro
d962907f87f4d4bd83eebfd3a65beec8
ad4fb00340766aa4939632d2ba6d655ca41f910c
42095 F20101206_AACHJH degwekar_s_Page_079.pro
684016889bb84ab7b1e7c9f688827a62
4f5ff7a74a4e386bcc5b5422000747088337285e
54774 F20101206_AACHIS degwekar_s_Page_061.pro
72fd7bbf0f415728fc5807a7c706a192
6c3839add79796d1117dbccbbabe6299331cb83c
57322 F20101206_AACHJI degwekar_s_Page_080.pro
696dad78ec060e55ca649d43ddf71c41
287742357e3a8dbf24e46ca34e4ef3908a6789d9
24766 F20101206_AACHIT degwekar_s_Page_062.pro
7b0c568ed86e5dbb1b020fb33b0e456a
9bf992b233e4fe1b4545b049b52887792a29795e
49126 F20101206_AACHJJ degwekar_s_Page_082.pro
199bcd56fa96e53370a7ff382ce49112
788917d3200e3bb2d8aba855cf998ac0f2425d60
55046 F20101206_AACHIU degwekar_s_Page_065.pro
07b18368e6e4032ded45c804ec7592ec
9992c6ad6fdc51159a7784d96697a6d5bb3df603
56108 F20101206_AACHJK degwekar_s_Page_084.pro
dc3eba88942613646c456b00b82cbb8f
e3105a9830fda59b8cb403c69f190147bbd522f0
59193 F20101206_AACHIV degwekar_s_Page_066.pro
cf78d20f8090042afd795d45d4370800
f50125ce0f93accdb04a34865d77b75c8b49f095
46967 F20101206_AACHJL degwekar_s_Page_085.pro
252ba261fa977a4886f562edab9aca5c
754f6bc74b482c5a14486bd2a9c8045ac57c7abc
52990 F20101206_AACHIW degwekar_s_Page_067.pro
aa401769b8f7d37eb60763606ab6960f
07d2f61352bb22bb894194b92c2d82dd423dd60c
28236 F20101206_AACHKA degwekar_s_Page_107.pro
ba3f51b3baf161ccd9583dee8515101c
f1da489912dc860f94fbef0dba34cb8c5159ccb2
51013 F20101206_AACHJM degwekar_s_Page_086.pro
5e7c4b906918c18cf5e033d548adbd33
5d489cc4f0a6780d991c7d5b37008889cbbfcd3a
56688 F20101206_AACHIX degwekar_s_Page_068.pro
f5788384feb51cfd475a11b165aab762
f6b165b0242cec55bee7cace0dd3eab6d72d6b0c
39335 F20101206_AACHKB degwekar_s_Page_109.pro
563cc44f2941b5a0ae990391eaf7e4a0
f9967c00d300a0d7e585e101a82033e7e795176a
52126 F20101206_AACHJN degwekar_s_Page_088.pro
a0e745e366a1a5fe4507c99a2bf11303
80959a704d9a65a08c0aff71629cc2760c4d3ed2
57055 F20101206_AACHIY degwekar_s_Page_070.pro
3797ddeed15f8f17fcd338dae6b58686
f53b4c3867f3d6c107ffc5b46da631b7996ecfe3
37276 F20101206_AACHKC degwekar_s_Page_110.pro
1e595c1b6bbcfdd2f2ddf7a716bd3dfb
af4ef4f28aa9b0d0db5e2fcf5b9c3ff6d3267b8c
69857 F20101206_AACHJO degwekar_s_Page_089.pro
1dc17596818c04e0be903fd34f3e7e84
b11acb7f41816d894d4edc53d27cb29178d4af81
47488 F20101206_AACHIZ degwekar_s_Page_071.pro
b5be056feca8569d4e6754da7f3af142
f651203c36533eb28c1abd297b361718f4c38f86
33468 F20101206_AACHKD degwekar_s_Page_111.pro
e4925768a44a190713b6839e6aa22284
82f56dcb00c7f33372711a6a8d253bc10673f034
4147 F20101206_AACHKE degwekar_s_Page_112.pro
41c889ac4a435e65f4d1e875b3e69b96
9f871c210ec50dfdda1ba636aea5d1c905ef14fa
33638 F20101206_AACHJP degwekar_s_Page_090.pro
47347503c482a03f9c893cc0d2b59c59
8b4c23b4e56e4ed7ebae0727ab48f96603e42849
51829 F20101206_AACHKF degwekar_s_Page_113.pro
27a9a1e8f3af3c7548266bf00bf27cdd
18f654f433d50cc94713b8701eb03ea6abb0701a
28758 F20101206_AACHJQ degwekar_s_Page_091.pro
5ea3463b8c50f8d18b7c0fd3588aa198
3492f9ab4f641dc5f12a48e708b08d5379fa6059
52731 F20101206_AACHKG degwekar_s_Page_114.pro
caddc0144c1d1542897894e0595664e9
3af0729968b9d12928611e8f9dd4313a37a16091
22711 F20101206_AACHJR degwekar_s_Page_092.pro
8a84934a0419f280d59887be279cb434
b7e274e20926db80af5463d3649c9cc6ad7a27a4
49762 F20101206_AACHKH degwekar_s_Page_116.pro
34e0b515b831e0bacc1f1ca61befda38
dfc02bd245bc5c66c778d8876e906061a556ed8c
33634 F20101206_AACHJS degwekar_s_Page_093.pro
47daee77a5beac2d97ba8a3899ad3a1b
25dffa1c47ef224e6668decf15b9f56805ec2dc9
42538 F20101206_AACHKI degwekar_s_Page_118.pro
4cc50139f15de457e23ad8a8da8079cd
f56a698a83bee1a74a0bac5dcc7fbab5fe9af0bb
64655 F20101206_AACHJT degwekar_s_Page_094.pro
8a563d1fc46a6a0aa52106167c9c96c1
64bce4cd098eb91e4483ab1499625e28938b755b
51978 F20101206_AACHKJ degwekar_s_Page_119.pro
3ae19d6d1ac6dbfe6f6647a4ae25e012
9098ac3f021ad0c6fe184b07730cbc3f28e8dad7
41007 F20101206_AACHJU degwekar_s_Page_096.pro
d7d24020486ffa98c19802d49d22e24b
006faf79a7b9128fd36298f0655b33e1a4ca625f
55997 F20101206_AACHKK degwekar_s_Page_120.pro
a40e82cc975940b688715b8bd2c8ca1c
a939c826def7ce953559e0cdd4b1d2f830716f26
37093 F20101206_AACHJV degwekar_s_Page_097.pro
ca313ed6e845143cc60c59f951a3dfcc
04cdc1f53f824927039e2d651134f15fbe57d165
49036 F20101206_AACHKL degwekar_s_Page_121.pro
c34ad5fe9a43dcd99c5095506be7de33
bdb3a4fbc9fe134a8e375ebc81aeb02a6eef9310
32403 F20101206_AACHJW degwekar_s_Page_098.pro
bd54098e2e8a0daf1f45ac7adf794445
676640817bc9107e279b2dd603a6f360e6862995
57597 F20101206_AACHKM degwekar_s_Page_123.pro
5cd32c08591b59581014f7fc600b4a34
5567cb82f0109a2237a8a05d88e15cda16d18ba6
28198 F20101206_AACHJX degwekar_s_Page_099.pro
4e744b0487668a323e0acf02c70f8227
9f18046424300dad636c5d99d0f67e000c6780f8
55278 F20101206_AACHLA degwekar_s_Page_139.pro
381918d900052443203c08610bf9c2fd
171303d17ecb7b085fbdf2f1504421c49bd0a137
48486 F20101206_AACHKN degwekar_s_Page_124.pro
39b72d96a5e7f2f2fe7f8be2c0a7051f
2b8cea9293ea120284378c0740b32cd380560586
34229 F20101206_AACHJY degwekar_s_Page_100.pro
e240e93f62710a570a696fa8ae55104f
7e78249232d99b3ea2517aa550fb41b8ecbe46ba
77705 F20101206_AACHLB degwekar_s_Page_140.pro
2fc1e3c72804894d53a266dc64abfe1f
e22ab02953f0350b1b1ac44f260f4e420b2917a8
45717 F20101206_AACHKO degwekar_s_Page_125.pro
aa70a7479b3da2744c12e3227fd6c3a4
6f92b94c13684effa4924d34af1da64ebb1e8621
28689 F20101206_AACHJZ degwekar_s_Page_105.pro
f95fea1aff8cb0df77be6b595fc0e417
577b74153e0e0482c176c30c398b2f396cc38dd0
2134 F20101206_AACGIA degwekar_s_Page_081.txt
8be9b2dc7dfe0c027f03d063f79037fe
db94aa9750dbbfdf97f07ac71418fabc623b3b29
67787 F20101206_AACHLC degwekar_s_Page_141.pro
256fba89a5e845aa88d14d2a8bb0ebe4
73f4a6e1c27a5121cd2edf13c7478261e5a1e17f
46695 F20101206_AACHKP degwekar_s_Page_126.pro
6e2798be51d931b2f8aeb778802937d1
8096fafdeeb684177eedc6d1bcd37b68a2c8e220
29620 F20101206_AACGIB degwekar_s_Page_141.QC.jpg
61556a7a4e354d30c4704f6f45cad243
c1191cfa1a04ca6894eab8b87e60a3edd3ec6345
66371 F20101206_AACHLD degwekar_s_Page_143.pro
dd57b3937f748c3fea7bc6ffa76e3dfc
9b3273d70466c5f8bfb956efbaf925320e885a6c
87410 F20101206_AACGIC degwekar_s_Page_064.jpg
b6c636690aa934206a4ffa5cb27c508e
d748c94a1076f56b822662f6af1d67e0cae6c529
54655 F20101206_AACHLE degwekar_s_Page_145.pro
574d9690232063b66b2ecec66f577041
61777b92f5bbcbddfba3d6f91c8dcae556df36e8
44860 F20101206_AACHKQ degwekar_s_Page_127.pro
ca631bd021b78eb8607d1126a9540081
a4cfe9a478dae1994252840b50f0cfacd9e34e2a
25271604 F20101206_AACGID degwekar_s_Page_006.tif
65630b64c5a77c3f38448bce8e80b4a5
b2ac235baa61bca8b84b775ac973990a7b58de23
64717 F20101206_AACHLF degwekar_s_Page_147.pro
588ec771509df3f77080a22ed7ffb251
d30d8e3eab8193730dee8cf40645149a130efa90
32862 F20101206_AACHKR degwekar_s_Page_128.pro
521b910e9a621ca8ea679fc14d56589f
292e1007d1d7ae4646ecce4b18214bc27ea58756
48911 F20101206_AACGIE degwekar_s_Page_117.pro
f2db623ad20cabbdee716e84a92755b4
a3dbe5584d47cbcfb01a49b22771a9f0488a300d
22072 F20101206_AACHLG degwekar_s_Page_150.pro
9473b54bfa00570d3fcbadb33f85d7df
31069d79e93b6fb38c536ece5620f3d099bafe09
11987 F20101206_AACHKS degwekar_s_Page_129.pro
bdbbf0b58975cb22390dfde51777551b
2f5abce2cb8e2c955a4ae21161d3c20606e07b45
29613 F20101206_AACGIF degwekar_s_Page_153.QC.jpg
f454c05a61c6937549b9f83fa2e5fb5d
545f9412f2f7b1e4109d2436f6a5e01592a3cb3c
61136 F20101206_AACHLH degwekar_s_Page_152.pro
6134e1194dac9d8e2eee6141fa24a9b7
6a2af935c46c6c461d5654433061776a32c0b9db
F20101206_AACGHQ degwekar_s_Page_124.tif
d37fd550e6f2d404308cf262e1b3bd7a
75dd166977d341dd4672a88963a91cde9d46a2a6
11275 F20101206_AACHKT degwekar_s_Page_130.pro
fc0b97b5e834232ef1b775508058ea88
51fbf314dc23fa00a23e19097284b8739e7ed4b8
35095 F20101206_AACGIG degwekar_s_Page_018.jpg
49737b56772360449d0739e2cf19ad63
c6bc478d52015fa5d53b8001a9400873cefc77b8
64262 F20101206_AACHLI degwekar_s_Page_154.pro
c57445fec08d0d34a3f7a67a13ba0b85
267ea402d6f0d746451e8eaeb6693374d007b422
2600 F20101206_AACGHR degwekar_s_Page_147.txt
027f399e8c146435003c428557517f7d
610c54ec8802c45e9735e3192004b0d9fd13be09
17194 F20101206_AACHKU degwekar_s_Page_131.pro
ccc29efa91b82b78ae8106a756ebee14
54b24fb34763dba4be2b5a367f43f712c8d74d90
59302 F20101206_AACGIH degwekar_s_Page_146.pro
4ebeb033299316da1e82cc903fd57a92
19fe326e13e00d7574adfadbcb2c6230776c7aa8
23707 F20101206_AACHLJ degwekar_s_Page_156.pro
2f6a5d5e0e7c5a841ea164db675a78fc
f089ebbdf4ed78e090e1b626db4dfa70414e3fd8
89229 F20101206_AACGHS degwekar_s_Page_096.jp2
b161808fd3db47e97c915bb57c81a482
bd288a30851a955935d2304680c2fc763b8b715a
36078 F20101206_AACHKV degwekar_s_Page_132.pro
650b467f034b72b34bc3ab918135ff29
9b65db54657e8a3f46a14b496c17e3f6011790a5
3120 F20101206_AACGII degwekar_s_Page_099thm.jpg
d9e5f249b4ee5d10f3565d4ba66f3e29
56a3d7f812206f96be9fdcd56e53b36c0674e20d
504 F20101206_AACHLK degwekar_s_Page_001.txt
14002632a084c7b175866706259fd47f
ec6d6c60cc0730d05e7945f9e76942e6981c7cd8
20784 F20101206_AACGHT degwekar_s_Page_096.QC.jpg
5f3a224b8620a242461392b4ec7ea22e
9abd4027afa4e4b2d30f597b2d71dd20df32f059
5916 F20101206_AACGIJ degwekar_s_Page_030thm.jpg
ec20b1b6396b18a4dd5e8b7b9cb66eab
97294e247e4e93a7ee9632794bbdcca82d46e21b
92 F20101206_AACHLL degwekar_s_Page_002.txt
87c5004c1339b61eb7c382843cdb71c4
a27e1403cfd6661204c1cf01b428daf032f0afed
970 F20101206_AACGHU degwekar_s_Page_092.txt
b9f068c2654672886afbd80074783489
a8517023ecf3cb769eb7f8a114ebb690c53c576e
61224 F20101206_AACHKW degwekar_s_Page_134.pro
37fe8c9bd1ad73c2648fd2fce4b21043
a887286a6126558906bb7a40053ea76a9c660f72
2003 F20101206_AACHMA degwekar_s_Page_021.txt
e5d2d50de332a11b1d395ea22b395a31
aacbdebea8db082f46d73e4dd24e37008f40e57c
1370 F20101206_AACGIK degwekar_s_Page_093.txt
413916b0a2b62704cbf7902dbf81cec3
723d657c9228cb89034cc8648fdaf3555034a83b
102 F20101206_AACHLM degwekar_s_Page_003.txt
e23314518b3219c661d8589122fbbda7
0fe0ecc54900ae4839a7c750ce5c0b4049653eb2
F20101206_AACGHV degwekar_s_Page_076.tif
e9b4b1f4bf0080d289906d453dd35651
2514090bf7d2e1f2edcf9454367730e69f7fb713
60839 F20101206_AACHKX degwekar_s_Page_135.pro
a1c3f6b5d01b128176cfa4385c31edc2
fb069faa08661e1995bf53e53c9745e4b7302e0b
2232 F20101206_AACHMB degwekar_s_Page_024.txt
50466ca00aa367c000578d4ccb1028bb
abc460068a84aa4d420072b7f72b1f85de8d3615
18117 F20101206_AACGIL degwekar_s_Page_038.pro
11409cdf3935dcd3b15d339c29382647
9b64a64f737905b45c364c21137c2974d0295660
2060 F20101206_AACHLN degwekar_s_Page_004.txt
7912cccff4e9913e8ada2d5546701bf0
775b94b5bc945d56b89ed91a2d6a30f763c500eb
70049 F20101206_AACGHW degwekar_s_Page_057.jp2
db0835854ee7f94f35270a8bda2b47ca
820d9191fef45a21b76027c4fe305b04778fa110
65925 F20101206_AACHKY degwekar_s_Page_136.pro
6ac0083274330581c0c3830b8f96bb69
dc253fb5547ed21838834fbf5478c18da3d0400c
2151 F20101206_AACHMC degwekar_s_Page_027.txt
fa2986393c3adac3830f0a53a5fbb2cc
e50be353655a10b7d41c69392e34932ce3b95f46
2088 F20101206_AACGJA degwekar_s_Page_036.txt
d9771b68a657411bacd9f9f9aa947999
1209a8dd905d9cf7c856d65162413ed67ed186ad
45312 F20101206_AACGIM degwekar_s_Page_038.jp2
18af805cda995beb6ce72b15b8eb33df
8b492d205608b126637fb18471414066e704c91f
430 F20101206_AACHLO degwekar_s_Page_005.txt
8c177718dd715f08a7be37ea08eabe8d
6c9c77ebf7719d180daae9b010a2a839e2055dd3
79034 F20101206_AACGHX degwekar_s_Page_097.jp2
3229eac32bdcb484849f6365dcbffa5f
f0238670eab14e0ce3bdfc37ff82a80bf92759fa
71559 F20101206_AACHKZ degwekar_s_Page_137.pro
1fc47fd6a3943426d60b9a7986a55071
3b2971c204b5a50b924406466cfde5523b623e87
2037 F20101206_AACHMD degwekar_s_Page_029.txt
00554ed4e29c560f2a70480ddf80cc7f
7a36658c53b5eac8f0b8aab7e1bfedbee67a9ccc
5493 F20101206_AACGJB degwekar_s_Page_119thm.jpg
b1d2c9480bdb0391736d00ecea05371d
36bd221f712190e2ead1c31581ae31bc1f2f26f7
1808 F20101206_AACGIN degwekar_s_Page_118.txt
4931dc960493907aa75d2c5ce3906013
d4cd6f90813a8c5f645edfffb8cdf81c356455c1
3444 F20101206_AACHLP degwekar_s_Page_006.txt
5b05a1cff1267ddf30cd4797a175026f
42ec370ec1bb1d90be377c0f733704c150fbf447
85635 F20101206_AACGHY degwekar_s_Page_014.jpg
464c9739c4f278518fed99141566f29e
b01ca97dc9438c3cabe4931336cde8cccb4c3e25
2051 F20101206_AACHME degwekar_s_Page_030.txt
c844134839fef760795bbf94982e02e8
987cc2a345d5cb62303a15ded6ee84df567ed4ed
5618 F20101206_AACGJC degwekar_s_Page_032thm.jpg
109cf8a0840e44d431bd08211c6ba160
3bef15ff820f478eb2d41b7ff705b1b48813c245
101168 F20101206_AACGIO degwekar_s_Page_033.jp2
7586fc8e6ec2bb892566546b63acec23
4b489714013b10a87691917da608557742840eb1
3101 F20101206_AACHLQ degwekar_s_Page_007.txt
fc66dc0edda76e6f4e95440d86fc0301
9a34ad50d5c510729f44fb0cec7daf72c7d25cf9
12512 F20101206_AACGHZ degwekar_s_Page_156.QC.jpg
ece337f1b32ec5920708999d7a9902d4
f3e9f8145c59afcf8f3453ff42edc01c38a5e137
2080 F20101206_AACHMF degwekar_s_Page_034.txt
2ea39b92a57ccb960e143e8fd586601b
c53cdf829974ca43faca58b40b512af7b8724d07
6321 F20101206_AACGJD degwekar_s_Page_049thm.jpg
67b0ff1f45418c1515fe91ed01bcdf41
b8a0e1e3fd8ecb566f6ece1b5c0b6dc75c5fe629
1982 F20101206_AACHMG degwekar_s_Page_035.txt
5e6c2fbe9e8681a5a6db930264dbf3ca
d9b0f447ae0630fd5d04c9c5cdf4dd17635858f4
60659 F20101206_AACGJE degwekar_s_Page_104.jp2
7176371ce3b226e8c068e26ecfc49105
922262145cfebfbd0a453390ff93908e9bae5cd8
91731 F20101206_AACGIP degwekar_s_Page_123.jpg
8593ee0d8eeca876e0eb56cf8880c743
563569c2133529ab3a974385965921057e766b46
F20101206_AACHLR degwekar_s_Page_008.txt
5f4e2f63914b004e12168684a5498a34
a70ffd56a22ebaeebda260793d822c58d33fa760
1126 F20101206_AACHMH degwekar_s_Page_037.txt
f287b08715ca4adb06e137e304e1d720
11658449e3845a4af682efc661218760aa5fca8a
3453 F20101206_AACGJF degwekar_s_Page_092thm.jpg
782ffb059daa4fe1452b7341be6f53cf
66e61939132095689c18160e8be9213b96277b42
5447 F20101206_AACGIQ degwekar_s_Page_125thm.jpg
fc440b3f4ccebaeb9a90555fb73e5ed2
5ce12de08df15d322136a4bf5dd231319e0debcb
1412 F20101206_AACHLS degwekar_s_Page_010.txt
45974ddb6e0ef7d919ffc231b6ee33b1
27b0c43fc6ee0fdc757008bcc4db68a44ead2f51
855 F20101206_AACHMI degwekar_s_Page_038.txt
bb91890cc7d91d9bb61e9c237055a364
ed19f4a5fba829e8309f806ac8660aa48c50e643
114397 F20101206_AACGJG degwekar_s_Page_143.jpg
1565ff0a417844ccba83ffae5d83b646
0a57f445670244e6067630e517d306fd38732524
F20101206_AACGIR degwekar_s_Page_149.tif
ccc834a06ce551d6a4296c3c9980400b
6e275b766b768467cf2b81e7eb832610090b5993
939 F20101206_AACHLT degwekar_s_Page_012.txt
0eb1c1a00d5f031b852c51010900205c
b6f596a1ba1219b96c1adede7b7ec58bf453c48b
1163 F20101206_AACHMJ degwekar_s_Page_039.txt
c6db8ce77c461a777522ccfeb3f0ff68
aaca1484bf12f062e488b2315f304728a15fd776
63180 F20101206_AACGJH degwekar_s_Page_155.pro
d3fcd161c4b48c181aa2eb689d548cb6
cd7b36d756ee74c86ec0c43d51998f913fcc57a0
F20101206_AACGIS degwekar_s_Page_123.tif
14bf8f801b5999f39b812545d9cda8aa
818a0c56b971628a1d31fc3edd59c2ca63330c55
2106 F20101206_AACHLU degwekar_s_Page_013.txt
6383018a3fad24db70d2f9e2df4d0d5f
cc03e8aaa5b6043c9fb789acbd01e753e08fffce
2162 F20101206_AACHMK degwekar_s_Page_042.txt
b784b0d280ad6057548f2e3a097d4f17
ced268e2362e350051f5a8acf8f4ead875670459
2112 F20101206_AACGJI degwekar_s_Page_142.txt
4f6a764013ad09e6d7a0cac91ed8155e
f70274efbe570a558119bf8781236b2289e7f6ec
4590 F20101206_AACGIT degwekar_s_Page_026thm.jpg
6f060102eb627fbd8d06ce01e241428d
d002aaf461968abd9caa3db8b347131a79f8c67f
2250 F20101206_AACHLV degwekar_s_Page_016.txt
06cb964d716f3cc0e8d1fd2af6025ca4
866c183175c48979f5594c83cf6a38ef14c6156a
1365 F20101206_AACHML degwekar_s_Page_043.txt
00163ecbd60054495395bdb09b70cf01
71b36d452e314c6822eb52de37d32580ee18d986
2225 F20101206_AACHLW degwekar_s_Page_017.txt
0a502c91a3c24c4186ac64c1f990059c
3b7090afdc5b156c6891571c0558fe2a2de4791e
1730 F20101206_AACGJJ degwekar_s_Page_031.txt
e161e289acceee39947c066df49f7417
f3d2a3c48d8f9b2133c64374b089e4b1ece17be8
53626 F20101206_AACGIU degwekar_s_Page_052.pro
8087589d3c63c348906f7d751d7d0822
5f18482be0af6fe744b5e2e40a997ad72eca2801
2167 F20101206_AACHNA degwekar_s_Page_065.txt
af99088df8f530217a460ce87bce233e
8a83790de55b986634fc028d6551bbc8bf3ba400
1042 F20101206_AACHMM degwekar_s_Page_044.txt
b18ab0caea505bd4ec60996a6d6b5df8
d932d189e5d955906616b6d41d7d15c659bb6e9a
818 F20101206_AACHLX degwekar_s_Page_018.txt
dcf423a2b34b5da6342480c1f1c54c1f
00d23f45019b1b12836814744df59876b36a638e
37742 F20101206_AACGJK degwekar_s_Page_129.jp2
8f1b69523fc7e89e5b9eeeed7d1cd3ea
03be8c3ff3594a2921ee3ad3d436eb6658cbd3b0
6542 F20101206_AACGIV degwekar_s_Page_088thm.jpg
a23ffa4de33d93220eb32eef6820fa85
11d728ad446020890bf21f63e2d8b818b4f0b0f7
2315 F20101206_AACHNB degwekar_s_Page_066.txt
55d6adae43be530c271282cd2fb502de
6512bd48e4ba5263198e56ce7abff46b7a1fd3cd
1713 F20101206_AACHMN degwekar_s_Page_046.txt
cc18e16e97156b2d34519cd85faee9a9
f69b8efdc0706c4febbcb0c074c64d22a6ba2ee6
1762 F20101206_AACHLY degwekar_s_Page_019.txt
58457744571498bda8c27e2116c45f73
5a6dfae915420bc77a15923cb4bd8ba1e47217c1
F20101206_AACGJL degwekar_s_Page_087.tif
7efeb752c3e6f3016a7499f2ad6c41df
137001f49602197e07cecaddc4755d90360cb54a
149911 F20101206_AACGIW degwekar_s_Page_137.jp2
e6ba49076972b83997d067262aee99dd
3f914a7855f4147dfee8f30a858156a76cdbfe09
2094 F20101206_AACHNC degwekar_s_Page_067.txt
33c74302d0bb4581319a12c1e812c4ba
22e9a0aaf31873359203ad54546f8bd77842f91f
2042 F20101206_AACHMO degwekar_s_Page_049.txt
53be53df84930b0b95da954f99d9f038
d05c67c0fc4e9750948c10fdc25e6823d2211eb3
1942 F20101206_AACHLZ degwekar_s_Page_020.txt
8fe3247d849263bf7efdfb230c85e369
62608bced244c414a70d9663451e48153131f8ea
5828 F20101206_AACGJM degwekar_s_Page_061thm.jpg
0948b5e5adcca7fe9eadd9aad4fb4ccb
df914dc2bfadafaed4cd15b631a9a77f82a694cd
3436 F20101206_AACGIX degwekar_s_Page_039thm.jpg
dcc3cbf40482d6fca6c54c0b326301f1
ca2ad9f144a4014422a85da9ebb1a3a6f5319bb8
2095 F20101206_AACGKA degwekar_s_Page_023.txt
4c75a9a8a2db45d8a710ea56c604a751
8e13e4965a849567e0fdcc51ad5b68a0925c8ba3
2236 F20101206_AACHND degwekar_s_Page_068.txt
e06ab1ac12eb26386bedcda9322cb400
da17aa835f7114c2e81ec567638d02153828adc5
2059 F20101206_AACHMP degwekar_s_Page_050.txt
1aee83e0ac3020688c8dc4c0af0220ab
de79f7a3f40f05a73ab28e20f5c7d3525c145fb8
53985 F20101206_AACGJN degwekar_s_Page_063.pro
7ffa82633212612d3acaccc0e395f789
2460117a0ad74cc47df48550c9c7df824c05ae2d
50717 F20101206_AACGIY degwekar_s_Page_030.pro
14342e12c8d9a22b363aa005ec1e2e09
4565b0c00c3e3cac154e7fab2034a151efa172d4
13843 F20101206_AACGKB degwekar_s_Page_101.QC.jpg
b589aedb9bea92e1bc9ed43b85d59000
fbc2f64bda4766ae77744a546e6013832e8a7395
2098 F20101206_AACHNE degwekar_s_Page_069.txt
f57ff0f2fc130c20a0fccc0f767b7749
d1bed8ffb17f7d72c00c8ee6877cd108ea30b0ed
2114 F20101206_AACHMQ degwekar_s_Page_052.txt
284c6d62b1e9807b3f783d66d75d85bf
9979c82ed207345bdddcfe42eba1467800880e73
13881 F20101206_AACGJO degwekar_s_Page_133.jp2
c7548216ca43ecfc1f6c70ef87f30f84
b37043dcd6f87d7207346b0a5b7decec83b06ab7
17764 F20101206_AACGIZ degwekar_s_Page_109.QC.jpg
e811db259b8ce68b5e3c92151567f247
5123c3f354e6a512f5ce6c7446e027aa54e2c8b2
348 F20101206_AACGKC degwekar_s_Page_009.txt
b03d9ade80adbacbd81e1cae5d4eeee6
e7016fa1d5bbc06e108e6dad5ad23510d686520d
1888 F20101206_AACHNF degwekar_s_Page_071.txt
5091406a613f41ef6091f7d636319899
2bd70e9aec08e5c211e1ea8e04e4089855a66df3
2178 F20101206_AACHMR degwekar_s_Page_053.txt
5e24c7a7ae1b17ed35b57f2b6b746d50
2e1a089c1cf68ddf0679f8e6c19b939640c72349
2268 F20101206_AACGJP degwekar_s_Page_070.txt
1cbdcde152e0e12a76400482be828181
34429114067d1c0944a79fd94944a09568c6a03d
113129 F20101206_AACGKD degwekar_s_Page_142.jp2
79afa568ece39a0379b474ae6c3b3e75
4259b261924d902c071bb5ff3775dca79146cc5f
2544 F20101206_AACHNG degwekar_s_Page_072.txt
b0164ea25e7d30989fa0fd3ea1f524e7
622f80d7b052da52efa393bf6a61a7e8274fde2b
32230 F20101206_AACGKE degwekar_s_Page_157.pro
98284bdc8afc563d347c1510433fa631
109bb63df44c80f4f0d3d23a013670e836c3a4e1
2019 F20101206_AACHNH degwekar_s_Page_074.txt
3e3eac7a4909d84a67d5e0822d3a5eaf
9ace1eb807722ac141752b99da00e3bc99dbb4a1
1640 F20101206_AACHMS degwekar_s_Page_054.txt
2a0ee85e8fb5ebfff91411fe093539b3
c9b72b2635866b0691e4c119bb6a630a5fa5929e
26291 F20101206_AACGJQ degwekar_s_Page_130.jpg
feeec8f24063ba6cffe69f5c96f458ca
2d79b0fa6924b9d3748d0d265f5fa7ee63087011
58822 F20101206_AACGKF degwekar_s_Page_128.jpg
48570dbe73aed98320f665150495ca40
ff749455d4cf77aec48ef6a5fcab8aad819add3f
136 F20101206_AACHNI degwekar_s_Page_076.txt
e1f4d0426b9e184d93edbb817c1d2a66
abba4bc2af500e889c0e671be45c63b87c509230
1247 F20101206_AACHMT degwekar_s_Page_057.txt
6de438aad8605b1ed1ffafe2752ac9dd
c2110c346bb579de19f3f285e74ebc8fdddcd1d7
F20101206_AACGJR degwekar_s_Page_064.tif
b318fe53d075d37024c2d7d25b4b6311
a0a2d0189935c46b00dff132b5331eb1d5c9da52
5736 F20101206_AACGKG degwekar_s_Page_124thm.jpg
12c756f163cf3a0b904b1beced1ddd02
50678c3764c1d274d98489de090eea6c902a5921
707 F20101206_AACHNJ degwekar_s_Page_077.txt
6ef9707d213a52e3de48576b353077f4
61864aff6f3e194673ebce57b97be8e284f0416e
1569 F20101206_AACHMU degwekar_s_Page_058.txt
4fe1e28781ac60c64cb6e315ab6a0c8d
103619da894ac2704f47b8b7c346e6dcb770018e
2678 F20101206_AACGJS degwekar_s_Page_143.txt
f75a1524b08dc3a36be44cd79407e7ab
dd91b81d7b544bc4bf7191eedaa1302611d84ae9
F20101206_AACGKH degwekar_s_Page_061.tif
7f578dabe980ca20e1da88f173739765
93dd163343f1ccc6e57ac40df0a189438a901f2a
2191 F20101206_AACHNK degwekar_s_Page_078.txt
abb56a54439ea2a91315178a8beda7b9
adc4ad36d49ac57fa3ed07cc0e2a5c9699257d19
1819 F20101206_AACHMV degwekar_s_Page_059.txt
0bee883ff32d7a01b019fc90ce979046
6d2a5eac91aac61c04b3af233c5aa4cc3353dbb2
107583 F20101206_AACGJT degwekar_s_Page_116.jp2
8946a382fc250640688a9a560ab55b0b
02cafc3225535ec8f5c2505b04b7da3f7e18f1e6
4233 F20101206_AACGKI degwekar_s_Page_133.pro
0de774ce0bb82e07c7cf0ab6df379009
88d706458ce935e773059cf000bb4c38ee142966
1708 F20101206_AACHNL degwekar_s_Page_079.txt
b59662fed3a34474c8cfdfdfb3be3b25
1608b1e5ab9b6a0ade261875f6194a3265212311
1869 F20101206_AACHMW degwekar_s_Page_060.txt
06a842d42dd0dc83e8b1aad27423de38
163616ca9e405f88a0c50251b373342e21652af5
1334 F20101206_AACGJU degwekar_s_Page_040.txt
8ae9d4b3e4c6c76357e051143b53f4cc
6476d10bb7488a82ffa813eeaa39a7d44d198c66
83617 F20101206_AACGKJ degwekar_s_Page_121.jpg
882eac8d5ab5d911998dc6530fc85168
77b9b68c9b8dc8e945745fb29d832cbaaac9ea6a
1304 F20101206_AACHOA degwekar_s_Page_101.txt
ed3e30a621f6950180cfbf8a7369aa44
69876e625eb3bb074d8f0da200388f151397b3aa
2013 F20101206_AACHNM degwekar_s_Page_082.txt
80260a660b55cf202891edcfdd4d91b5
37c8dce9baea0dc712f5afc114ceb2a23965e16f
2217 F20101206_AACHMX degwekar_s_Page_061.txt
3f0de48a541dba4fb5cda38b48a67850
1424948774dd09ae0b12fd8e1a55b68d84b97e09
1463 F20101206_AACGJV degwekar_s_Page_100.txt
6f9006ae6e80dbd169ba213dbb105585
e19ca3f3ed10099d3f0399139a206feeb2f930a4
857 F20101206_AACGKK degwekar_s_Page_131.txt
8413f42dc69eb475cd6893a62cb1b6f3
c358bc945c912db9b61f59cafb78012cb69d4036
1315 F20101206_AACHOB degwekar_s_Page_103.txt
05c5b46fa7f99ec75d47d749bd3c4783
40177937016d7456486591890cd0d566db9a2fbb
2202 F20101206_AACHNN degwekar_s_Page_083.txt
3fcd79a3d858ecbd79a8aee31b8a4fcd
4fad4d9a02e72a927d0a9c9c31701f472b357437
1005 F20101206_AACHMY degwekar_s_Page_062.txt
7eacdf7d335c079df723f9db7f3bd90d
7f95f34c7dff32d156b94c834fcced21a1e46bb7
1845 F20101206_AACGJW degwekar_s_Page_032.txt
3a40d70f389f28ca30b8a84a54175195
659a342aa0413711e149cb240b9b32f3d276a1e5
108804 F20101206_AACGKL degwekar_s_Page_136.jpg
f101976d24e06d2fb1613c17f7eb5d93
d4799464a0b6e3be473c4deaf68a5c4cb5df6515
1127 F20101206_AACHOC degwekar_s_Page_104.txt
2202ac2196923fcec4cebe1396faa924
a8080e959cc181759f938ecd2f339715b72c33c7
2203 F20101206_AACHNO degwekar_s_Page_084.txt
408ccc11f17ffb81739ec605f00c62a7
663d0fdcc855b3e41b77974bb6bed1de01959af3
F20101206_AACHMZ degwekar_s_Page_063.txt
4c11dbf2a3ae21131fb77ec5931ed08a
d955577c84e385b25a8f7210ba43809175d919dd
1926 F20101206_AACGJX degwekar_s_Page_033.txt
0899f674fe94f985283c0418fb324efa
f9ed21126d334df45354a157de8ebb68e4304dcd
71942 F20101206_AACGLA degwekar_s_Page_118.jpg
74245d26c1abd76197a231f591e7d1a9
1b2f1f801caf8087b804b003bf10725dcef60405
45941 F20101206_AACGKM degwekar_s_Page_104.jpg
c492bc2c81636a8d8727146d5a4a67d8
8db79a58e7b1effa85460f80731c4255028df42a
1246 F20101206_AACHOD degwekar_s_Page_105.txt
74f6c08b374040355372c91ad19bf0e2
33d875e351c9497cfbe15500646b2d7488c19bfc
1977 F20101206_AACHNP degwekar_s_Page_085.txt
5958630d068727cb8802df6b218798ce
9b60752da94d8b0ecb7d7df8404c815391a4b565
2540 F20101206_AACGJY degwekar_s_Page_154.txt
0b3253fe523adbf68b19f13979b0109d
5ddd13ec7a21ef370482fa379aeba811cc43911d
18826 F20101206_AACGLB degwekar_s_Page_132.QC.jpg
4f71e6248cb53cc636511f32fd23085c
eb1ea2fdd79ada1a281235c25155095a5136091b
115969 F20101206_AACGKN degwekar_s_Page_137.jpg
ddc3c43cce84fd35260d8b757530ef44
2e6b79ef341d96ab1cff29df21b61dec96962b2d
1515 F20101206_AACHOE degwekar_s_Page_106.txt
2b9373ee7b896955777e324fbbf3465f
f390e3728e2339d5544e9a5ea651feba168b82ac
2017 F20101206_AACHNQ degwekar_s_Page_086.txt
d70602d9f1f535fb6c9f8ba2e9ff0942
c44535111cf08e6d0d2f1844642ddc017e23d2fe
F20101206_AACGJZ degwekar_s_Page_021.tif
b17250cb1e80b121e0fe2ee1ce79e094
5f9784c4679ba7e96775e0cbe52fab11fe33a0ff
F20101206_AACGLC degwekar_s_Page_038.tif
a804740254dee9a6611ac15b8a949994
64dfb605a58e37c60ef6bbba99d06b875fcc0bb2
18687 F20101206_AACGKO degwekar_s_Page_093.QC.jpg
3e4eecf1739bb3164a125b44fc1bd202
38d8af915d6645860d551d4e3cabcfa3dbd541b4
1166 F20101206_AACHOF degwekar_s_Page_107.txt
344e9f45c052ea9bc0e8e19c99c5f652
261c874a50c35a051fd8f659e2c23d6047ac42f9
2062 F20101206_AACHNR degwekar_s_Page_088.txt
b70ddee270d70283550cac8bcee76519
4ebcd303e16d5608f90bd077b1d0966a72d92792
F20101206_AACGLD degwekar_s_Page_029.tif
e7956bf5e7865cb8a394a186f98656d9
22e69e639ff2bb1b60ab2c14cea204c9b1368239
F20101206_AACGKP degwekar_s_Page_104.tif
a8749fff26d6d3312b6cbc28763b25cb
2754131aaa5a0cd32a15db82f20c433da303bb5c
1353 F20101206_AACHOG degwekar_s_Page_108.txt
8099c88c3e359e8169d31cb9fe819067
0ed98529c6ecf135a772677e4e1bb8f92a6774cc
2768 F20101206_AACHNS degwekar_s_Page_089.txt
b32afd8ba2e18fd9e4f1a20f4369cb45
087293c5bef378bc31da42d76d725040a13f7ae4
85590 F20101206_AACGLE degwekar_s_Page_067.jpg
7f24a316434a1d1b52eb2eb5eade6129
c9d37d0f5fd8ffb4d80bc9ac613eb74dd4f785b2
23370 F20101206_AACGKQ degwekar_s_Page_032.QC.jpg
8e4bada4be62ebcbb395a4d597bf5592
7df2c19cc91ef7ffc60c6ae8790e40f5c570874b
1746 F20101206_AACHOH degwekar_s_Page_109.txt
462718ba58e39f8a277a24ad3fde4dec
c0ff446f673b1d9038f99f25c2bbb3197d3ab282
2004 F20101206_AACGLF degwekar_s_Page_028.txt
722db2353d94ac0c48645d8246e2767b
a3008c00238d74434054f3f7096a0400d2686d1d
1629 F20101206_AACHOI degwekar_s_Page_111.txt
183632799b395a1f26ab8a4b750131d6
9707e75bd4b831d50b17414062582ab3793e84e1
1231 F20101206_AACHNT degwekar_s_Page_091.txt
7276bbc67f3744f1c7f90b3fdf704a4b
9c59387b8759a19ad5137f0ba1b24384a4f93a0a
5504 F20101206_AACGLG degwekar_s_Page_002.jp2
c2a449d511e1a95288b8d30f48400889
8a6b737fadee0f78502aea9f0f4f0f16a11d4cf6
25458 F20101206_AACGKR degwekar_s_Page_139.QC.jpg
23920b04d6a6564b329dea8035722da0
729ecb0058f90e2440dbb06c3106f17d6da43f87
2049 F20101206_AACHOJ degwekar_s_Page_113.txt
3b9628181fdbccf49af59636fcf0918c
f11d1c897665b09f225199108e5bf0a7941ab892
2616 F20101206_AACHNU degwekar_s_Page_094.txt
9f66c896ad8d8e1d63e2f04c93eb3d42
4309578e0d35c0eafa1987baa3d073a07cee1b31
2099 F20101206_AACGLH degwekar_s_Page_064.txt
8ac17634022622aa0c3d11f42818b20c
580c58bd5636f4e32c53799c93a25eb77bbb7b3c
136642 F20101206_AACGKS degwekar_s_Page_155.jp2
af4e964a9c8382948cf2c32d54b8a12d
88a424c8cbe84fb5e296e6fb24ba5aed24ec9a7d
2152 F20101206_AACHOK degwekar_s_Page_114.txt
9d7b413387c16f33ac6f256e06738ff4
c0edaf54a7ce180e2a512dea88409fcf5f2dc076
2833 F20101206_AACHNV degwekar_s_Page_095.txt
6d6bafc40994693282971aee68bbf8e6
a377ed30603d4dd4d5f932a842e8555b0fa7a9d4
18432 F20101206_AACGLI degwekar_s_Page_058.QC.jpg
8acf3d9a558f0b5e6e499917d13e718e
32f15a2eb0307b859fb6bbf5c2668e04248790f1
87645 F20101206_AACGKT degwekar_s_Page_036.jpg
d632a6ba5169c98a1575895eddd8ffff
7f72b3046c4927a0c98a8159fad99a937b46b337
1466 F20101206_AACHOL degwekar_s_Page_115.txt
85707994b3fb5f4478930fae1eb90089
da5598b4f8091a47943aa46da177a7c64b89bfce
1648 F20101206_AACHNW degwekar_s_Page_096.txt
a0e067cd7724f34df40b17ec3928e0a1
4a00cff15d7d872debe649779ed0285164669858
4532 F20101206_AACGLJ degwekar_s_Page_115thm.jpg
88356649dae886785c1f1b64f144e472
753d6184f38c03e8c6a900a6075e23cc624620c2
66113 F20101206_AACGKU degwekar_s_Page_045.jp2
e6910aa18144dc8f326ddda6ae1753c5
8d0576f51b3739b4571035cd840a7538e6276367
2417 F20101206_AACHPA degwekar_s_Page_135.txt
378a48b58518a429447526c758aa604f
e1e65dd1c6f82259b56225c122af0ce51979b4c5
F20101206_AACHOM degwekar_s_Page_116.txt
5689e5d7beeb3e80c042dfbffbe1faf1
b5285a08fcd69fc6539cd46d02f7af4e9ef4af98
1628 F20101206_AACHNX degwekar_s_Page_097.txt
8387a2d1da0705128b92efccfa894e47
d09818007d0f4510777f7f1fc256ac80ab45cf49
29685 F20101206_AACGLK degwekar_s_Page_101.pro
f49f3bcf7584b00b0b6a7ff01ecedf00
b19f8dae0d28dc9dd9e0056ef0b1e9cc8f2c7185
87660 F20101206_AACGKV degwekar_s_Page_031.jp2
7514a34bc943d51509386275e9ec79b3
3bbe784dd162e6728b0cd18c82d3e1eb2d1241f0
2685 F20101206_AACHPB degwekar_s_Page_136.txt
f688c3264885bcfc6a306b2e6ed0679d
6ca68d3cfa21c5628eab3efa6e039bd50dc9331a
2008 F20101206_AACHON degwekar_s_Page_117.txt
4587ab5c1190521bc03a0ee498050b9c
0d1f12b67c78380b42dbaacda0e9ca0c29decf96
1369 F20101206_AACHNY degwekar_s_Page_098.txt
261f010d34bc75d4c02b8d8b2dc4389d
dd29a830bb14874ea3073f0c113dd53b03ac5850
6794 F20101206_AACGLL degwekar_s_Page_022thm.jpg
418924b1a1eb21672be06321e006115e
b67b6caa382b4f90de91a2eea3dceb460bbba2b7
F20101206_AACGKW degwekar_s_Page_010.tif
23bbf18faf96ecfec03190f7c4e80c09
698c364f532588327c0693cef3626af1db255014
2907 F20101206_AACHPC degwekar_s_Page_137.txt
2919b21744eeab1fbb3d7cecac132888
d601b19ceab4b3d3d9c9a5c3e1e87a9ce4fa4eb7
2089 F20101206_AACHOO degwekar_s_Page_119.txt
435cf97f41167fe5e619537a7507162f
f1bd7fe6756a2a97c40ef28a9b2fccda5d2b0f19
1172 F20101206_AACHNZ degwekar_s_Page_099.txt
cc1a9364f84aee73191df35fdcab69e0
2d80dd16c99b30876ce0bdbccf58eb9fbc3b24f6
24627 F20101206_AACGMA degwekar_s_Page_149.QC.jpg
5ddbd28025d70826ad99186a7c4b517c
369380b45bb3b274a348ecda4694768e711d0a4c
F20101206_AACGLM degwekar_s_Page_020.tif
fac899ba87deb791b0187733ad226b8d
1049957612497e60c7d28f4913a97affdc249910
26107 F20101206_AACGKX degwekar_s_Page_037.pro
8278299ff330ae02c658eb70fc7894d6
c5bb46945ea1fa2c164588c31ba721f59bbe539e
2594 F20101206_AACHPD degwekar_s_Page_138.txt
dfdf85d331a46d876fd910ef5e299476
d84588cb619d488bb6524aeaf07938493062d081
2247 F20101206_AACHOP degwekar_s_Page_120.txt
f85546bd1c78eb07fd5bdb37af43fc73
6bacd8922923be2d4fe4529372daae5e6966fdfc
27203 F20101206_AACGMB degwekar_s_Page_134.QC.jpg
5afdddf78ff6574f1ad37debda0b4374
ec3e4953c854a7891db4b2e4b3fec4b2fdadcb57
1209 F20101206_AACGLN degwekar_s_Page_003.QC.jpg
d35407316e9a3dd41dc7e7d5596d5a5b
1f55be2715ca65e0275b26d2e15550c83f7bf4f1
F20101206_AACGKY degwekar_s_Page_107.tif
1a08ff5a24e326478a77fec520c36fa8
02ae0c81e241c99878e0993abdaea6e803b84f37
2328 F20101206_AACHPE degwekar_s_Page_144.txt
a0eacc50039274577682a8471342cde3
ea5fa464149118393c2e10a52b67aab85855a316
2024 F20101206_AACHOQ degwekar_s_Page_121.txt
ee813aa0e1b8e0990f7f26771d99a9cb
5596bc7f0b0dc0647e6ef03da22f64f418d7632e
54176 F20101206_AACGMC degwekar_s_Page_081.pro
fb63cec4aad13dcbeb8c58e0713a5cc2
23b53f250d94c297dbd23725974ac00580c96a5f
72939 F20101206_AACGLO degwekar_s_Page_040.jp2
8a4999b2125d56f95e95fdd5c2a2253d
e5304a11e47900e3753b1a0c4a993de96872f653
91755 F20101206_AACGKZ degwekar_s_Page_016.jpg
cc884947a6d6fd24d8405e876aae2005
708cbb78bdb5cf581b8aecd0dad0ecfd35a838a8
2443 F20101206_AACHPF degwekar_s_Page_146.txt
fd89a19b1345b95c6f6ff71b5070d72c
cc8e4cbd550e2dff725f88bf1ddafdd565a42e72
2129 F20101206_AACHOR degwekar_s_Page_122.txt
bfd758fb6788595d8185129815c79507
4ec73018c0f08deb5781f9188ee00e01d0b54914
F20101206_AACGMD degwekar_s_Page_065.tif
9eb5a0dff99522cdfa1638cfe89df354
a7bc73a506001d0202fb51d1182f873578543ec7
1467 F20101206_AACGLP degwekar_s_Page_026.txt
6446bb7c11011cd655898565fedf35c9
5140a9adfbb2ef87e99c6faafcb2449d66f93a7a
2067 F20101206_AACHPG degwekar_s_Page_148.txt
7a36d1e19315d97d1aa4507f4ef8c406
f110296e487b551d128725603b1f4d94656566b5
F20101206_AACHOS degwekar_s_Page_123.txt
0e3f468ca5d2b55d8bc8b338b20e3188
6925ea0a6e95ee94e40965b97e93302f32fb93f4
48171 F20101206_AACGME degwekar_s_Page_029.pro
0629da624d18b9fb2c6af9764002aa79
fd3e8bf046768ddac093908a6784098973bae1e3
443 F20101206_AACGLQ degwekar_s_Page_055.txt
1ca45f9063dc6799b357a5b856681044
ff7349d80fb159be29cf591d2d590141510b6753
2104 F20101206_AACHPH degwekar_s_Page_149.txt
1920eba38d967739d19e15e32e51cb1b
e484c09eaf04796927b6b3ba4c574993c05e38a4
2085 F20101206_AACHOT degwekar_s_Page_124.txt
afa7d1c41c91fbad617d03320f25120d
857aa30f11e193ecf94b52273774f7a4c2011ac6
7124 F20101206_AACGMF degwekar_s_Page_155thm.jpg
45dc03b38ad6dbd772cf1d154af5b552
cec7e8703eb8ce13c7d7075fa98d4d436ef09259
F20101206_AACGLR degwekar_s_Page_019.tif
fe260362fee5f996f2579a730fbeafed
f9fd40954c78d1d3b46869d48d870ba06e295898
878 F20101206_AACHPI degwekar_s_Page_150.txt
ee8b8f152afc4783fe24cce33b80029a
a10da9d89c0e43618711d1ea53078995e270d5d5
F20101206_AACGMG degwekar_s_Page_059.tif
b171e61c782820328c362fa1eb482d1d
4b817bd9a4b781c632385ec9d593ca6999659c2d
2471 F20101206_AACHPJ degwekar_s_Page_151.txt
256603c39f70f1cedbb073a7bfa269e2
2864e76a67d50392380e56758a5294707c6ffef7
1928 F20101206_AACHOU degwekar_s_Page_126.txt
7188f8942504dc6c29ce07be81d25b3f
7957cccc3c49872a5d2bded6fa06c71a4737c8b8
22001 F20101206_AACGMH degwekar_s_Page_056.QC.jpg
1ae3ca82c06bf73e5ea9cd78222503b6
dac6889f6ec20cdef3870975007540935110afab
62619 F20101206_AACGLS degwekar_s_Page_138.pro
fd38d3cdaab3df2df54c8316dba022be
a1ff301801d7472c46fc86ceafda9331a92db765
2423 F20101206_AACHPK degwekar_s_Page_152.txt
b7614e3cea2717d5b9ba12e0a522bf3a
f0a0339e250a8e28d421611865d63edd488fba84
1900 F20101206_AACHOV degwekar_s_Page_127.txt
84b27f060c693c636701f97165268e42
6e5bc5c7b7fce418fa01c8f99c167764b30404ff
2214 F20101206_AACGMI degwekar_s_Page_145.txt
0f0e1e92f84d6e97eaf73e9ebdf77756
bbbfd20b17ec45fb807cc9685d0cb8e4ebbbe7e8
99997 F20101206_AACGLT degwekar_s_Page_126.jp2
7fa9d4ea33dfe9cd423a0c7ce9d83ed3
70ca52e732ad1f1a143782320a89066e137e119b
2500 F20101206_AACHPL degwekar_s_Page_153.txt
d02285f169ffd533be2bd3e243eb18bd
1179956ba5e1554dd43cf159ba44520d0d663331
1435 F20101206_AACHOW degwekar_s_Page_128.txt
b9315f1b2fab5fcceaf0deef86620ed9
50b0f2cac288b5cbd1bf75a16cb4392426a7f94f
29931 F20101206_AACGLU degwekar_s_Page_103.pro
57fab028a32ae8b5479c915a9542b62a
71710d85001939e1929067420bda2016fee48997
59965 F20101206_AACGMJ degwekar_s_Page_091.jp2
d5720022e5ff72d8527f3b6fffa7ecfe
ffb6511326ac48f8f94351dbacd7a52f6a70a3df
21566 F20101206_AACHQA degwekar_s_Page_007.QC.jpg
7fa287c55660925119ea4159aff6fc1d
5020a3db554f729adfbfdf58e333e467f78ddb50
2497 F20101206_AACHPM degwekar_s_Page_155.txt
df4fff8f8c8298e90e0fc8c53d06f5f9
2396db4ad23156874cf4ad0c703a0dcde3a67ac6
745 F20101206_AACHOX degwekar_s_Page_129.txt
73dbf1ccfa649c15dfa1398bfe4ea69a
ec4ba1c108534d35c403ce547d541f106f48e274
3273 F20101206_AACGLV degwekar_s_Page_044thm.jpg
534168312eb1ed2bcb67dfafbe48315d
757a062766c6b0028f1fca199b6b45b81c25a17b
F20101206_AACGMK degwekar_s_Page_056.txt
e3443fce9627fe9c11f49974aef3ce23
eaba582ff3f6c06de59f9ae0aac48740ca81afc2
785 F20101206_AACHQB degwekar_s_Page_008thm.jpg
7346899ed8ae0ffd3c18037aa016bfef
ff9ec589e848c780318688f371630fad9baa981f
954 F20101206_AACHPN degwekar_s_Page_156.txt
d27ae7daa75e214eb3429ff670dfba24
2bbc7e0ad8e1eea029ac440242b04ad26963d8ba
175 F20101206_AACHOY degwekar_s_Page_133.txt
479d5ecda49b936f7c95de449ea09f87
211d834278680877c5a0d32312b2ebff6e36afba
F20101206_AACGLW degwekar_s_Page_142.tif
2688f4087aede7d776066dc70502d882
67e432ee4a5cf10a9853419c42b93521db0fd717
1332 F20101206_AACGML degwekar_s_Page_090.txt
abf78a0e812605748cb2327b74d7bf06
63c24de49b97803d84a65864d0cf33452da9588f
2163 F20101206_AACHQC degwekar_s_Page_008.QC.jpg
6b5b3df800811b2b61630d22bb611607
f9bb02491213711dcc2d01b95668d0f8eae8b247
1327 F20101206_AACHPO degwekar_s_Page_157.txt
e17d477816d7dbe1db25f4d4a439b9f7
2a578b8de6a7d814f7d78a02743f288f546f86df
2494 F20101206_AACHOZ degwekar_s_Page_134.txt
7f36c1ccf3de38460a45b510775fe731
1cfee756990b785fd2b52c702ba0a4fe30115d2e
27766 F20101206_AACGLX degwekar_s_Page_102.pro
1ad0519c5954cd8f821b41b5c052eaf1
68dd94228b480f10917a2321e810fc893492521e
72937 F20101206_AACGNA degwekar_s_Page_007.pro
ebbd3e225ec7e1bfa9ead67d432e8954
7c395ef2b9a3cf9c14111c4f02fb85c8524ba74e
5974 F20101206_AACGMM degwekar_s_Page_087thm.jpg
f1e570c7b964c0e0c2e42c5b0e8d4c09
f29ec4c628c5a20e011b2bcf4a32141155d44731
1763 F20101206_AACHQD degwekar_s_Page_009thm.jpg
6f5dac2cf01dc3358741ac4df5b4957e
69b758ac322cf492c8f7f5566ca4d582030f33c7
3339357 F20101206_AACHPP degwekar_s.pdf
2f2cfe48f4a1cdc023ca3ba28c925014
3f92f22b69974d57395c7c8c27361d473d10c3d0
2144 F20101206_AACGLY degwekar_s_Page_051.txt
c62760262d4b16f2fd3aa2361196df50
2258995e6d50fa196dd59189d758b5caf54aa366
100600 F20101206_AACGNB degwekar_s_Page_094.jpg
ae663500161a5ffbbebde7c9415a199a
862ff4e6df7206d33fa30d39097c0a181ab8fd47
107409 F20101206_AACGMN degwekar_s_Page_148.jp2
9bd79af8d1c705b0122c2ca7bb891929
a56acdde4466465221f8351cfa21bcf32b2c3f2a
6035 F20101206_AACHQE degwekar_s_Page_009.QC.jpg
ae6faffd9e5b7e547c55535053e1b012
b94c0ab8a59eb844e836bdf3650158a5f2661a31
1728 F20101206_AACHPQ degwekar_s_Page_001thm.jpg
7cb58165c325567416eb9a41c4d2ad7c
d0cc752ef6ec7c96c15816330857e149e6837e6d
13301 F20101206_AACGLZ degwekar_s_Page_105.QC.jpg
56a54af7665f57f8d702c29e37aeffd5
3f1b694186f03aec62f1b20a7ee41ffb66863cd3
92070 F20101206_AACGNC degwekar_s_Page_041.jp2
543ab868e42dd1b5f398841409159dfe
0b6927d952dd2b831be2a49e0a378ef2aacf70fa
6497 F20101206_AACGMO degwekar_s_Page_069thm.jpg
6d1dd6a25a7219789a5f7bf2b5f08999
2abbbf3a4b385b8d7389b3a00808f8579af35983
3660 F20101206_AACHQF degwekar_s_Page_010thm.jpg
d2ca534c21d572b89eb82e0ae761ffd3
79f37d83ae0d718cd66e2fb1d38f1b0d80a62f0c
6997 F20101206_AACHPR degwekar_s_Page_001.QC.jpg
1508f062017de8b7ecc9b1047ce486c9
cd4f170f3f32631b6bb51018f54008f8ea15a076
6996 F20101206_AACGND degwekar_s_Page_072thm.jpg
6fda5e8f7f6fc26c2a0401a4aa282361
f68db3d52f703e15916e50fd975f087b3ae1d6d2
26738 F20101206_AACGMP degwekar_s_Page_004.QC.jpg
84b06987af1c4da7594c60ed015880d2
8fb977c125c22341544c03ef0f90ba8801910df2
13887 F20101206_AACHQG degwekar_s_Page_010.QC.jpg
61d263c2031e03e2a28de9904e0fa54b
bf1a44cdbc1616f44146aa2e140572fba3204139
460 F20101206_AACHPS degwekar_s_Page_002thm.jpg
5ad6da0518ad7b0db3e8d3a8889035ea
1a394cb2c46d3817b2b331a69f6509512b0c1148
62799 F20101206_AACGNE degwekar_s_Page_153.pro
142522f31cb684491a9728b8cea0fb52
409845ef7b694c2e2cfe1289ad3597cb78962169
6520 F20101206_AACGMQ degwekar_s_Page_052thm.jpg
1fbd49861ef6a71042fdcb50bf2d3bca
884d9ed1fb080be0668e0f9ab8d01b0df0d59c84
5520 F20101206_AACHQH degwekar_s_Page_011thm.jpg
bcfe0d6c7e8d18cad474a1e1008bf745
56700a2f92fe72881e37577ffb403af0c6dd15f0
1072 F20101206_AACHPT degwekar_s_Page_002.QC.jpg
65ce31b48b02cbe86fa59662470795a7
2d7fc7b874586a10fa460a416c471214fe1aa16b
1425 F20101206_AACGNF degwekar_s_Page_075.txt
b04e8ad768347aaa485c954b48c010c6
a80ed891d45bad20701842168cbb82ad36b8b0fa
1585 F20101206_AACGMR degwekar_s_Page_047.txt
3dbdaf8a01cad9728497c4f368bf7f5c
1712adff99e0786e25a9ceb86b85df4146fba837
22301 F20101206_AACHQI degwekar_s_Page_011.QC.jpg
02bb43a7455fd732b050d64126b54782
5b54a53da2de09a1cc9c7e7c3ea5c83473d04860
511 F20101206_AACHPU degwekar_s_Page_003thm.jpg
7e0a1932c420c32121c9113518e8e9bd
8dd25d0657d634b13c0820097e17349fa24bc7cf
91975 F20101206_AACGNG degwekar_s_Page_024.jpg
f46653318fa24f8a15f32e3696ff485c
0ab75b4e95409bd9f8da15c4e2c32d699e9fef98
6955 F20101206_AACGMS degwekar_s_Page_141thm.jpg
c4bf1cc623c59218151230c17d1daa37
810532fc9ab822745e121099ae8511d73fe8251f
3085 F20101206_AACHQJ degwekar_s_Page_012thm.jpg
ce181b5d329a16a2af3a963d3107bad7
11076ccf7a0b5b36a64817722da035641a6d2d30
F20101206_AACGNH degwekar_s_Page_031.tif
1c37767527cc5b980d75c3a7b696596a
ea9087b0e2ba337e85f8aaa6278ccbf116344bbd
12762 F20101206_AACHQK degwekar_s_Page_012.QC.jpg
45656fae14963ecf44b2f49a1b06ca92
fd2ecbede9a5269bb88068fdbfa44c3e80de17f1
6498 F20101206_AACHPV degwekar_s_Page_004thm.jpg
bf39627ffa1bb42a36886a7b06bdabf8
f792fc7b9dfd5fa0db992da164181056f0e10553
35183 F20101206_AACGNI degwekar_s_Page_115.pro
486e86e96efa015e461a36e8a5e79a20
359805fbdf0d99ba6290c68a35adede986ca6e0f
F20101206_AACGMT degwekar_s_Page_132.tif
7438af38574e8365274b91441f7df0a3
6f8b7494dcfdd8c95bc0aceca6d74cf818927ef9
6209 F20101206_AACHQL degwekar_s_Page_013thm.jpg
ed55547c6187a1d70936228259766608
8a69ee39b6cd147bf3f1e69e124f6c8a636f414f
1632 F20101206_AACHPW degwekar_s_Page_005thm.jpg
deedf2cd388beb8840408d829ce6dc3f
9562e7d41f91a203e701e96e17068cbe7dfa20c9
5873 F20101206_AACGNJ degwekar_s_Page_120thm.jpg
cfd98897e90f7bb3aab1e01ad78bd9fd
460c36620954bdec81ae6e75afda71af51c2d65a
F20101206_AACGMU degwekar_s_Page_082.tif
e2c2010a02b91605c49c647f8b0d4de4
c5ce02f2447d3f1aad3fcdd62fde138888b7703f
26635 F20101206_AACHRA degwekar_s_Page_023.QC.jpg
93cc7a2d9cd1bbac63084a0bf8306d02
1c3c6f6b760497f88e635c67729d31792dd6ed5a
26722 F20101206_AACHQM degwekar_s_Page_013.QC.jpg
8322e9f11653b9bd2bb915658aed03d0
d57f352654b2102c2b5ee948111e123da173a92b
6294 F20101206_AACHPX degwekar_s_Page_005.QC.jpg
9bdd5038360ca0a99d4091f5c632356e
73f57ca8ba568e3095017907946004c10461eb9a
33079 F20101206_AACGNK degwekar_s_Page_140.QC.jpg
9d74b8ed791a6afbe9ae2200ab673b68
87ddd8aca6a456186fb5fc2728ebaf6322538740
1871 F20101206_AACGMV degwekar_s_Page_125.txt
e5bb185a6b99ef9b19d141a011efb5a0
f59fdc49a323203bb064b4630d52a631c7d630b9
6594 F20101206_AACHRB degwekar_s_Page_024thm.jpg
fe064eb5913cdecb47a5b8f34123f243
620b84b462a7d15e02fc6d18ad023fbf99370eaf
6561 F20101206_AACHQN degwekar_s_Page_014thm.jpg
8ee78df08314125ee315d06c6a3f5198
0f5893bd0278cf4685585ff5ef7e7b77b8c5182b
5002 F20101206_AACHPY degwekar_s_Page_006thm.jpg
cab767c6408402e844e5dfc011a39b8c
0259fd4c39af6559af2f405eb773b8cd3e5bcc14
2221 F20101206_AACGNL degwekar_s_Page_022.txt
f99cfbe3e0b09b8f4f9f4c119ee51c3b
a2ad7271c212c3b1adb7749f1195d17d7340107d
81660 F20101206_AACGMW degwekar_s_Page_086.jpg
40baf706f5edc4ec194f87eda9d51644
a61188fe0cd59fa438955205d03b737c4579a263
29230 F20101206_AACHRC degwekar_s_Page_024.QC.jpg
b4e772fe6114fce9ad79750dea240407
dd1e93ca5a0a02f59dd60ad09efffb4c1b4e8903
26406 F20101206_AACHQO degwekar_s_Page_014.QC.jpg
8ea6c666a2deef6fa5faa3fd7999115e
7e7942f2faf7c17378354b53f3b072bf860c3ee3
20512 F20101206_AACHPZ degwekar_s_Page_006.QC.jpg
1da07c8b0fc7572966ed79eb709a6c4d
8a4fff025b3973d05ff4e828921094540131e2c6
2006 F20101206_AACGOA degwekar_s_Page_087.txt
33f220641be686e55136d34ad32d80aa
fba18b3c25891be319f5bb5e0ae5364e93f1f8a0
84927 F20101206_AACGNM degwekar_s_Page_148.jpg
d3b69954355a2de8dfe930e5d1bfb3f7
b16cb8efa8e83f8feaa927b315b39fa6bcae15fe
23557 F20101206_AACGMX degwekar_s_Page_124.QC.jpg
9adb04b4c7dea8f43b2ecf58370ff31c
469e16f3acfc82b21e3187f00d31b46099fd000c
6663 F20101206_AACHRD degwekar_s_Page_025thm.jpg
ac0926b201e7fa0714c7cb6c51e280ac
2c6a88873a4f3febd98d52ec0c3cacf73cd28779
6564 F20101206_AACHQP degwekar_s_Page_015thm.jpg
3f2d797fb6b3fd8a1c3ee28e1e310ed1
729c23330c391cf6e106f5e3aa03aa06e5fd164d
F20101206_AACGOB degwekar_s_Page_074.tif
c81cf0f4fe666f357ea777428d059425
5f3aa033e34b428aa83237fd930a96b73730c2b0
12441 F20101206_AACGNN degwekar_s_Page_099.QC.jpg
01258e0bfb7f09a1c10def93ec6f832c
424a141e837a5c3c3bd59e5a7c0599ebd718852f
121571 F20101206_AACGMY degwekar_s_Page_070.jp2
b4371a859e85d9cd84e5065935418bd5
aa15f998a593bfbdcb8caea76089d1414079cebb
18903 F20101206_AACHRE degwekar_s_Page_026.QC.jpg
166a09dee7f2b07ce8a0e6ad3d3b69b3
41435135beca12aeef61fe314414f02fbc2e6fb4
28066 F20101206_AACHQQ degwekar_s_Page_015.QC.jpg
179aca44b96df828c970141d9c443182
ccccb786677c517c577e3c6a027c68968a0065e2
F20101206_AACGOC degwekar_s_Page_072.tif
2a7905cc38834c0dc871b6d6ce24248c
4a299ca99e7ca61975c24564d720635f339e0fdc
2181 F20101206_AACGNO degwekar_s_Page_073.txt
cb636f6cc5d7ce3a081c0f39b997ac4d
b1db6552d9a02f6383d096f2ad49dda69ee225d9
50346 F20101206_AACGMZ degwekar_s_Page_101.jpg
a12e38c4f94902ebc5085ba02cbbb12d
99d5d880bb451cd32c58bb05c795fb47d27a6c80
6490 F20101206_AACHRF degwekar_s_Page_027thm.jpg
f8a52ea694f569029c919b0479ad6170
8389acac7215f32618a40347fd5bc1ae4459ef7c
28621 F20101206_AACHQR degwekar_s_Page_016.QC.jpg
ad97b1e1263ce9b29a01ee8b08ec70ca
d6c99a1acfbf9c52c4f3d249afd28f392ab4e115
F20101206_AACGOD degwekar_s_Page_157.tif
17c102f735faf58550dd76105d607b42
812ce8a4a99b19d27e4c8d178f7e1259b599b5e5
F20101206_AACGNP degwekar_s_Page_118.tif
c9a13c1858f985065dc0bc0f0d5e4deb
e712bbd5f76af509ba2d7ad966e7aff24bc5d5f4
27035 F20101206_AACHRG degwekar_s_Page_027.QC.jpg
bd95eafb4774613c977b3a90d6d3391a
88b016b8ff205fb2f26f2a85b1f9f329a49f2be1
6534 F20101206_AACHQS degwekar_s_Page_017thm.jpg
6ef90f3ec495cb4a81892f480b13e4e0
315aec16eb9f4099f851d0e7ca866be1dbafc5cd
128110 F20101206_AACGOE degwekar_s_Page_140.jpg
2cb358d8f90efe1967be2e0ae9829938
1ba34e4d98494c80d188337400e2ab309061b799
18345 F20101206_AACGNQ degwekar_s_Page_157.QC.jpg
d8885950dd873b229f1d912b402787ab
8fb5695b93f1cdad1b99493d4ac6900b3bd48bcc
5772 F20101206_AACHRH degwekar_s_Page_028thm.jpg
c3925f623c4327bc6df7828f7c41362a
10a478a99e0cfa62c7f28a41d04d22dd53bbbc80
27375 F20101206_AACHQT degwekar_s_Page_017.QC.jpg
376d88bdef106466b9aab355d6f67ed1
b59834bc1e54035ac4e72dd8ebc43f9b82df643d
45413 F20101206_AACGOF degwekar_s_Page_056.pro
2d31f2551de00e5ff0696d861c8b4574
d999cd9233ebca3150b51e464dfbe06d05029d92
111813 F20101206_AACGNR degwekar_s_Page_067.jp2
70564f40e1a7fd6c856919f3c5345ff2
94c88de96fa2aad2bb49b1e9885cd7c87e075dce
24070 F20101206_AACHRI degwekar_s_Page_028.QC.jpg
6bb14a37739176fa90f218fe0e75ce7e
f7e0ebf13110f44c34cb4f255b14a0c357873933
2780 F20101206_AACHQU degwekar_s_Page_018thm.jpg
1117221836b9ccb088e78f41e5ef673f
e351e139959c57d2ea3a2bae33ca3ee928e18c81
51097 F20101206_AACGOG degwekar_s_Page_122.pro
071ccebeacf472d2dec4953c84490ce2
94147193d58e2a4247bf3e9602c892c04d1af6be
1237 F20101206_AACGNS degwekar_s_Page_045.txt
562dcde802f223e9441101c984a3fa1d
9ba676402b0d63e6d7d3bc2016f63aa538610332
24908 F20101206_AACHRJ degwekar_s_Page_029.QC.jpg
5083bcb8620c4b4a23c65a3c7283572b
bf4b0c713f8120312ca42f03dfb6131b6ecf169d
5715 F20101206_AACHQV degwekar_s_Page_019thm.jpg
dc8ca82597ab373e7425a5f9dfc4259c
e07183ff39c4c0111b967ff1b48d9f432481f8c1
79600 F20101206_AACGOH degwekar_s_Page_033.jpg
2e2819b7f3a8e577cf14532572c7f42e
dae1f9ae48160109cc1fd39745c25f3a0ff9087a
29114 F20101206_AACGNT degwekar_s_Page_066.QC.jpg
fc9a26f4a754e159da0da26e128511c9
527797ed16ce8769d6e522edf58944473e8d2d82
25552 F20101206_AACHRK degwekar_s_Page_030.QC.jpg
d471126990cad6691a8d95cabb0664e1
782f992b38137210724d6cbc7343c96e6094c7bc
35614 F20101206_AACGOI degwekar_s_Page_130.jp2
e837111fc67c40b3ba55bb7d8f61f254
cf6cf30c19b8f2294537375bbe91defb40814f5a
5060 F20101206_AACHRL degwekar_s_Page_031thm.jpg
8c2e99d837b2b910e3f30b4d0ac5556c
91c4b2185ac5aea13036aed08e485befb1a78b66
22410 F20101206_AACHQW degwekar_s_Page_019.QC.jpg
0db2b3a1b62a193596244bfe3690c38e
2021337f3d51e4ada7edc7032152738c6b2d6cd3
2289 F20101206_AACGOJ degwekar_s_Page_080.txt
42608d9111fc95714801c6a39983cad9
b63341a2a1e234d642b3df65aa1c2d54141cf105
54476 F20101206_AACGNU degwekar_s_Page_051.pro
73ec7de95b374ace17aefdec5b88873a
025e81c9c87f30b429fa66fa1436c13961d4e7b1
21324 F20101206_AACHSA degwekar_s_Page_041.QC.jpg
1fa7d1a4ed042025b70572ce122513bd
78bcd1a0e24bdc5d925fc54fd614920555a027f3
19967 F20101206_AACHRM degwekar_s_Page_031.QC.jpg
5a805fe0985446aab83cc9eb591fda0b
9dfb0dfd0797e444e0866e80c4cd9e9584c2aff2
26339 F20101206_AACHQX degwekar_s_Page_020.QC.jpg
86833ffd02c3786694f73bab6bb7850a
2b31f4c2ace0f75437173cf9e3237eb1decaf6a8
F20101206_AACGOK degwekar_s_Page_136.tif
54b7a53d8a7aa2455400d5c028699ff4
f9f7e415572cdf98ae4274278afe380cadd889eb
11475 F20101206_AACGNV degwekar_s_Page_018.QC.jpg
0eccbdf83f092e77a5868e845abc6cdb
a21c03781b0a64a509dad4f0703026af75fb33fa
6745 F20101206_AACHSB degwekar_s_Page_042thm.jpg
d66819979412311c294b7e4888ee3981
6b90dd6cb451a1129dc400412e2086a6a8f50cae
5667 F20101206_AACHRN degwekar_s_Page_033thm.jpg
76def0765ac444829615898372d1a638
0f7a3fc90dc0b56b735d1b5b30e56c925a2b9b30
6084 F20101206_AACHQY degwekar_s_Page_021thm.jpg
25f7a1fe71ec77e8c5128422bef0a681
b3afcd1fd27d15c76eca8406fd04e4828e7dc29d
66538 F20101206_AACGOL degwekar_s_Page_101.jp2
b4b8a9c6959ab67c63d47351c33cb9cf
63c007b235aa44e026aabe0b5e18cd91c120ad78
1670 F20101206_AACGNW degwekar_s_Page_041.txt
67b9c18a426534e6c0020ef8f3694938
12a60b8f0c3dd06217596f59e61ea581ffe5b686
28213 F20101206_AACHSC degwekar_s_Page_042.QC.jpg
db2f2a98fcf88e7027ce1fb2fed1e4a7
8f97489bc045d3fc49382facff15ce8b08cb6138
24110 F20101206_AACHRO degwekar_s_Page_033.QC.jpg
1dbbd2be20ccec7f09891d742c08ea30
96fc1fdc3ee917c74fc7b773fce42ce0f945db87
6109 F20101206_AACHQZ degwekar_s_Page_023thm.jpg
0a632783094debeec84991126781610f
948d697c1c8f2aa61d2892903534aa1ccc225894
53199 F20101206_AACGOM degwekar_s_Page_069.pro
83664d91760d8393afb1673c6ef5d7d7
9c29a8a4f8a6ba5288b2397cc103a3bd06be87bc
108654 F20101206_AACGNX degwekar_s_Page_089.jpg
e52e3d50e571f83c47356a6d8c0ab173
a7734c095518f909bb23c1f1811b4ee48e9ecdc2
82358 F20101206_AACGPA degwekar_s_Page_029.jpg
81e379ffa7b11127e779f6c3f85444e1
ae7d4a13848e87675a7202d4908b958673094630
18412 F20101206_AACHSD degwekar_s_Page_043.QC.jpg
41d2b139c49c5860e1ccf5a89619d29d
5001ac5b2ffa22ab63361bf849c7f8a3432a8854
25135 F20101206_AACHRP degwekar_s_Page_034.QC.jpg
6aa60009e904a7694c6fb6eed653106b
055a3a8cb00b94e5a52ea06cd0ca72e21bd2e1de
3553 F20101206_AACGON degwekar_s_Page_108thm.jpg
9fd80d45204df5fa3eec20fc84ad7fbd
b0b268df2b5edaadbdff54781ca968fa0e841d9b
6432 F20101206_AACGNY degwekar_s_Page_048.QC.jpg
5721f148a3829d2a646008a5adbece64
2a8d43ea33aa92d946a9ba22d4589624873a1eb4
51352 F20101206_AACGPB degwekar_s_Page_034.pro
b760c1f1d53a56529c43882acded5e66
0cd0baeefdd4e73c2100f989fedffb9b10acc05e
5446 F20101206_AACHSE degwekar_s_Page_046thm.jpg
f3d8a5d56e61aa9d5c7dc5f834eb1156
d5110a07436d03c6735b65ff3328b71c7a0c6c7e
5769 F20101206_AACHRQ degwekar_s_Page_035thm.jpg
ef394909bdfd38e67390cb449ed4f989
7ef9b2df8426ae272143d910dbeb5bfaec579c1d
73621 F20101206_AACGOO degwekar_s_Page_127.jpg
009f052850ea107969791d0429daf6d3
c37201495a5255b142a392840a72b6812686b0ed
52012 F20101206_AACGNZ degwekar_s_Page_142.pro
6300e8d8db172ba2aa065dc7ffacd6aa
67f155c813df793711d5800096bcb03b27dc81b1
3007 F20101206_AACGPC degwekar_s_Page_140.txt
97ec9c273cfa7c7981599819dc5b9c58
0b887b9cc534b6d0cc7e68eda81fdb7bd8afac53
4909 F20101206_AACHSF degwekar_s_Page_047thm.jpg
1452bb59301f536edc06ddb10aa81814
530003e079767b28fa9666c835fc98b7970f18f3
26103 F20101206_AACHRR degwekar_s_Page_035.QC.jpg
19e37cc11e347e9d9662933c8e4229db
d46a2720d3d47dc49aaf5b4a043b3b0d97979d53
22946 F20101206_AACGOP degwekar_s_Page_148.QC.jpg
22dc7d3967066ea4679dfa8aca6c65f8
12fcc2a43e831e8c62b633ae45f50f3656a63cdf
18713 F20101206_AACGPD degwekar_s_Page_048.jpg
3769b8910bcb4c0e31157ef128bae37b
f48215798fda991a0c1d38d51fc41412b67190ff
20780 F20101206_AACHSG degwekar_s_Page_047.QC.jpg
ee09b3ce08233bb407d85607d53cb0a2
30cbc261dbcdf6ee0dc66dc1972346827b549c21
F20101206_AACHRS degwekar_s_Page_036thm.jpg
d4c4ca6690c9ebe81fe04a062b873766
b630d678956327bd707d6665a55a589acb9d9d7c
49276 F20101206_AACGOQ degwekar_s_Page_148.pro
6f090ecab70980dba62d0b55fbc08dbb
9f59e97ccb7244cb2a38e8494cb0474be6827fc2
90140 F20101206_AACGPE degwekar_s_Page_073.jpg
1d8c81acee608a2a46380fd119662178
ff620924337d21b40d526bfb0a6246221d81dcb5
1986 F20101206_AACHSH degwekar_s_Page_048thm.jpg
979d16193b3451be1b9a0cec82528b8b
162297de305859d378f6d384c0012fb18695ee35
26832 F20101206_AACHRT degwekar_s_Page_036.QC.jpg
9ba29ebeb29d44ea1d00ec6bc1dfb3df
9b29c34bdec83ce927d8b08d5d6c4e7f67e222f5
113556 F20101206_AACGOR degwekar_s_Page_027.jp2
e7957f0c1358d922983e40ea275d1920
eb5b6785be836705a060c7f77890666eb4e55fb2
4732 F20101206_AACGPF degwekar_s_Page_093thm.jpg
b024ace13b2b8438f799547b89fbbb49
0d49f0d3fae685d57aec562bbe58ab260307fd2c
6441 F20101206_AACHSI degwekar_s_Page_050thm.jpg
5e0eb0353d0a9fa8ab631afdc846be46
d3fdb8441c3e1067413efbb9a2d7df335d1b568f
15264 F20101206_AACHRU degwekar_s_Page_037.QC.jpg
548ccaf4ec4240d334fbf34ff4952dd7
964e310c5f7e911989837a27e0972484d71ea21a
3887 F20101206_AACGOS degwekar_s_Page_133.QC.jpg
5895ab2d709429fea66bfd5367057993
1b5fa74f7cf586cdc8d675357e1c9e4e7f92f3a1
114950 F20101206_AACGPG degwekar_s_Page_063.jp2
eece00349d489a176f6e52e9c8d003da
db89fba4d40d0c46bcbb63fa8ef36f2f66d7b0c2
27083 F20101206_AACHSJ degwekar_s_Page_050.QC.jpg
fcac6894d9b0e115045ec8043bc6c2fa
ac532aff2094ac30228ac540d0185f23ff91775a
2612 F20101206_AACHRV degwekar_s_Page_038thm.jpg
b5c23adb4b274635848190bf01ef46a1
4d5c5d317c8595b2547059971f5a27748a4616b2
6505 F20101206_AACGOT degwekar_s_Page_051thm.jpg
8946c7a9eedd3568c64b3f14ac837869
7897543453cb9eb8c1e44f9ff48f1f4349cc0a7f
F20101206_AACGPH degwekar_s_Page_045.tif
ac6188ebca7720c474c380e23767b7aa
11943a7a0a4aa1e739e6b7da511afb1be1dfa022
28626 F20101206_AACHSK degwekar_s_Page_051.QC.jpg
221aa229c1f81f378f8d441cc1116fc5
e6458b6be490b641c01f27c32f4c321f6cc672ec
12944 F20101206_AACHRW degwekar_s_Page_039.QC.jpg
7ab0dc5c47909a2c09a5b962d3c88091
5eb5fa2e17f987704352ffc392a45c1822e46d7e
25896 F20101206_AACGOU degwekar_s_Page_049.QC.jpg
328a1b1caeb091f7d1366e50440f30e0
15fa8fb5a05276873a28059b5733a4a0bb59ab46
99990 F20101206_AACGPI degwekar_s_Page_087.jp2
e3958c1fb818a47f2146a9679c849a1b
5114bb2c86fcf2580a105a49ac52680c32e386bb
27795 F20101206_AACHSL degwekar_s_Page_052.QC.jpg
dfdd03e0eee16d9b6c178fb6006730d1
441d5f0e85b064c45969ae3eb1ab76cc83d12375
6225 F20101206_AACGPJ degwekar_s_Page_134thm.jpg
1bb6effc485f04f6812d56f10bdada4e
7c8860bceaaeb54e37c99e9aeeba7a61d08d76f8
6499 F20101206_AACHTA degwekar_s_Page_063thm.jpg
97dd71d91cf1f4aad3ac605a080b81ba
810213b55f38117ff0b6bc58a0e7b609adc070de
6504 F20101206_AACHSM degwekar_s_Page_053thm.jpg
733202a1966b87f76d0f6978aaae7699
126dcc3ba6c2ac33bd06945e4eb964b1b57fb571
4111 F20101206_AACHRX degwekar_s_Page_040thm.jpg
58a71908175b3b0c0d7a96d2a33a48ca
9edf5dd63b40357a032dc4a20b9cc1f74ebc83af
28712 F20101206_AACGOV degwekar_s_Page_025.QC.jpg
c1f2b77da131891aa2acfe9b5afea96d
96bbb01d74c2b7af3833776004b99a5c77f4b58f
F20101206_AACGPK degwekar_s_Page_131.tif
c47aefbb831df7189dbba195b3ce1a42
fb068c979fa7925475679de4fc8d6d0a5c03163d
26966 F20101206_AACHTB degwekar_s_Page_063.QC.jpg
8f3155fb2c3e5151b38e175c48ef8c85
9454cfa303e854603e128c922bd71bc12d32b892
26737 F20101206_AACHSN degwekar_s_Page_053.QC.jpg
34b5e0ebc016594060ea4de844fde1b9
640f2a0ee0abeffb821876117001ef8232ca495a
16817 F20101206_AACHRY degwekar_s_Page_040.QC.jpg
7aa418b55d77a636c4537f15d1336346
8beba4ba49046b7ef8530b30bdf758bde5d1a64f
3695 F20101206_AACGOW degwekar_s_Page_045thm.jpg
2fba9dac748de0d0cb50bfb027db1a5e
d15e465ca98c0e939857592c42f3ddb8fd5b6d3a
54364 F20101206_AACGPL degwekar_s_Page_144.pro
7929034bcf55338620150e4414530949
c055985039cd9f1b46dc8050f5e840d5546ce624
27026 F20101206_AACHTC degwekar_s_Page_064.QC.jpg
a9bfc0be912b6074338dbb11e35317e4
a7627e0ad0586547e2372d47a85665b2af96284b
5116 F20101206_AACHSO degwekar_s_Page_054thm.jpg
c9b9dc44b9951d5502793f29c3ec7afb
ad716d9e3036d30791f29741cec1e9d401b38904
4964 F20101206_AACHRZ degwekar_s_Page_041thm.jpg
efb47c3f776cc86ac6d89ea709ef469d
cc4a62193a623997f44c94d023770b45744a2ffe
15815 F20101206_AACGOX degwekar_s_Page_100.QC.jpg
fb6640b685dd0eab428c27e1cb72f017
2b45e4eaac583aeb9e7f19ce0266a3d38616b03f
F20101206_AACGQA degwekar_s_Page_043.tif
52e8e3e6acb98502b1d68be2ea98ff27
994bae41209e419cca3a27777777b0dc7d47a917
6483 F20101206_AACGPM degwekar_s_Page_064thm.jpg
867f8a5620742014335314a4d619523d
a8edbde58ac25ea2edb89eec3d0e270b0e6d91dc
6701 F20101206_AACHTD degwekar_s_Page_065thm.jpg
82fb624f11ec67ef92e87d1f2f458ba7
aaa656b8a322e8c893e046a66a15567c419ff9f6
21332 F20101206_AACHSP degwekar_s_Page_054.QC.jpg
5f2b6fa601912ec913093cb46bee644d
36da84533e2e842f977ec82e2bfe3063ca814a69
177 F20101206_AACGOY degwekar_s_Page_112.txt
b163d71e8076de1680dfac8416e2936b
e392a8b0bfbdf0fa20dcbec9fade7917a48fee35
779 F20101206_AACGQB degwekar_s_Page_130.txt
8e0dd6f21f40048f687c624d941bab2f
7788472452d4c8b782e99d37db3fd52a49447df5
2359 F20101206_AACGPN degwekar_s_Page_008.pro
b5d4fe5acc1521e2ab37d4ac45a3682e
b1ade230b68484929cbd4f1c66e2386c7fc7bb95
28537 F20101206_AACHTE degwekar_s_Page_065.QC.jpg
ae9a4bf19226d4230cb52e4c13c70302
2f4abf176122b7cf41936db0994307af0b2cc0f0
1811 F20101206_AACHSQ degwekar_s_Page_055thm.jpg
480fa160fbb4e4298e21d32fb4b53133
230400ae81b833686711ffc91369a2a821ed9c24
106139 F20101206_AACGOZ degwekar_s_Page_138.jpg
a13c1dadc943ff875ad0d8b8e9b2e63d
f80a43edc78dcbd19dd487883b695711b3773b4d
34786 F20101206_AACGQC degwekar_s_Page_106.pro
972b19e13731e1b17ca2eb42e1418c02
c3a394f1ed06adf42e232dfe572b430669ea0433
6037 F20101206_AACGPO degwekar_s_Page_034thm.jpg
7bf64bd77c4323f50bab4cc3c447c1b4
79527c29e54b5f5620e6afb7ab854613cd40373f
6900 F20101206_AACHTF degwekar_s_Page_066thm.jpg
02629fc2ea3d52b2239c348adc6e6b4f
e9a4ccbf7f8125684fd21926952bb1c38a11f432
6396 F20101206_AACHSR degwekar_s_Page_055.QC.jpg
bb616fa161b18800cd215515b2419e05
6227b7204eab45c388d1ec335ced23d53bcd34f1
2061 F20101206_AACGQD degwekar_s_Page_014.txt
ab0c01bfd2920016358e8af1a33e452c
b0dedd952a61383f28818aba4cd257e43457b403
6440 F20101206_AACGPP degwekar_s_Page_135thm.jpg
c832a0833fa6dd0e03d4ea755d2ef992
2d92028467e4f8c0d656468b8cf1b4b76181b888
F20101206_AACHTG degwekar_s_Page_067thm.jpg
1113b06329f2a45b26f594869567ca7c
6db6177e8d60f1e03f867c60f20e0b71ca9f6be9
5562 F20101206_AACHSS degwekar_s_Page_056thm.jpg
7876f21aa8d81ba6c0ccbc5a396c4fe4
07334142cad3aea64b7b15eb3b6590edde82bdae
F20101206_AACGQE degwekar_s_Page_090thm.jpg
7717f59565001e2b76ec5a7a7d899b2d
4f680ab5575e5df0a9ad8a032d70e450aca9d709
12964 F20101206_AACGPQ degwekar_s_Page_062.QC.jpg
66eea9bf85731cadb1dfba5552a062ea
4df51f49a54035160d34710c4ed758819ba390ec
26420 F20101206_AACHTH degwekar_s_Page_067.QC.jpg
7f7baaee373fd7a6694545d4c0642f55
adee67095f0bceb413cbd4ed56b740063c327509
4038 F20101206_AACHST degwekar_s_Page_057thm.jpg
afa650f6680e2be3ae5eb8e0107c0fcf
c4d770db916c3be1d3f98c085cd738c13b6156c7
36203 F20101206_AACGQF degwekar_s_Page_077.jp2
ec0bc0f3a95465c7d44ea0ade12b3b01
7f697307dda3fa2c2dd815054308dd74c788e3ca
28864 F20101206_AACGPR degwekar_s_Page_022.QC.jpg
60a11bcdfdff13157b1cb938b821b3f4
181ce227465a4982d71330c1eeb7dee405c28f34
6898 F20101206_AACHTI degwekar_s_Page_068thm.jpg
8b0e988cf3c90fb1ec45d1b3fe1251f2
4d9867db97f98fdd2671b972ce48f8035428fe91
15842 F20101206_AACHSU degwekar_s_Page_057.QC.jpg
0c5e45541288d03859dea016d801f575
69d25dd327957cd37252a2d295700f3e304bef3e
117114 F20101206_AACGQG degwekar_s_Page_025.jp2
d2306b1bb27d454476b54853d0a3e811
8db7d6b9d87196888dda93af2c9255432a486fa2
44859 F20101206_AACGPS degwekar_s_Page_011.pro
6105fdcd924760d398c1dae90f7e3891
fc6636cb63a2d58c0b450ad65487b2b0f5b79d38
29386 F20101206_AACHTJ degwekar_s_Page_068.QC.jpg
068de7f1de2fa8b1ec7e4d0474c96c5b
437856f2c37145797dceca16ca2d5707098aab4a
20466 F20101206_AACHSV degwekar_s_Page_059.QC.jpg
6e61ab5c48c1c419b28e72a1d4e05284
e7de0b4f32b74d44298a1e791d946a33983fe0c2
24705 F20101206_AACGQH degwekar_s_Page_087.QC.jpg
fa28feeb8b74dc34eefbbe232eaaf842
e7fe695b77cae9b22a95944b33ae32f4f21948ca
48267 F20101206_AACGPT degwekar_s_Page_087.pro
daf2c7e1ea11a747e52e294b47fe8ec5
916ea7491ec2e27e8ddd54f9edf2c38f1ba8fb61
27199 F20101206_AACHTK degwekar_s_Page_069.QC.jpg
53c55cdb4a45db5fed2fa7f48c2337c5
84ea8ad3753577518d148adee42ed8f1c1671a61
5302 F20101206_AACHSW degwekar_s_Page_060thm.jpg
f7da385a96acd1293dd5010b6be0d6c3
4866dfcbc3f04c1a3dfee7d87802769c115e37c7
1962 F20101206_AACGQI degwekar_s_Page_011.txt
836ea0278a3b2195712ae15563a61c3d
8d53f7bd27914e4073c373940c420050702c6cd8
F20101206_AACGPU degwekar_s_Page_121thm.jpg
de4bd3caf41c059e5e5b9c169d436274
3a4b9f5a3288146557771fdd3c10b54f85fcbba1
6507 F20101206_AACHTL degwekar_s_Page_070thm.jpg
e6b27b631bfa6784a8c6cea7905c3afa
8119a85cd245bc66febb74fd2fec96ac6f46ea1d
21557 F20101206_AACHSX degwekar_s_Page_060.QC.jpg
9617c6867f594d33ddf0e9965527469c
bed0c6bf42132cd6b387b795cabed3c56bd5d2f6
120236 F20101206_AACGQJ degwekar_s_Page_016.jp2
9745ea268f3d7c18e2517acea2dd1d4f
dc127324017a7a99b1068fc5ee96312b2d8416c8
17524 F20101206_AACGPV degwekar_s_Page_128.QC.jpg
edb97f6759df54b29274a021ecaf614f
8db9bc2a542aa6a1c63620155c1c4a8dfdb9eef0
26746 F20101206_AACHUA degwekar_s_Page_078.QC.jpg
e84126c582d305b4f7c8b3e1f83642a4
983ac06cb59fc9a26bec2e48fd2b790ce1e58525
28511 F20101206_AACHTM degwekar_s_Page_070.QC.jpg
df36e6fae2a5c1b150477096299f2cb5
726a5de436d4b9df98841a735b0d572aa0fc7de7
6268 F20101206_AACGQK degwekar_s_Page_020thm.jpg
f19cfa2a452a6fd06abd14d7497b6904
7aa7d73d617a42083ae07565925fa6236f18fd5d
21804 F20101206_AACHUB degwekar_s_Page_079.QC.jpg
5aafbfafcc003ca2a7c10a19bffb4117
4ab33a06a594ddc2f25f5e262a6dca1c3c07068a
5644 F20101206_AACHTN degwekar_s_Page_071thm.jpg
80c1cb3e4eb8adfef4778f3e5459f3de
e4216e03f70275801b80a32afa24a3634fd57ecb
25110 F20101206_AACHSY degwekar_s_Page_061.QC.jpg
2d01ae092af4c50cf8cde81bfe45b3ca
84a3f4fbc709e818a2fe6e9a6877a9af869c3891
113251 F20101206_AACGQL degwekar_s_Page_069.jp2
da4ec1c57dbb12033cb3b616d22974bb
d7194ae48a8b9edf478714f064dac23f86447d61
F20101206_AACGPW degwekar_s_Page_115.tif
73b063d8961713fe428405c8c4ed009c
6d64b4cfdd8a9278a1196e4a8ff350ddf9dd4e90
6643 F20101206_AACHUC degwekar_s_Page_080thm.jpg
006ab88105cd56e69d727c69b7130aa2
181a1a5281af302ba2e69865916a7b9c29bd4e7f
24183 F20101206_AACHTO degwekar_s_Page_071.QC.jpg
d2a352d4a56e2caa463f4e833f3f9657
6489fe913a92eba8313e131eae4173aecf1e0297
3300 F20101206_AACHSZ degwekar_s_Page_062thm.jpg
8c2ea38fe0d994279afd086c58bb0f03
9b3afac7c737a5267b69bfef71b2a5e3aa980b7a
141639 F20101206_AACGRA degwekar_s_Page_143.jp2
42da49b69dc522bc1015cbfe0d5ef236
a21c8a8f54fb67abec5a383296983c6f8e209af9
219 F20101206_AACGQM degwekar_s_Page_048.txt
c70d7274a3161e2f89e1fb5dc1419a54
e633775b59cf554f944e768c22f7e868038d734f
3749 F20101206_AACGPX degwekar_s_Page_037thm.jpg
b87706fc738d599e505028ae4f9e1f0c
2d824eaccb61ded3f3366b335781667fe3576601
27340 F20101206_AACHUD degwekar_s_Page_080.QC.jpg
b6908285e7810ae37c36588df0b64617
a40cfd3cce0539aa3c56e601de82580c20251f2c
28684 F20101206_AACHTP degwekar_s_Page_072.QC.jpg
1ebd9da1c9cf05f7b248b9ecae6381da
91efe09ef3b4b815bc224456f0c800540556ba6b
14755 F20101206_AACGRB degwekar_s_Page_045.QC.jpg
ac334c95a5227a680dad947d7bf9d5a2
aeeaa45f397878bbe1923bccadfe7266b62cef59
25972 F20101206_AACGQN degwekar_s_Page_021.QC.jpg
a480e5dd2f00a580f32a7cec755bbcf7
11baaf1f30df5429df0d1a65a61cdb35e655d0ba
6812 F20101206_AACGPY degwekar_s_Page_016thm.jpg
5795ccf390af90d6fcbecfbcca93a5ff
93097a22b3ce66f21296710b97df718da8da8776
6456 F20101206_AACHUE degwekar_s_Page_081thm.jpg
1257e94f796ecf9ea625fb58a65f1edd
29f9d4f88136665cf8f44f547f33eea5e33b3384
6874 F20101206_AACHTQ degwekar_s_Page_073thm.jpg
ec82f7b4d15827cf34078a9bbb7c3ef0
fd9d5d1611f3046f3440ef9acaa3f2db8253d095
F20101206_AACGRC degwekar_s_Page_126.tif
79fb8801d804a9c46f813fd88b8ba5f3
6e49af3dd247afaf626591e98cff4a8fae54c2f0
4459 F20101206_AACGQO degwekar_s_Page_043thm.jpg
c021126641dbb3f69e7263198e6bf3b2
baf2896bbd0aa84a5e0e89118fd61f0a06b3b616
105692 F20101206_AACGPZ degwekar_s_Page_147.jpg
90cdc069897a478d04d00f85c8806188
e3b0668ab54c4cfe9f3ac64d57cd8a5eeca3135a
F20101206_AACHUF degwekar_s_Page_082thm.jpg
391f6269a2be9bc2fad0618e8e1e7233
4fd5f7e5bcb01e513b1b823d106acad3022f9c9c
28909 F20101206_AACHTR degwekar_s_Page_073.QC.jpg
abc6e5e38755e055fd4b76bc287f0be7
26e6cb2943d35d49f468747387095d1f95b04c95
63090 F20101206_AACGRD degwekar_s_Page_107.jp2
fa9b58920dc42124961383f394a712cf
84805d8bec974d25f0e2b80bcea5ed3c7e197937
68982 F20101206_AACGQP degwekar_s_Page_096.jpg
48d38f7755bd7497342a5a33140d7d49
40e6cda9dc618e2609bb543f8d350d8ca255e60a
24832 F20101206_AACHUG degwekar_s_Page_082.QC.jpg
5d966f6c8938a944cc172af1891a4b90
7ddf5c59aa8ed40b6360e942511321f4d5c8d776
6612 F20101206_AACHTS degwekar_s_Page_074thm.jpg
7d4dfb1d1067f3111452660b032021a5
0ab37abf8593f33786b4e5d272b4ce38285bcbe1
51136 F20101206_AACGRE degwekar_s_Page_149.pro
e8467b03ba3d28b9b27ea762d382b4bc
264b3a3ba8462cefee4740d9fbb1c68170ff30c6
2807 F20101206_AACGQQ degwekar_s_Page_141.txt
80cdb1303894858cc25cb3a04b781eb3
0ff865bde79e4153ed89af7582f196694b816d96
6618 F20101206_AACHUH degwekar_s_Page_084thm.jpg
82eba10defb41608c3840d2769c92875
e75022d2c2600eb13b81d8194cb62be26ea78866
28446 F20101206_AACHTT degwekar_s_Page_074.QC.jpg
304ea91ea33bdcba112689ae7433c37a
aa9308e72fd26345a8df17a174bfdcddea652eae
6761 F20101206_AACGRF degwekar_s_Page_083thm.jpg
d2bf7394c72333be2d883e2bc5b6ea35
1e81d9e56fc37a3ff715a491728a4fb13140cc2e
F20101206_AACGQR degwekar_s_Page_135.tif
2b7d4073acd1e48d78ab5f52d97e8c86
4f9b1fcbbc2eab8fa67263f053caaebdc75a0508
5659 F20101206_AACHUI degwekar_s_Page_085thm.jpg
121735d65458171c3b690c2bff27a89c
a612fac31965ed6282a3a029d02739ac3198972c
5028 F20101206_AACHTU degwekar_s_Page_075thm.jpg
fc3e35a02d03ce2f737b1d882563d28e
3faddd0cc01b49060f51e7adbb598988772379ac
81346 F20101206_AACGQS degwekar_s_Page_049.jpg
f65d778e2ba30af30dbff72aa0fa5bff
7c8ae50e1cc59fdd022f8fe4dd9dd957143be4b6
28187 F20101206_AACGRG degwekar_s_Page_084.QC.jpg
b525864d9b72d591f238b8667c228809
270bb625cfc5ec3f1eabed7cca5b608dd3c380ca
24172 F20101206_AACHUJ degwekar_s_Page_085.QC.jpg
ec2321b43bc2e6045c5774232acfebbd
a0ab1115a13c9f70e6157975f251e89a2dbd566a
3579 F20101206_AACHTV degwekar_s_Page_076thm.jpg
4bd82a8f50e1bfdb58756c421d3b50a8
1fc8a51947288d556736a5e5ecd4774dff356a1d
5245 F20101206_AACGQT degwekar_s_Page_059thm.jpg
5223dd1a84289aeb88932d62c3ad190d
06b37e7b59f1a4606108c18c6b0db1a0a121244e
F20101206_AACGRH degwekar_s_Page_015.txt
9f9dea47f62a741e980d74828389af4e
f8f9f00329d2a846d58f8aaf51bf3588afcc6f0d
F20101206_AACHUK degwekar_s_Page_086thm.jpg
54f5d0e2a8b11eae491a8e3170d95639
98c93db6042a30ab452c1a6cdd19f25db5cbf48b
11454 F20101206_AACHTW degwekar_s_Page_076.QC.jpg
00d3263d83f819c630a4b8052fc3d3fb
141f0e37fb8771d35445e7455c9a16d4330a4bfb
1189 F20101206_AACGQU degwekar_s_Page_133thm.jpg
72c1fc20678f9e1453f773f8d834c207
735b8e4256fba9c767f8cc067b0b85bfd9545588
62012 F20101206_AACGRI degwekar_s_Page_115.jpg
d5cd1f2a3ecab030a4a86f6d3c896b04
dc9171278416ef917c69d601e6ce136327bd902c
26490 F20101206_AACHUL degwekar_s_Page_088.QC.jpg
af65f55639862b27096ac654a1ab93a9
806d94f705fa723093fef280d17770c893e58da6
2935 F20101206_AACHTX degwekar_s_Page_077thm.jpg
ae9cb833d6b60b579f1d3514523afd1e
9891de6cb77f4c819a64cefbc752d767362dd514
120683 F20101206_AACGQV degwekar_s_Page_066.jp2
5438996731798b31212e6157c77c37c2
e29d0b2e0cc851d6037695434c15ae8999e7b8c1
F20101206_AACGRJ degwekar_s_Page_147.tif
5ec81ab75de0381b75c5a45aaf8de3e5
05ee6f7abff7fc9702f36eb393f9771fd387a05d
3778 F20101206_AACHVA degwekar_s_Page_100thm.jpg
0afe6d5033d617324cc10bfeb4ac98df
d47a10441ad982a1953876b8f7ae2338ff6d9dba
30505 F20101206_AACHUM degwekar_s_Page_089.QC.jpg
cc1999255e2d23749c700aba776ccdd8
d15054eb427243120a2dd6fbe7d9da0542dc65e5
9909 F20101206_AACHTY degwekar_s_Page_077.QC.jpg
44fcb8fe2f95cf6cd49a5e32553979f8
5a0e338e9b67d74c9bc29c9a96fcb85fe6486475
57551 F20101206_AACGQW degwekar_s_Page_016.pro
f2046b1bb957e8a2b0682acf694382a9
ab795af7408c4d00fb3703ec43049005850da689
62375 F20101206_AACGRK degwekar_s_Page_151.pro
566fbca82831993f0b6467ff6bcb7244
132ff473b459931e118883a1bcdd64f5fa5206e5
3138 F20101206_AACHVB degwekar_s_Page_101thm.jpg
966c97119d12d8bbd86f239ef247995b
7c0db74a77f612377c4506eebaf187382ee9b471
17225 F20101206_AACHUN degwekar_s_Page_090.QC.jpg
f3d018dae7a23b80baf13a77c4e3c0c1
4f1483dd75111eef4149050b950d6bd6f5e035b5
28416 F20101206_AACGRL degwekar_s_Page_083.QC.jpg
7fb50286cba8bc9b37e21b6b0030badf
93006ef5866ba3cbdbe23dc4048d8f1f4e1cab49
3057 F20101206_AACHVC degwekar_s_Page_102thm.jpg
b47c92ab1370952b1e9a2c2c57a7a987
0652dc1314a5c4b39d98d5d480bc9c427508139f
4171 F20101206_AACHUO degwekar_s_Page_091thm.jpg
5448a21a1b5eb2cb4c4ec34176821b5a
38b990d48e1d84f042d9222635c05d71ecbb1173
6385 F20101206_AACHTZ degwekar_s_Page_078thm.jpg
78ffe41f36e46453026a60ed95b61ae4
a30254b46d83587161a4cfef49598484d17a5369
12931 F20101206_AACGQX degwekar_s_Page_044.QC.jpg
8d49ee60e7dc245c4fb8aad3e15a4fca
593c41a4cc4c9ee01d579b52e693095373d97ac4
5422 F20101206_AACGSA degwekar_s_Page_079thm.jpg
20ef615a7712ffeaf48c45c929a81c31
a47d2ddfe035ee364f5109f101d5cb6589ad3632
F20101206_AACGRM degwekar_s_Page_025.tif
c21b34a6c05a485b91fabd1a3c89bbd8
85591ac869dd96bd6193f3fe25cadaae231f02e1
12628 F20101206_AACHVD degwekar_s_Page_102.QC.jpg
25ed2696f11121b96384c70bd0884288
4462e178ab94c5038f9d9115512a7d5cd609718d
15341 F20101206_AACHUP degwekar_s_Page_091.QC.jpg
25fcd46769a85445a2a3e3163fb535de
37e9d92703568114d42ecf3e15b841584d88e1a5
25488 F20101206_AACGQY degwekar_s_Page_086.QC.jpg
da9415a4838d61bdbbe836b1b98ff3ea
9f4e7f09b4954771650ad8b1ce225dca6199d3e1
41243 F20101206_AACGSB degwekar_s_Page_054.pro
3e4da5ab08fbe2c8bf791b6d2ad2f63b
e0520c9d0b1d3bc2caeabf7c7ab6e34f45a9716f
56001 F20101206_AACGRN degwekar_s_Page_083.pro
d5dfb537e78bcbfe1140fc8dd15123c4
4e3407beba9cd3dbf793d352626b99378c81f77e
3150 F20101206_AACHVE degwekar_s_Page_103thm.jpg
80cc3a29b5d08b4580277ae063d36639
82bbc7b341fc04a7b6a1cd61a51cb92ea2d3d9ef
12724 F20101206_AACHUQ degwekar_s_Page_092.QC.jpg
f08e3dc414842761d5ac1a6eb11b1040
777f6e029be0674677861da813042c83659228ac
23261 F20101206_AACGQZ degwekar_s_Page_001.jpg
af53462a84f740b974436d12306be7b2
64fdec2e2020420926c687cf1bd304d29baca561
9741 F20101206_AACGSC degwekar_s_Page_038.QC.jpg
7fe42599d5ff7a841816980e7f59306e
74cef050251df6f4fd6c93241d575ac7f384a22d
15751 F20101206_AACGRO degwekar_s_Page_110.QC.jpg
cb364ff433d4327b210691124c2ada9d
9e90ca58ceea4c9ef24ccf793b76aeb1bea42df0
12906 F20101206_AACHVF degwekar_s_Page_103.QC.jpg
7ee746550b1c898f0e92d576c9e6e892
f70fa39db1bfebfab79dfc6b88de8bb1da79d8fd
6902 F20101206_AACHUR degwekar_s_Page_094thm.jpg
47879fe5fca32878d5d64b1086c13e09
823c4106119926cf3d05019027eaa15c78fd06b5
90268 F20101206_AACGSD degwekar_s_Page_084.jpg
4ee7c0282a3195e81f81eb59e361b959
cdb957b26fe6d321d5a32a3562e79ee24b87e9bd
83466 F20101206_AACGRP degwekar_s_Page_020.jpg
96289e94e7212db757b78dc076f90309
4c141e45a4f602f95af3f0a1fd5aedd7e464d7f2
2937 F20101206_AACHVG degwekar_s_Page_104thm.jpg
902b658f41b91dfc925461df59b28c82
17542fc9e48697933073e1b4f898f2214510dffe
30513 F20101206_AACHUS degwekar_s_Page_094.QC.jpg
65a48b2cf36133a4b5a91cf8863a54a9
feec77b3bd2401509e2c6d07eb2572b1702c74eb
20125 F20101206_AACGSE degwekar_s_Page_075.QC.jpg
29e578180489045be22ef3f6ea116420
c8fd7562baa8a898c48bdcd26b6dfd2a8b9ff49a
F20101206_AACGRQ degwekar_s_Page_156.tif
e275196a2ea32517c912b5c197605c92
da929a2de6ddf443a8da41579c5c35f4eb47b5c7
12149 F20101206_AACHVH degwekar_s_Page_104.QC.jpg
d47939c2900da7088abdf6b79d035a1b
2bf71bacb3c65db5e743500f53eedf268f5a4726
6591 F20101206_AACHUT degwekar_s_Page_095thm.jpg
0ece792eed683813d8477cf682e6f392
3a462a920ec7ef9254f089de925203469659d396
5896 F20101206_AACGSF degwekar_s_Page_029thm.jpg
ff00ffaf94d81fc8a2343ce971f20c1d
f3f671368821ecb85edf5c92c4c17f30e23747d3
4443 F20101206_AACGRR degwekar_s_Page_058thm.jpg
71a2ba371b7dfe850a606dc60ce38d20
3378194526e66b8e1f7dd01d6b354e79090fbb59
3053 F20101206_AACHVI degwekar_s_Page_105thm.jpg
f0092e87edc1727243c0316f1b1bbc0a
ed9996e2832bf511606b31ddf31e19adccb57117
29676 F20101206_AACHUU degwekar_s_Page_095.QC.jpg
5ba3ac3c5486d7a9d6fa03f2d4b0e8f9
f9f1d40a0f0d49e532916606b6e887150be2ce5d
1400 F20101206_AACGSG degwekar_s_Page_132.txt
f17975499796ae4ed529a5289f8514b9
9c9509e7e8a77687dd2a95675c09fc36013428e4
23311 F20101206_AACGRS degwekar_s_Page_046.QC.jpg
b61c6fead1809cf88e7775b40a626cdf
3b5d84b65db15bb3d76df2b5e25b656c6cd7b5bf
3563 F20101206_AACHVJ degwekar_s_Page_106thm.jpg
59cc6e30beed778b97d460697c657c1e
e60be276052c460f925b60cd26ff1a848e9b0926
4770 F20101206_AACHUV degwekar_s_Page_096thm.jpg
a63f5a755c17c5cf0d4af1758cb2800d
c74b559d6ea082fa80140f61df6cf28cff5e6c1d
15027 F20101206_AACGSH degwekar_s_Page_108.QC.jpg
80f1de56665df7262c6c07c7a46c279a
26d2aa0d75341d095677d26ec863984fe537cb8d
117825 F20101206_AACGRT degwekar_s_Page_073.jp2
d6ca06ff9b34fdb549c0d198df3b1e86
6f8dd71f3f93f33beabbe3a443e058332742cf7c
15290 F20101206_AACHVK degwekar_s_Page_106.QC.jpg
c895e907d70faf9e4fd0a8d900765003
6b5994008faf57f9b65931bf51448b05ceb35d5d
3684 F20101206_AACHUW degwekar_s_Page_097thm.jpg
8e6cd743fcd54d707d69f8a2af97562b
4e17ff899f8f8a4b28957532122cc7e6e4e4b262
53284 F20101206_AACGSI degwekar_s_Page_064.pro
7e9750cda132c4681e8ca6b195c306e9
100fbe7aaad518578336d4e2ed3ba3efe017713d
F20101206_AACGRU degwekar_s_Page_015.tif
320fe7cdffa6db71476eaf0990820f26
d78ea1372a52f29ce9c0779e457641e899ac351c
3028 F20101206_AACHVL degwekar_s_Page_107thm.jpg
22d231258904dbf4d21ec17b88e46792
c3b423582d9644c31dc44fba9ea2040e53d269ce
16063 F20101206_AACHUX degwekar_s_Page_097.QC.jpg
e229ce47998945d81e8e8358795e1905
778764c93f6f72db557e6908953b4ac6c868d3e6
45761 F20101206_AACGSJ degwekar_s_Page_060.pro
1ccef8bfb289053494e8c00d7c9dba11
e19617d22707d20f62716ef31dc4b8f5229516eb
F20101206_AACGRV degwekar_s_Page_096.tif
74dd5192272b041d6c047f75d51edb17
80226f8ad338aaf1f8830f2e0967c79005ed2888
21735 F20101206_AACHWA degwekar_s_Page_118.QC.jpg
3d7a10c037b73f66d1e6a2fde3e7b9bd
435798eabd23a3827fd82c3c373421bff34b6ae4
13055 F20101206_AACHVM degwekar_s_Page_107.QC.jpg
e63764e8ca00f36bcea2801af1449ef7
fbbcd5b164d3c0411a39176f044a895bd083cf9b
3180 F20101206_AACHUY degwekar_s_Page_098thm.jpg
cd03cd0e58d1f6b855cf816bed5d5874
70145bd0a19a84237c2fb53b7f2e95806a94e39d
54894 F20101206_AACGSK degwekar_s_Page_108.jpg
d55b93a370b7e48e8d32038e0a8eaf05
8380d4754df01f672712c33d49a74efbb62da43c
F20101206_AACGRW degwekar_s_Page_138.tif
8b010be1af49b36ea68708a6270ac5ff
286cbe6b4d227513b0a026ebd7387d7d16b65cbb
23656 F20101206_AACHWB degwekar_s_Page_119.QC.jpg
e44ddc5fae63073b3ec543847fe7c2d9
79ce87f5afc3baa9d5e6354936c821d88f1db998
3549 F20101206_AACHVN degwekar_s_Page_110thm.jpg
9f34088dea1e03ab2896862688d20ffc
3d2ef0011c122e7fd4772f09ed0e0433bb4503b1
13703 F20101206_AACHUZ degwekar_s_Page_098.QC.jpg
4f32dfec647f6df8ccfbaf6b5857b5e8
57564a65c94cc16cea10578e932654fa50376092
79932 F20101206_AACGSL degwekar_s_Page_082.jpg
319cd47799c6b8f9abf01d995e94efcb
ea85cf5d5318459aef99e423d6c97b143f134a05
27125 F20101206_AACGRX degwekar_s_Page_104.pro
623b2cbd8ac306af2619440b90a63118
e5fcf83048f8da8238291f0254fdee3af03c3280
24858 F20101206_AACHWC degwekar_s_Page_120.QC.jpg
726e1b5c4555905ab493de7a0543d117
a99af5c28a991a299568cf17678d52df75110792
3442 F20101206_AACHVO degwekar_s_Page_111thm.jpg
0cdf77742d6699623e5da635a2bcbb0c
a015fbee4e132714aba7ca23b466900b9420e6d8
6734 F20101206_AACGTA degwekar_s_Page_089thm.jpg
cdf7c193858e502d40864f95667c98b0
078f9ce615ba6f529c8c53cf158256415e972f74
4229 F20101206_AACGSM degwekar_s_Page_109thm.jpg
d1725858962cd40fcd8cfe88e25d5eae
5a769bc1916d819811e9643b4a4be669d3b3a5e8
6006 F20101206_AACHWD degwekar_s_Page_122thm.jpg
d666135635ead5077b70dd5ec3ed41be
8f702459c74d330742f3d5b2d4291b3f51db6ea5
14847 F20101206_AACHVP degwekar_s_Page_111.QC.jpg
0720826e3fdeeed7d3041d5a6a001f7c
b47a51e33403e8ad5e7edf24cbfbdabde937cc8d
24094 F20101206_AACGTB degwekar_s_Page_116.QC.jpg
130c5101b9918f98b130ad5c26294a34
50835a7191bc2d63e3079b69d967c8d9caf8c33b
103979 F20101206_AACGSN degwekar_s_Page_072.jpg
9261b39b518474b1944ba83b6a486f15
99fc495bf49c3a55942b188f9df55d87755127a7
2441 F20101206_AACGRY degwekar_s_Page_139.txt
94c53df0dbd0dd3bc72be28889dc55df
8cfc262c8ada56c413dfebb7ea18f6b18a5427c7
23830 F20101206_AACHWE degwekar_s_Page_122.QC.jpg
04f5fc4eaf461ef4c39b4a30bcdce0ba
d5156f070f84990064483c0500c7d99ed81eb4ca
825 F20101206_AACHVQ degwekar_s_Page_112thm.jpg
6ebf2d0018536a9b9846732c1a3f4955
5d684186797d0cad938b43aaf981760ac51b60cc
1139 F20101206_AACGTC degwekar_s_Page_102.txt
b6dd5bcc8fcdc1da55e399030d1fb6c7
085af985566fbe9cb681f10dfdd0985896785639
53461 F20101206_AACGSO degwekar_s_Page_012.jp2
724bc67efe8f1eaac174d4e73c5f2a0c
24ce1e8c52afa1c2481055699bd9f9e843c8d009
22215 F20101206_AACGRZ degwekar_s_Page_126.QC.jpg
963ea7251a4699deef6edb2a89214e2c
3974a82524c6d668898923c73909d06b282db1f5
5913 F20101206_AACHWF degwekar_s_Page_123thm.jpg
69180097560bb00610f096eab0bb76d6
03a20e20f16acb8bb1ae8dfc283352ba13e683a0
2592 F20101206_AACHVR degwekar_s_Page_112.QC.jpg
4f9267c822b8f1aa750963007c27afec
07d52c5efd5f6ccfe2ac259b73053a7c768fe401
17718 F20101206_AACGTD degwekar_s_Page_115.QC.jpg
4083b87e54f22db3bca62e1d35d155a2
ef95c597f339a5f3a4321e85105e1e6cb83094a2
2161 F20101206_AACGSP degwekar_s_Page_025.txt
7937fea8cb85866c583abd47932752b9
969db470eafcd17e8c65d604d1398f007a90e2b4
24718 F20101206_AACHWG degwekar_s_Page_123.QC.jpg
730ef7cdf566f59bafbe17137bbb7f05
033869541f0c5335c426f9b2cbe9519b5cdc5068
5392 F20101206_AACHVS degwekar_s_Page_113thm.jpg
38c518f31dd31cec1d71ad6cb25425d0
bc1cda85428a0561f3c2fdb787ad0bb581ead0b5
95611 F20101206_AACGTE degwekar_s_Page_006.jpg
effb793e6fde6dc59247c4312c5ea164
9fa08688432cd295042df39df54a958c81ccdbb3
24726 F20101206_AACGSQ degwekar_s_Page_142.QC.jpg
267bf8f2cd4146c522be211d00a51ca4
970d550a50e42c8fdc786ba4609e997dfd9cd0e1
22134 F20101206_AACHWH degwekar_s_Page_125.QC.jpg
e6f472a4f42e49a3578ee13577e0df9a
22b1612a9ef9c2e3b2039c2d471741338d2eb256
22683 F20101206_AACHVT degwekar_s_Page_113.QC.jpg
1fbf592b830ce52a7a91d7a4c7387a34
ef727b4a4500fc4b082287bdb6d7c66e4d0df815
54031 F20101206_AACGTF degwekar_s_Page_057.jpg
6ad6d425f616260a3668ae7098795e63
ba221765ec73e48ccb8d797d439267d81ca56a89
112655 F20101206_AACGSR degwekar_s_Page_074.jp2
5d89e28e306f2e6074830426e80eaecf
ccbe5843dae918e6d9b0aa5c3f0023575220b301
5774 F20101206_AACHWI degwekar_s_Page_126thm.jpg
bee84e2c306e8e5a8e104eec5e814054
b4771995193a862b067b4b1618c2649f8279e1f5
6203 F20101206_AACHVU degwekar_s_Page_114thm.jpg
b6163ef53c41c9d51c37746ee3351c79
d31ea79491e3dd54a8c98d39c590c66bd8275587
32956 F20101206_AACGTG degwekar_s_Page_108.pro
c41e1262dcfcd57c9d7fb9368e9aa6cc
adc58789ade6abf403aca6e36b1337ca212cdbd9
21987 F20101206_AACGSS degwekar_s_Page_055.jpg
8c4665a9ee075132774d275fd51bc0fd
8062004d3b007a94780f48b7bbcd96fb511bdea0
5497 F20101206_AACHWJ degwekar_s_Page_127thm.jpg
ff203861e8d812b5db2ffb24ed6c6f1e
0f273f833420c4b212a5d1e60e080b222823d870
25276 F20101206_AACHVV degwekar_s_Page_114.QC.jpg
8ad678fe8bdac56a043761985fd8407d
4806c2fe798207784180116f527dbf6e25769d47
5393 F20101206_AACGTH degwekar_s_Page_007thm.jpg
eb517bd18cca86f5ea5d2bb688999ebd
bef371bf804896a3ce594af1dcf07d34b902181d
95396 F20101206_AACGST degwekar_s_Page_145.jpg
3b7748ec73ce8228a078373d66680d01
cb7173ab73be24dfb10e050c064ac9ca11a43e6c
20894 F20101206_AACHWK degwekar_s_Page_127.QC.jpg
019667b6e2033e3473eb8675b30b1d26
3641a9fd9aa89527e4106fdfbaa95bb67ae6e960
5809 F20101206_AACHVW degwekar_s_Page_116thm.jpg
225c91c61fd76a265649e79d70ab6a9d
6f03bf3db95b0d3d76c34d774001103a568c9678
70133 F20101206_AACGTI degwekar_s_Page_095.pro
cbda8dd5246338e15e8f858c9743931a
e3b00bc6f89d1a68cc231d2dde52d3ecb44eb9b1
F20101206_AACGSU degwekar_s_Page_148.tif
e0b5cc219f4a96d64216cfe2f3408bc9
63b8b54efe25dbad0db7e5288b1b5185cd8ddf3c
4631 F20101206_AACHWL degwekar_s_Page_128thm.jpg
afe3e6edb819114cc2e031cc16759547
d09caa6b087d514ee2bd3e77152d707eadd8ec2c
5611 F20101206_AACHVX degwekar_s_Page_117thm.jpg
233a8ab2aea24ef7c8e7faa7e0e7160e
9f80dcb3fd255d962df79f215f131f26d4439daf
236667 F20101206_AACGTJ UFE0021359_00001.xml FULL
b1b25df70b622e51b748bccaa5a58a74
c844b5e59e5b707e07fa1373759cd7cb2fd350a2
67050 F20101206_AACGSV degwekar_s_Page_058.jpg
1bfc494c69b1c6db4ba5afa383e82d92
c51c40e6d12bf0269077077b051b1448a365b930
5792 F20101206_AACHXA degwekar_s_Page_139thm.jpg
9a85d39cfdb6e99c24d7fe70ad2b28a4
b731e546a98f65e00d1a9169ac44cad852b4a202
3023 F20101206_AACHWM degwekar_s_Page_129thm.jpg
148418ed731bf38aa616a11735d92809
c41d635d6631c64d7bf17e3f59753020bd9e1b9b
23302 F20101206_AACHVY degwekar_s_Page_117.QC.jpg
19e44fe1cd3cbfe4529160e85304cba9
f8a9015d3d5469f68dafb991a50a54f5106a2dcd
22921 F20101206_AACGSW degwekar_s_Page_121.QC.jpg
cb063a0965e4826fdc809fb71cd86a1d
d19166572dab70068fe425434038819883059ffc
7140 F20101206_AACHXB degwekar_s_Page_140thm.jpg
7b2867320e82d65b1366a5d8af717040
6e5802ae7d9d60d23b11df518790f0df2a09ae9e
9472 F20101206_AACHWN degwekar_s_Page_129.QC.jpg
afc94f02033094a028c30513eb20076e
1c19f60bc1584dd26ac751f308ccf19a82c45e69
5752 F20101206_AACHVZ degwekar_s_Page_118thm.jpg
0aefdee8449d53fafa48ad0d890cf8a6
a6565859d4664f13b7987ab43a8d8336a82ac5a7
1823 F20101206_AACGSX degwekar_s_Page_110.txt
2b4ee282d5eaa9152d53362649cc11df
070ccaeb2a4a408d7547914b41fed49957b10c75
5745 F20101206_AACHXC degwekar_s_Page_142thm.jpg
62e4c5634ac4cf0b9675129a6b5d4879
e746db016fd896ee6d90a45a4e61f73842e5d53e
2590 F20101206_AACHWO degwekar_s_Page_130thm.jpg
70f4bd80dab985cc51a6e006433f73bd
53278a1f8fcd2d855f3bdb1448e5b41a7edef86f
3740 F20101206_AACGTM degwekar_s_Page_002.jpg
9177c330e49fa789a84b60e06dea7cec
acefa74c53255016f6858183ea4d75ef49a667b3
96086 F20101206_AACGSY degwekar_s_Page_046.jp2
fe4cf9a784cb353f7eb8936131c65763
3f12823080393c493c30d3b4e6579b6ceaed3318
83525 F20101206_AACGUA degwekar_s_Page_021.jpg
09f4b2760bc5ae9d15163c476d8393c6
3d1f3739e4300c73de730f87f3e28906485a5539
6872 F20101206_AACHXD degwekar_s_Page_143thm.jpg
1e55ef335d4c6257e132c6fb53172695
b6ab68745df96ea5e04806f7bbdc889993d5205f
8882 F20101206_AACHWP degwekar_s_Page_130.QC.jpg
ad8e80f72c31f74d82b3643c0ee1ff9c
629d7389d5aeb52a9ea73de03fe0e136fd7bb51f
4385 F20101206_AACGTN degwekar_s_Page_003.jpg
330535dc42e32e145bd4eb0ebf60b7ab
edb5c746b8f0616617b29ee7b77354c11d0d6175
92820 F20101206_AACGUB degwekar_s_Page_022.jpg
836934184ee2fbae13d7bea2544a1820
fd6b3d3e353625596150c21c921da07c44e4ae09
29751 F20101206_AACHXE degwekar_s_Page_143.QC.jpg
996631721b02183e3dd37d2680009b59
0fa28db25a6b77501fe217494fc7f196ad758dc4
3483 F20101206_AACHWQ degwekar_s_Page_131thm.jpg
e3fb302c5b299b3f79026f48519b8f7c
17710874af037a962de2e84ba403f7f857f7e8f9
85996 F20101206_AACGTO degwekar_s_Page_004.jpg
05113282eec6bd1f520b485239feb3d8
5cf7ee5e68207c119021e16aeeeb7f8e5f98a4eb
27338 F20101206_AACGSZ degwekar_s_Page_081.QC.jpg
085c9b81a5c310d8bcae6faf3101ca62
c569c5dcd3f2385c436d41da437aa972c46a6442
85020 F20101206_AACGUC degwekar_s_Page_023.jpg
c7da4c398f9b176c803d47835d0877d6
311608a313853fef6c5336c2f27121f615ba9deb
5413 F20101206_AACHXF degwekar_s_Page_144thm.jpg
ba9d14904ab7e690cc55585fd1c74758
f1af0289cbcb0b405516aa87cbaade3a185fa6c7
12173 F20101206_AACHWR degwekar_s_Page_131.QC.jpg
11c6e47eed48d2e3ce6306100bb9e1ea
4cff783a9e3df62eb669f8c00d8e1d2189cf7977
19604 F20101206_AACGTP degwekar_s_Page_005.jpg
6d83a024a2283bcc4f51c0bd404dc82d
5bf0b92bc8bf2b95cf6d655d9f0c2349023c199f
90475 F20101206_AACGUD degwekar_s_Page_025.jpg
1b49317662d2127b4435b0413e91cc0c
2e9bef895b36dd91b67238d40f7f3dcb4e07bf2e
23887 F20101206_AACHXG degwekar_s_Page_144.QC.jpg
8b9d85088ffc2c088a8406d1c475ccce
0907a5e0a826309f57d972cf28ea5c55095e0cd2
4568 F20101206_AACHWS degwekar_s_Page_132thm.jpg
9c318cb83b773e5c61af85019e065f6c
0ea98edc16489dab1d7cb4f05d1b69b37a7aa0e1
97256 F20101206_AACGTQ degwekar_s_Page_007.jpg
06e859930fe3ed952dd8a7b65b900687
d7c863b2438e46b9583cbf8162b8b29d11fd5169
59718 F20101206_AACGUE degwekar_s_Page_026.jpg
2039dc45157ccf8bc8802c8c6b484791
5e205818421b9a3e08f96b92379787b64640d685
5832 F20101206_AACHXH degwekar_s_Page_145thm.jpg
d70ac6a86643dbe35140ebdac52e9d66
22a10cd828f980485666219ea86346fa912bd26a
27739 F20101206_AACHWT degwekar_s_Page_135.QC.jpg
de4f271b9d47c62fab64809704c2eac6
ed9b938c6b1514fe6ee4a9744902d06bc5dd45ff
6941 F20101206_AACGTR degwekar_s_Page_008.jpg
eebd9e4dd2a071833ede10d6bc86922c
c1a94a1fa241ec93c753f10c77a9d1a6a2ea52fe
111421 F20101206_AACHAA degwekar_s_Page_078.jp2
65a73eca38525184105660ce3d981f94
4288f28d3b81016c40ba6a1dfb1cb64b628ac41e
87588 F20101206_AACGUF degwekar_s_Page_027.jpg
d7023aa1d66e67ace53cd00f682d43c9
d78346937186436a8fc57419649b0220f2c0f5e0
25489 F20101206_AACHXI degwekar_s_Page_145.QC.jpg
9f41529488d64d9fde9e1b6b8f17f91a
d1fafa065dae95c1c34a22d96a09d72fa02b5509
6219 F20101206_AACHWU degwekar_s_Page_136thm.jpg
107a409da9c647a824f3d8d11689cb5a
5cb2cfd2909fffb8ac5649a20117ad783cfe36aa
19887 F20101206_AACGTS degwekar_s_Page_009.jpg
df73c8e4b9832cb79160ba17fe560af5
2ccb03cf1d810d8a5889f4a1e08eed7aca5c3a69
87268 F20101206_AACHAB degwekar_s_Page_079.jp2
1722f7eb530ea9018f028fefab51eecd
5bb5e108ca2ac10fdf7cac2e259c51c4ee100930
81318 F20101206_AACGUG degwekar_s_Page_028.jpg
429299f4c0bc96ba5385ac45e7a8e457
1892031db908265c5f327cbcecc1f883af7a78e8
6511 F20101206_AACHXJ degwekar_s_Page_146thm.jpg
e17c3ef34becc6503481c3bc04b6a29b
d9f0636094cd7fb2d67b835ff72b7ba675877f3a
28428 F20101206_AACHWV degwekar_s_Page_136.QC.jpg
4ce6218b74a9d0ea6f394cb9343286ca
415c6513eee04a7480f6850bbbc347aa556a0827
52251 F20101206_AACGTT degwekar_s_Page_010.jpg
5abb8ed9cdbd1a88b34ceae2b558a35e
38756ac7833fb0ad51df733d94a9e0adaa102bcf
119380 F20101206_AACHAC degwekar_s_Page_080.jp2
3f5d82c277a9a910920991c12637bb02
97582f61704e85b2e4fb151ddfe53dc7d652fb68
86055 F20101206_AACGUH degwekar_s_Page_030.jpg
1662ed5ca82c5f8c0b0ceb7ecfa7acba
c2ecb522297abb55f44bb8594d132059dda97dbb
27558 F20101206_AACHXK degwekar_s_Page_146.QC.jpg
3eaaf942c5786ab4206f783cb38483b1
39b8b8df42fb7eb4efac04aa2f67d1b3938a2c53
6912 F20101206_AACHWW degwekar_s_Page_137thm.jpg
dcffe763c1de9ef57bb0780c37b42d41
879a594fac2e1ecd48506aa0e26fbf8c8ffba0e8
77438 F20101206_AACGTU degwekar_s_Page_011.jpg
dcff8a8c7f83346f4a461606bc91fd45
4656ba8c6f730cb6b2289d841d506e6d7e1f4105
112031 F20101206_AACHAD degwekar_s_Page_081.jp2
41c71db89d0edd964db16a72d7d6025d
ca086b5d2bf9333d263ff0ba97df1d7931043a72
66031 F20101206_AACGUI degwekar_s_Page_031.jpg
a5e5b3eab505504e397b21a269de37e6
c97605f0e92e454ecb39b6eef28e5d7a22920eac
6582 F20101206_AACHXL degwekar_s_Page_147thm.jpg
e66067e55147a9db192451b012ad2b09
58e08063dda322ba9ad8f92a8a27aadd17ea8058
30497 F20101206_AACHWX degwekar_s_Page_137.QC.jpg
d2a91e16635cc99807bf37b9380a85de
f09ff4fc563288fd70dea514892a16d8f9505ef1
40963 F20101206_AACGTV degwekar_s_Page_012.jpg
e9a5d80cd6d8c69d5dda388deb272d2f
2bbe1e177bff764a95fc6d6de62777a2d0531ccc
102859 F20101206_AACHAE degwekar_s_Page_082.jp2
f863724bae006514871c5729184b2858
4c2747e39fe55a203fddeb0467758cbbfd24ffd8
71536 F20101206_AACGUJ degwekar_s_Page_032.jpg
3159a9bfae641b4991fe13a58bf446d6
58ec02ee50f290d144d11b084344b2f5509273b1
4319 F20101206_AACHYA degwekar_s_Page_157thm.jpg
5b9929836aef4962c9ddd92255e0f802
633d6a479e1cd96adbe34c93c15dc85ea678ed27
27885 F20101206_AACHXM degwekar_s_Page_147.QC.jpg
d9f947ea358f6d3b771eaf9a6715107a
a18d02c87db8e985bffb76915b513f6a9eac95e6
6183 F20101206_AACHWY degwekar_s_Page_138thm.jpg
af8a5e8e35ac07aa702e41da9fed85a3
285818fa1c0a8c875a79bf0bda725d283eadddd6
85236 F20101206_AACGTW degwekar_s_Page_013.jpg
c8c41be6f94fd21e6754c898c6aa4452
52c1767e0d83434fec12efc15fae0a058f66a40f
117672 F20101206_AACHAF degwekar_s_Page_083.jp2
a8792e626eb35807095ee5bad323897d
18084d5bd1b010e51a769aa18b7c8289f0d05d22
79903 F20101206_AACGUK degwekar_s_Page_034.jpg
ed806cd3120d68d5cddeb1434ff89ad7
cd8492995f042b9b4e7b91f18df1fe6c2a9ed138
182617 F20101206_AACHYB UFE0021359_00001.mets
7d25b4981a479e265e2ff8c9f235863f
07bc53e42a045601e2f535cdab5d47a28b353a5b
5575 F20101206_AACHXN degwekar_s_Page_148thm.jpg
1b6237ade44407c037524daa571e00ed
d8cd4e6df874c2c5d7aa230cf2825d5c08cd2b7c
27047 F20101206_AACHWZ degwekar_s_Page_138.QC.jpg
9f258825fd885c4577abd5b12081fd4c
77efea9272f5577f358a6ded0f8cdbdf6efff8fa
90622 F20101206_AACGTX degwekar_s_Page_015.jpg
26330aa4bed7259df087f3072eb1edec
340fa02777ac11bb1f8d49cfbb60852efced1aa3
86206 F20101206_AACGUL degwekar_s_Page_035.jpg
0a9271661959f560911c73d7b8894a1e
0cd4df8d8e3795efaeda2231d866e0758160a5f7
6043 F20101206_AACHXO degwekar_s_Page_149thm.jpg
bb179fb2640b2d0d2ddfeb0dbc0f01e1
30b3413ae3169ce366d242f7932c0c3934ac9765
89734 F20101206_AACGTY degwekar_s_Page_017.jpg
833dde79e316b13fb57156045623b48e
1dcfbea3cd736dcc607239dc2ab73378673aad91
117358 F20101206_AACHAG degwekar_s_Page_084.jp2
ee643c1ff6329b7c57ab2398607176ea
36b207bf5dd082658f5888dc7d8dd3795de5678d
85137 F20101206_AACGVA degwekar_s_Page_053.jpg
1cf21f3cfcbd71ac3ffa4d3fa686231c
03d43676d263b5c310498b2f9fc200bb3515c42e
48135 F20101206_AACGUM degwekar_s_Page_037.jpg
4b812a3b9fb790bd8d93c13a8fbbf858
d8d227c946733c14b57572b70de7cc3c0838eef0
3195 F20101206_AACHXP degwekar_s_Page_150thm.jpg
24146dbdf01b4707132c122997ffbea9
15ba5c7ca4849d4be913fdaf7bb54fed16ae59d3
72053 F20101206_AACGTZ degwekar_s_Page_019.jpg
2bc22d036d1d8bae5bb5bff0299b7c54
a5f17fbffef79a8db27625ce1342d3256dbb092e
97206 F20101206_AACHAH degwekar_s_Page_085.jp2
6d7cd0ee4161b847208e8031d0eab882
5aa0be99554e3f148eb1786b9900ffa8ab0b95ec
67320 F20101206_AACGVB degwekar_s_Page_054.jpg
4b9ad635636d3b6199073e1829744ab6
bf8ce75c07cf5be372194603e1628bd53acd68b1
33872 F20101206_AACGUN degwekar_s_Page_038.jpg
f2036be7444906d9c8873e3eb201b459
2975d30e9e6291b4371da33c99e670120e02f406
12666 F20101206_AACHXQ degwekar_s_Page_150.QC.jpg
666af1f515f8896fc0d4ce425b2b2bac
cc57883551e58b0464d7e5d6036b032926bc65c7
106192 F20101206_AACHAI degwekar_s_Page_086.jp2
42c6f91ecf6668a781c15638778a9b5e
0821eefe53831d3c09a6eb586358a1c4d42203f7
77607 F20101206_AACGVC degwekar_s_Page_056.jpg
6b5ceb1fcd019cbe6e9c73f03a52ff9b
bfdbead4c701143993de4d625c3df256ad3f4c3c
44566 F20101206_AACGUO degwekar_s_Page_039.jpg
0d8951b4b9e22af7093b778cd2ba2b18
ff8966a62a85d2b06b98b37e1de05d2d9a64c4e2
6916 F20101206_AACHXR degwekar_s_Page_151thm.jpg
62ce7ecc117a27967d5838ba45405a3d
618ed3739a2f0ee7739ea1ce9ffabad7e3773da9
109770 F20101206_AACHAJ degwekar_s_Page_088.jp2
634b1098e3ac4bc37b99939e9e72434e
55f013c8079e21c4eb82831dc2be85f1303220f8
72858 F20101206_AACGVD degwekar_s_Page_059.jpg
cb72819fee7284e4742cf034448082aa
0a30b3484867010507520c8514cc3fbc2aadaeb8
55594 F20101206_AACGUP degwekar_s_Page_040.jpg
fbb5e2f513920e49922ede1379310c29
07860c4b9b7530cc9f47bca92533523cae727fac
29304 F20101206_AACHXS degwekar_s_Page_151.QC.jpg
8941a48167d0d819e1c2a0690e256e6c
931b06846bb312c5d64682653512fba718f62ae5
142156 F20101206_AACHAK degwekar_s_Page_089.jp2
8d0d12cb88b9f0712298c6e4c1a3c920
42ab5263acecb6cb2da684998b90e59a1f3ddc52
74928 F20101206_AACGVE degwekar_s_Page_060.jpg
3c0756f72da5cf10a3ba6baf6ed06b96
79ce892aad1067a9ad35cb56d562e730d87e358e
69037 F20101206_AACGUQ degwekar_s_Page_041.jpg
38fda4c6f92ca4e2c2e9f82a237a7178
7c8bbf98845263da4bc52c39e85a7a8c95bba58a
6973 F20101206_AACHXT degwekar_s_Page_152thm.jpg
1b9d39cb0f87830fbe12e1e6a3a204f8
42fb4fed3d173a9034cb57e97fd360d79543ba28
77050 F20101206_AACHAL degwekar_s_Page_090.jp2
90af172b5d83106c8a270c81107f439d
a0eaa71fdd851473c7775ad24e39756559df5424
88420 F20101206_AACGVF degwekar_s_Page_061.jpg
67ebdac2fc3df0ef46fa96986f46c829
e8916243a6f9f0bbf7ba15e9b89c21fe33824140
91064 F20101206_AACGUR degwekar_s_Page_042.jpg
c12e1ae34fc89a2f2b34a5480dfe1979
c2130d0fd4725db193bb18e461b525670f5b97bb
74343 F20101206_AACHBA degwekar_s_Page_111.jp2
06d86ecae403a5ebc8019cdd66bcf50e
52fa7daeb343ad4a3018a2caaf0ad02480b4d496
29275 F20101206_AACHXU degwekar_s_Page_152.QC.jpg
d88bd70854670e14a672be049f05f398
8932912e2a484fb7e800a4a12ecc7e0ab4689f64
49690 F20101206_AACHAM degwekar_s_Page_092.jp2
196d650708d9cc8a3e78ec582e0f8e13
815060c02d1e05d555149582ba2b78d595a475cd
44535 F20101206_AACGVG degwekar_s_Page_062.jpg
ee5bf610e9354300535758394bd3c9c3
a3ad1fd053fc3a1753437862914b6a394ef0026b
56594 F20101206_AACGUS degwekar_s_Page_043.jpg
b9758a5bec9f8840cf63c7ca09f10be3
b3f3c4cee0ec0bffb4043a9963c8fdfdd3428efe
11883 F20101206_AACHBB degwekar_s_Page_112.jp2
dd62b40173747629bddbcbf888dc18b8
319634062cc5be3f10ae7e98b3f8ab1a345b5f81
6951 F20101206_AACHXV degwekar_s_Page_153thm.jpg
d83b7ef100f5c56f2dbcb52135e4c76f
3256e3d5fe37143ab3ee32fa1cb6b344bc8bf763
72119 F20101206_AACHAN degwekar_s_Page_093.jp2
1cc56df83a5067d640a6aba28210bd5e
e1f168aa0fd6c1e864e04769459d14a7b7a7d505
86656 F20101206_AACGVH degwekar_s_Page_063.jpg
bea69689e01b57fd09eab33b015a6154
2e17d5e0c4f788e7714b6711d6b882f7d69ead82
43410 F20101206_AACGUT degwekar_s_Page_044.jpg
a4f871c6ab7dc53c2cf635cf62b98031
a0347359b519e2eeb76cba1fd54fcbf6e531a63e
115932 F20101206_AACHBC degwekar_s_Page_113.jp2
efc0cda774384d1b52fc8772c7606d4d
1d172ba5b068089c7ad1ceeb890f75d58c160be6
7174 F20101206_AACHXW degwekar_s_Page_154thm.jpg
8276e12a474ff8e7da67abfd6f0d7d14
4ae62306611a16035dfd379484d3b6f30d0ec661
136900 F20101206_AACHAO degwekar_s_Page_094.jp2
5d19431751bf2374066c60150d2538cf
1ccdc2e1469dad25b99d7050d6b0163f1ae24701
90152 F20101206_AACGVI degwekar_s_Page_065.jpg
8aa428da189db6a642fccd2b096ce385
cfa300850d17c832714b17568e94110ba1836356
50709 F20101206_AACGUU degwekar_s_Page_045.jpg
e0ec9b1f24671a431bedeea8145a196c
0e52a12c2bde912900486cb65ad5e28dbce0020c
110384 F20101206_AACHBD degwekar_s_Page_114.jp2
3f00205397a3209134d429ec1b57c2fc
d018b94f31b7e7b8e800d6e55706fda12c3e8e25
30478 F20101206_AACHXX degwekar_s_Page_154.QC.jpg
d808deb07538b1cd90fde31f6a5003bb
a23e62dc4e270019af1dbd184cfc6fb7bda9ed78
145859 F20101206_AACHAP degwekar_s_Page_095.jp2
2dd1aa3f8acbf2aa8f710f5e343f1107
91b8fa7a8693c985e4e6924546ea9fe947bb4d4c
92691 F20101206_AACGVJ degwekar_s_Page_066.jpg
2cafcb2fac9e3681c5cc15f651ced5e0
9b8e8feeee2cb2f2ccc7122a94ceec844c807e8e
76364 F20101206_AACGUV degwekar_s_Page_046.jpg
dc18736aa6da31c1a44bc9ffa9d4d3b8
0883ac0ffa5669d21ccb1a11652adc47013d7375
78414 F20101206_AACHBE degwekar_s_Page_115.jp2
c6fd5451d4e7b521534f7382ccd3ef48
85f86bf8847301226f8c08a397774b343e0d78d3
30792 F20101206_AACHXY degwekar_s_Page_155.QC.jpg
1c20d4bbbbd0b74046d678649baab7e2
1c15962f21b7fcfa93dc936f235e5844631df535
68957 F20101206_AACHAQ degwekar_s_Page_098.jp2
9190263ed5fe43e0176172e9df1280ae
5f1b0d46bdbae828afec2726846763ffd8eb4425
92817 F20101206_AACGVK degwekar_s_Page_068.jpg
184132fd4067c566f8926c9db0421932
255271c80cac02f8cde69dfda29479190ac5ae90
69874 F20101206_AACGUW degwekar_s_Page_047.jpg
c552f9314c304826eb00d05f6c47d21b
8a6bf395ef397f3ddad1a6cf88a2a1411446bcf3
103715 F20101206_AACHBF degwekar_s_Page_117.jp2
195582524098dab0956870facb0238aa
989132dd9fe46d49f26ca2517034969ba2479feb
3129 F20101206_AACHXZ degwekar_s_Page_156thm.jpg
c29ddf9b4c5e0ad8f78dea48fd9a0e02
c2ddbf9eda8911b55b6ca819ab1ca1dfe1f12c4a
62348 F20101206_AACHAR degwekar_s_Page_099.jp2
4c6173fac5524913e0db6b6868223b88
518442e009b198113843e03f732d1754642b6e6f
86911 F20101206_AACGVL degwekar_s_Page_069.jpg
c7a9aee4ac6cbc68109f493d52d6bb4d
0115acc3f166adec3afb8a9d4ab5bcd64a56b9bf
83197 F20101206_AACGUX degwekar_s_Page_050.jpg
d7899c81a2dc780f520511da42b6a1ba
2064fda3d7352977e898d4271bafae07058cad5b
90005 F20101206_AACHBG degwekar_s_Page_118.jp2
317eaeee2172deed988b60e8dca369c8
3211a8bb6748cde3884f763041404d88b453d14c
57755 F20101206_AACGWA degwekar_s_Page_090.jpg
738d496cc61c8ada716f285af6a785a5
bcdba6c75d879752412b932f202b3139f5fdb207
76675 F20101206_AACHAS degwekar_s_Page_100.jp2
c938233b7359c274e976cd816c7e9643
fcb62afbb9c1d321b06eaf8becde1d5dc40787d4
91334 F20101206_AACGVM degwekar_s_Page_070.jpg
cabbe112df65ab6d16c3222d1ab47103
f13c6e08242e3b976730f0fdf249798d47040fd1
89069 F20101206_AACGUY degwekar_s_Page_051.jpg
8995289e357c7beae8779d2641bb9e7f
002e305c456677c7f00722897ef67df3dc7659c0
48395 F20101206_AACGWB degwekar_s_Page_091.jpg
4eef9b048502e480a85e74c571a957b6
19479694b03ecdb958ed360c1b5a847c07ad3fa8
62279 F20101206_AACHAT degwekar_s_Page_102.jp2
0145a700fefdf5acfa577b2c028cb6d1
bb13d168f8c65bf2092d52904eb466893f682200
77161 F20101206_AACGVN degwekar_s_Page_071.jpg
2e6f73aa9bdf8faadf52a43d8da7c9bc
8ccac737600c93185abc36ec69f0e452eb864bc4
87018 F20101206_AACGUZ degwekar_s_Page_052.jpg
21181c8b74086dc214aadd20718ba5d7
bc9f36b6c393b2edc15080668f9df439038c9e22
108675 F20101206_AACHBH degwekar_s_Page_119.jp2
3359936c557e79b85b4083ae0c2ec50b
27cd02736df61ab02f81a097a3a0bfe2729e82e0
41369 F20101206_AACGWC degwekar_s_Page_092.jpg
923b70df230e62109250f59f9e411c20
b494ba0bc670039fa00d7890830f913c7ad841f0
65134 F20101206_AACHAU degwekar_s_Page_103.jp2
8bc0955ead98966760d202bfb97e3d8a
8e58c7a5e71b28b800e45a75438dcd18b403d41c
89394 F20101206_AACGVO degwekar_s_Page_074.jpg
7c2b0d5b9f72be9bba6d8ab00c85dfe6
fe08acd5555bbaeaa49b37c8f6d518a2fb090069
114335 F20101206_AACHBI degwekar_s_Page_120.jp2
f982d8ec839fb8fb8fb9c71476adfba9
ac55cd2a9aad630355fb026cc4e53f86f97a57a8
64936 F20101206_AACHAV degwekar_s_Page_105.jp2
f5b764e68335f571f255bdd168ee66ce
ee5cb583a0c03ec236dd0eb9b1ae2e7ca362536e
60981 F20101206_AACGVP degwekar_s_Page_075.jpg
10b6bfd8d42d0222cffb5a54b74220ff
d502ede89e48dc1f4e3c0410a904a17d8af78a44
103690 F20101206_AACHBJ degwekar_s_Page_121.jp2
909a5394975e39b5e640151e4b78cc7b
60e9f11b1aed8a8529ef3f734643be60707f6652
60212 F20101206_AACGWD degwekar_s_Page_093.jpg
8678e898498f224b68c320c26166c2b0
1f00f357366c0f52ff67a4591cb46d839a46b5dc
75903 F20101206_AACHAW degwekar_s_Page_106.jp2
2fea1a7f995c72125e7e3fe466141a50
db2077cc60eb39b3f92358d42bf12525fde01ec9
33581 F20101206_AACGVQ degwekar_s_Page_076.jpg
ae4ed3464d5671a94dd14dc018555351
022db248d75a62c483be50672b76b04dca2e3473
107500 F20101206_AACHBK degwekar_s_Page_122.jp2
2ce678a4fbaaf4017394f598d84149f4
ccf8befe9a0d684baaf1d3518bc670e9e931c0bf
111876 F20101206_AACGWE degwekar_s_Page_095.jpg
10a082d20737108d6b02d919d7ce01bc
4c5e311d2cb67f4b50ab39f7c54da93b5e4e2ec6
73378 F20101206_AACHAX degwekar_s_Page_108.jp2
a86a0cdeda149e933264bfaff5cc5eec
6a8f5c2b7a12706fed86590a4d22187ce62a5332
31903 F20101206_AACGVR degwekar_s_Page_077.jpg
823e3c23b82002c1ca76b2a9d2c2d9ab
d997a08ce330d96cc9bcf7dee6c55ff08d516534
118370 F20101206_AACHCA degwekar_s_Page_145.jp2
1d4c0b5ee018a09300ec7db201ab95d0
abb54d81051b99af7e4e894cdbaaaece6665fc01
119908 F20101206_AACHBL degwekar_s_Page_123.jp2
56a10675cd46849cbdf06ecc47a84aa7
1b20f75e183c270347d9c663e5c0122be97c9155
61649 F20101206_AACGWF degwekar_s_Page_097.jpg
d049b0f1db6c5bba0384a81383014cf1
a1e0c5c6193e02934371114c284109645ce4c482
88843 F20101206_AACHAY degwekar_s_Page_109.jp2
988eded8237d71871264849c9a5706f5
613e51f392795d2270afcbe757803fa89182e81a
85602 F20101206_AACGVS degwekar_s_Page_078.jpg
0711e2c0cd2c1c5615575c63b944b1ee
88c5320d9488eed1e60f001f2d3d87afbf42762e
127700 F20101206_AACHCB degwekar_s_Page_146.jp2
07f635bbe7c1529835ac8e826bf7aeea
7dbfe13333a19e89ecc23ac2e4763301716db9b7
104152 F20101206_AACHBM degwekar_s_Page_124.jp2
968a1a061fa9c4a0283c92472a763709
d40b1c635144819b8398f2dc3089b4e1e9320802
53290 F20101206_AACGWG degwekar_s_Page_098.jpg
e59b1f0c33c97c4061d3ae0028f8c484
c51ee3f46312201b31bae17a71c59c377763c5d2
79159 F20101206_AACHAZ degwekar_s_Page_110.jp2
4da9a37ac71f29a3253a4724bd2d6103
68955afc1f7b17e7f5376ba6029666cb0569e09d
67474 F20101206_AACGVT degwekar_s_Page_079.jpg
c86adea1cfd28a6a77cb20f994cf491e
9a919a7b772cc1ef378b6b4b6b4cdf7495014236
137719 F20101206_AACHCC degwekar_s_Page_147.jp2
a8e1e16bc68df1a989608a254a97c4d2
26937730a42d6e8dff9ed00e659b427821653789
98277 F20101206_AACHBN degwekar_s_Page_125.jp2
78f5f9c643c8874f2b6d22ae791c835e
19ae1a04ad63427425fe522a62a2a655841e116e
47188 F20101206_AACGWH degwekar_s_Page_099.jpg
6d5edb6191f8f841e322b9fa6faf59ea
2ed6cfd1e3fb4e11d69b9f373c376a1f743cc76b
90818 F20101206_AACGVU degwekar_s_Page_080.jpg
18fc8adf3e054712633c2a67cd3d42ae
bac10eba9120379b95fbdc4f737d39b53e01d8d5
110605 F20101206_AACHCD degwekar_s_Page_149.jp2
11cec11844d320f8e88fe23ed6d3a34a
b0e6ffd34e09acd6035071364a70132948f94f8d
95528 F20101206_AACHBO degwekar_s_Page_127.jp2
7f798c77cde121639897d46a4e26f35d
fb7b3b9bc490261a54373213650e7ca4a49be34b
58236 F20101206_AACGWI degwekar_s_Page_100.jpg
e06877ea2fb2a9f014f5b3425e2569ce
eecee42ed85121556114c546890d6e83b3670ccd
88031 F20101206_AACGVV degwekar_s_Page_081.jpg
c8677e0604e925f328e713993f128dd2
b7df48af8f58406da546d370112e42dcf7a941ca
55329 F20101206_AACHCE degwekar_s_Page_150.jp2
7f9bcaa6b4be3673267ac143b3d8e84e
c2e6c40752e358b21e3876dacc1c714bd7f2f121
75885 F20101206_AACHBP degwekar_s_Page_128.jp2
52c91040bb66c47c58a3585c576a6412
41acf120f3a982106b13de97529c50241f76a697
47212 F20101206_AACGWJ degwekar_s_Page_102.jpg
45f4be396d888f128179e8a8eea6a791
fd6414224f41c01325539863afbdeaf1e456e8c5
90249 F20101206_AACGVW degwekar_s_Page_083.jpg
f76abdaa8fdbbc03699e63ee10133aa4
caf5487beaffecacd42cfe30fc3cc6d6714a2037
133531 F20101206_AACHCF degwekar_s_Page_151.jp2
583453aead085c46c93eabe47b12444e
878042a474b4416dfd165b36e3fc1affc025ab34
47453 F20101206_AACHBQ degwekar_s_Page_131.jp2
9d2ef90b9bafc6b3e81887862350852a
c0ec169472232042349df90f49fb496f2fb2bfd5
50130 F20101206_AACGWK degwekar_s_Page_103.jpg
39e6af27fddb1590a20f824f691ff83e
2db45875f409481e49d3effebf1583a60bb000b0
75570 F20101206_AACGVX degwekar_s_Page_085.jpg
2f566402a831eb706cbe90bba34cc96d
cbc1e6a40f222f36c1dcc1629909eea645822f4c
133768 F20101206_AACHCG degwekar_s_Page_152.jp2
741f9966253c1efb4134575dab87f4cc
70fa333a88991963f3f64f8d1387b6ef590d886b
86339 F20101206_AACHBR degwekar_s_Page_132.jp2
53ba109ee7b9734bed5d6cd1536be2c9
ac8b75c4c2efe90f5c3c94d2e40af7f8f5915ce8
48869 F20101206_AACGWL degwekar_s_Page_105.jpg
35aaa91188620a46bb966d80a43a45a3
6526f9e27f503aa4d566cd09a53d8189f854a1ed
78608 F20101206_AACGVY degwekar_s_Page_087.jpg
bc4faae3ae6d6f1a04bc13d0896e9600
2d43158f924caaeb46fd2986a39b398a89895f56
135142 F20101206_AACHCH degwekar_s_Page_153.jp2
3fcd90b540939314e17babe7c121fa7a
a7066643f165068f84b3f8cfe52d0d9c87b9ad8d
78613 F20101206_AACGXA degwekar_s_Page_125.jpg
87a080037356f0b1ef425369f779d1bf
5c5c59c160dfe996518832a32cb773103deb9ce1
129079 F20101206_AACHBS degwekar_s_Page_134.jp2
b791a456586e842e76fdab2a1023cc4d
e2b3b089b99a9573dbbcee7709925479c3316a05
56949 F20101206_AACGWM degwekar_s_Page_106.jpg
73078d6417dda5f6b6e0a22ecd94c150
8b09e274d720dbc90a620186f6d7f90b4b961a4f
85300 F20101206_AACGVZ degwekar_s_Page_088.jpg
e0f1e6abebc7072c97af4a8df88f3f9c
792697179d03454184fbfb098f885e55ace51f28
79278 F20101206_AACGXB degwekar_s_Page_126.jpg
1831f59e1802cf200077798977c251aa
b4919389e0b9603fdd8aadac721c5351047a7835
131642 F20101206_AACHBT degwekar_s_Page_135.jp2
38eba3a6d877e0267fc901bdad2b0828
bc763b15e89e7eff95f2dcc294dfec756ea27e18
47523 F20101206_AACGWN degwekar_s_Page_107.jpg
53739f808c39cf805081cada7b78f7a2
f7e8c5e57df88bc9b530d8dcee83fd1b71c4acdf
138109 F20101206_AACHCI degwekar_s_Page_154.jp2
c1739d85fb5731800a11636227c5491e
a3fb2fad0100bc46306c318bd7f4bd1cb0324566
28660 F20101206_AACGXC degwekar_s_Page_129.jpg
27cb2c8b5ad76d22514fbf946407a1bc
4fc099094b85847d801c36693b851bba073a8313
138907 F20101206_AACHBU degwekar_s_Page_136.jp2
aec1979b28c46bb8f485d7a1dab9a6a0
64481890160274e157ab36f6ee4680adddea00f7
67643 F20101206_AACGWO degwekar_s_Page_109.jpg
4e6a6f089b7bb3cfe6b64c67475165cd
a297327518c0b7f325f08cd2b741ab2640302cd2
55074 F20101206_AACHCJ degwekar_s_Page_156.jp2
40e7d25bb7b471f7edd6b6a8c5a9e828
2155a0bab55ba759794900a7f22199f23d3818af
36556 F20101206_AACGXD degwekar_s_Page_131.jpg
70b7f390a048ddfe1732cddbaaeb67a2
511b566af3fbb1fd4526c038b71c643106d2df5d
133749 F20101206_AACHBV degwekar_s_Page_138.jp2
b69d95a8684f87a55eef2a6fbf5138a6
1fd66f89ee3e8372afbecc04132c272f9db0dde0
61021 F20101206_AACGWP degwekar_s_Page_110.jpg
8a3321f087acfcdffd41671dec2dca64
5d697d83c660c448020acd0e92fa8b39d65e7ad2
75884 F20101206_AACHCK degwekar_s_Page_157.jp2
b12c9f86a15c7ac7f80e51ef95a4e49b
6f7928f5ec0b4b66fdf860627767564f4a774938
67825 F20101206_AACGXE degwekar_s_Page_132.jpg
266790bf0f48995fa88900bb8564d38a
47513a8fa84b3b2ae528ddf4d3871bea236afc95
121096 F20101206_AACHBW degwekar_s_Page_139.jp2
5201e0379e49d919227035b224682bdc
6ffcd1189b560a1c8d8eb627a9b78888ca21cf08
56081 F20101206_AACGWQ degwekar_s_Page_111.jpg
061767b41dbea5d805fa6796374092cf
b2d8d8669ddceda0f484d36c0b591bb1470e53d8
F20101206_AACHDA degwekar_s_Page_022.tif
8a5989c41ec385ef6473eb4322904fd9
d74c6ba04aef218c8ff74e25356fcb0e47f3c96d
F20101206_AACHCL degwekar_s_Page_001.tif
e05c5613a476b35653b688192cb8204a
a7e85d25eed2670ded8961519146ce533241726e
11947 F20101206_AACGXF degwekar_s_Page_133.jpg
7052a0c50f4ba9b94c06916de1739904
50c07f5a1b5618fbdede2aeeb552a917fc1df299
163264 F20101206_AACHBX degwekar_s_Page_140.jp2
5ca38f2f3fd861d439ed746219112a20
2be9225717c6e04bde3b5d402ae75ce591563ee0
8934 F20101206_AACGWR degwekar_s_Page_112.jpg
5a0429993726eb98d0812cb53c3f9a3e
fa18086f3b0a985c5b57bd71bd5dcd2ddb8fff31
F20101206_AACHCM degwekar_s_Page_002.tif
ad4a975a1a2754794017e9edf3ed8453
0ae2e529fd0078012d6566e7357f03324c1a4776
101475 F20101206_AACGXG degwekar_s_Page_134.jpg
d9bbd51006f57357fb16a6095d0987c8
ee558eb912740f1aa809bbfd435742062d9b1ef8
144935 F20101206_AACHBY degwekar_s_Page_141.jp2
f282462a58a230d01be2c87929974b5a
d57bc37cb22384cd311068d5840b61156e634c4d
84658 F20101206_AACGWS degwekar_s_Page_113.jpg
abacc5927ad44f128c22a0a692abca2e
81b56475fbbbb05f6cf7f2ee9c8e1e5e30e657f2
F20101206_AACHDB degwekar_s_Page_023.tif
8a9081a22662528efa17b071ccd1df01
3d9febd6a6a24ca96475f010b9d602d6d56e330b
F20101206_AACHCN degwekar_s_Page_003.tif
80faee60f2540750c3d3a04a9a10b4f4
f2555bbd9477042816d6e8b0800523a3c5afae34
102730 F20101206_AACGXH degwekar_s_Page_135.jpg
729059daeb0eff1edf9bfd8eeb021b56
1809ddea0770ed3213640c3b57650a63fd0a62bf
116821 F20101206_AACHBZ degwekar_s_Page_144.jp2
4c4e7e635a0c409a4573ac532028c820
1e010cc001fd7171aab808ff521969079413426a
88550 F20101206_AACGWT degwekar_s_Page_114.jpg
22bd51c5e6daf02b3d9bcd5e0de1960d
a986c031d44a639896a25135fa03d743c30f325e
F20101206_AACHDC degwekar_s_Page_024.tif
36d4d4de7477d2ae1a9b0a1e3a4b9f45
ce3421971a29dfbb332cc085d147f10e1da8aaf6
F20101206_AACHCO degwekar_s_Page_004.tif
00d384e26f0d3eaa17fa9b7f21d0a334
9f0957d70d3f263e33128c62e0c1a71ecb9afd47
94587 F20101206_AACGXI degwekar_s_Page_139.jpg
a02f9822423984c738465fb851eb296f
b08b34442ce0c710bd8911519a39fd6a2690821a
83729 F20101206_AACGWU degwekar_s_Page_116.jpg
b194f8aeb9727711610b691066cd9152
6ff41844926526fd7ba131c74bc972dcd4a0b7bb
F20101206_AACHDD degwekar_s_Page_026.tif
5ff552fc51ce86377314a6b60d0d1b92
df6f3678f9637cee1589a7c3ff463a4596f83e65
F20101206_AACHCP degwekar_s_Page_005.tif
2c75e05c9bcdac818966769f2a85b102
a341a43007d5100a41dd15206aca10a60de0b4d8
114759 F20101206_AACGXJ degwekar_s_Page_141.jpg
cf57ba40a0f3d2b7fffcb7a3c4604ea8
901877524eb80e214b3db6bb86fbc5d771e1fac4
81861 F20101206_AACGWV degwekar_s_Page_117.jpg
40de9d85dc2028fa49995137a2dc3046
42b4992bb62a514497d8b618cd161294b15002d1
F20101206_AACHDE degwekar_s_Page_027.tif
2d2e2ec86374e350cb5d92d2a007f8a0
ec0338c8b51994cca481e9bf6d183b3eee7b9519
F20101206_AACHCQ degwekar_s_Page_007.tif
b353ed2c1bae71038a3c6e2798a5c913
43d3b269739cc856434b4d06b8a19ae964da7887
90247 F20101206_AACGXK degwekar_s_Page_142.jpg
a95e6670c0483ac4d124bb942c5a4e78
ea2919cf9726a5ecf276d82a5b378f25227f8985
85999 F20101206_AACGWW degwekar_s_Page_119.jpg
1589532e4412b51ee5e428143d9b4a44
e4cead866c2f61efb31cda2a42ca12bd9d219726
F20101206_AACHDF degwekar_s_Page_028.tif
5365bb56277159fd55d61902377da92f
a3fbf727f8bc92abd3eafaec2160e73a44f59329
F20101206_AACHCR degwekar_s_Page_008.tif
cc4993380d90934ea1715adc7ba85119
0974e1bb127e9161a0e39b63c9a4626331e2a479
87644 F20101206_AACGXL degwekar_s_Page_144.jpg
755dae944811b287836ac2858b2cc14d
1601ed9174dddc3ca5d35eae7bf119662750a7db
89497 F20101206_AACGWX degwekar_s_Page_120.jpg
bb8ee29e2ae421a3aae1d97bb3a7e527
759216a473f1829635cf759a21f4e94fd587a55b
F20101206_AACHDG degwekar_s_Page_030.tif
bc50d0e72ee4938730200524e882d150
73f72ef95088a88c274a901a4522c0c97f3f21e2
1051980 F20101206_AACGYA degwekar_s_Page_006.jp2
26a573899b1a932b1fd7e384a284671f
684139b8e8d9a57e505969326b7d31115335a391
F20101206_AACHCS degwekar_s_Page_009.tif
1d7b819e0c4f0f7a89bd43ab5a795830
cfc0f50a65c6c1102969a5a2e9553ac142743359
102219 F20101206_AACGXM degwekar_s_Page_146.jpg
057244bce13edb1b78ca1f3de5cad4a6
5555a2183ea4dcf50439a1671531a6eea0eacbc7
84766 F20101206_AACGWY degwekar_s_Page_122.jpg
04141f076b9880aae3d4ee7b5dc7011f
d189e6a19cff7ef3bcfb2278feb82ab8ab80d978
F20101206_AACHDH degwekar_s_Page_032.tif
46274e4be9b5806d18e0b87fc5f8c72b
659fa97d6f054fccdb76a3f88fcfcbd87f3b13d9
1051983 F20101206_AACGYB degwekar_s_Page_007.jp2
80420efb2451c5e1f26a4ce5520e98dd
a699214a437309fc7a4e8ad31d9841ac3bf0cd84
F20101206_AACHCT degwekar_s_Page_011.tif
4804c07854991ebd35a4b78658b2bb42
97c0c100ffd4b520cb0e81127d6e5f7480c00269
86193 F20101206_AACGXN degwekar_s_Page_149.jpg
f64871105e1b3d7957d30a95e91bcbaf
4bd84f08f0cc6e63af13021d4f3924be50560c6e
81650 F20101206_AACGWZ degwekar_s_Page_124.jpg
803af75244b4b50fc878c2c285bfd345
465af8bb5e21c1740f2ee82ca8e4581475744473
F20101206_AACHDI degwekar_s_Page_033.tif
75d9ae013e9136310c523c3082dce46f
b03978df9232a9fea18516c5795ed06d224feaf4
90860 F20101206_AACGYC degwekar_s_Page_008.jp2
3397d0c2b681703fb7e67968a7fc5293
5384923c000fca5105c8134fdf7c36cef99cc686
F20101206_AACHCU degwekar_s_Page_012.tif
0958546211b43c9746523a5293fdd849
4fa8b0a787a11090bf97ff1cd64ceeecc10df26f
43659 F20101206_AACGXO degwekar_s_Page_150.jpg
97d35bee9da6b3b93ff04d4ea3c40f13
897dfd49ae6b7c0bc2afe9c2e9a34842772408e6
387537 F20101206_AACGYD degwekar_s_Page_009.jp2
7c33c8c1cef82cf999999d3326d70c3b
2522e375384b1bd0a76f01daa38cd97a989ffe04
F20101206_AACHCV degwekar_s_Page_013.tif
f6997d8cee5072c14b75b6a2082ec903
b81725ab25014f80220eee59e2914256011325f5
104402 F20101206_AACGXP degwekar_s_Page_151.jpg
c4582c3b21ec0e745e34ceb657156b0a
20b029979c292dae846a0d8709e2c83685b5329e
F20101206_AACHDJ degwekar_s_Page_034.tif
9fae3e9623dd65b7d3993ee55e72a0b2
f3e044125fc2fef4249fcdb844fc0a43eb7d8491
1051970 F20101206_AACGYE degwekar_s_Page_010.jp2
20cafae56f2025bec32cecd5896af741
f52585953b7c64f7498ae7fce1eacaafc2fc9ca7
F20101206_AACHCW degwekar_s_Page_014.tif
4b3857201aed8d4f86fcfc61a46a7cda
09307071974736584dc807c843af50b447f8446a
99519 F20101206_AACGXQ degwekar_s_Page_152.jpg
69d3f94e6afe79ae98d869ee08be350e
b3998cbb3ead847ad926d1ceec3dfb7b9a05c893
F20101206_AACHDK degwekar_s_Page_035.tif
01bc1a04813cc04fb3eddf824f6c2054
fc2ccf75a7c62cb1e4521f5eae828feea51e3dee
100068 F20101206_AACGYF degwekar_s_Page_011.jp2
7ddc4314c961b9bb09f70477a0acd998
bd53cfd3e5e0126f7db66b5061c833eb782125cc
F20101206_AACHCX degwekar_s_Page_016.tif
b501c8c4c48e50cb2e1b0a32f6203a4a
3fc3869ce44f2cce43713c2d77b960feca569210
104871 F20101206_AACGXR degwekar_s_Page_153.jpg
6e8655b4c7d7ca6e663ae6e1ff3c322a
cfc6d315f8fad2f27643a2e3c72c9f05fc8eb53a
F20101206_AACHEA degwekar_s_Page_054.tif
e8232fc92fe02d3c5f760dde6f3ed472
60041ecd4ae9cd26051763af51650566b48ada0d
F20101206_AACHDL degwekar_s_Page_036.tif
5491d5015c513e8f49c8b28d4bcd2619
c877cf2f72bcd5f91b82e1e20358ae9b5019fb1a
113293 F20101206_AACGYG degwekar_s_Page_013.jp2
a1f10f3ae2db5f406043b90b00817fd2
930b2167daf862c7aa72dd5ce1c6ba77fb149681
F20101206_AACHCY degwekar_s_Page_017.tif
573c0b5afeffc766ec7a38b2a0d5c51b
8a577674b0b0827350ef9eee2a525840cfda075a
103671 F20101206_AACGXS degwekar_s_Page_154.jpg
3c451f8a172d744286f89ac7e5ecee1a
16723fdec8207826cd8346cde89cdc678b358eea
F20101206_AACHEB degwekar_s_Page_055.tif
4e5aa323feadb9a6e4eb2fd04718376e
06e964e6cb26129bb7db89ad9df7df3eae41c31c
F20101206_AACHDM degwekar_s_Page_037.tif
6112577ac52fa80561aeeb8094e6cd5e
1cec55484eaa543bc443bfd42b02c33aaa15f3aa
F20101206_AACGYH degwekar_s_Page_014.jp2
08d02fa109b4a1cd9a8b1eeb00b2f40f
e6c7ff3d63e5ece614bcd510b6b1467556c0e17e
F20101206_AACHCZ degwekar_s_Page_018.tif
598165f0097b4608eaf5aa11c7704786
3fcb7c25f58f61a969b7f5952a52fc3b02a9d9e7
111029 F20101206_AACGXT degwekar_s_Page_155.jpg
53af54eed2122b6017a2946d349cd5fb
235b7a9ed01e2bc31f5e8f1aff01485e924c952c
F20101206_AACHEC degwekar_s_Page_056.tif
bc8ccad2d5c361f364689b670554413d
0ae3cfe2192dbaaf80a1a98d8d9f1312f33cc874
F20101206_AACHDN degwekar_s_Page_039.tif
182249aeffce7fe9e6e370c6617ecf11
e9d61641fd4b02b0cb560de0a2338acdc74eda6b
120429 F20101206_AACGYI degwekar_s_Page_015.jp2
21e8cc9be03f0cf99191b466fe5478d2
1934ac2a1990162ddd1475966f00948bf06fd70d
42067 F20101206_AACGXU degwekar_s_Page_156.jpg
dd03440a7d83b87fd7c8bd8ada5471a1
1ec55f95505b282649edfa05b23151744e203289
F20101206_AACHED degwekar_s_Page_057.tif
822849ab9a3c7d47955fbd6c6d219c14
8918e87ba4cf163d413a7e49c6ee08153f895eaf
F20101206_AACHDO degwekar_s_Page_040.tif
b9a6f1e388d53939503c2fa28ab0e8bc
7adfcee4224fd67ef149b5786b4dbdcf3d1858f1
119582 F20101206_AACGYJ degwekar_s_Page_017.jp2
1e321fb82d570226b89d57031e0d0240
117896c7e3f01875df7efe1eadca991c24e0cff3
57677 F20101206_AACGXV degwekar_s_Page_157.jpg
85b0fcd052318c41b2260272e2b2317c
cc9a8c978e84901264a029ed16fdcecf7655b407
F20101206_AACHEE degwekar_s_Page_058.tif
6c37193c8b13650b17af796737c4960a
2b99a58d8a2a54d7f130e7c4a00dec6dc51e635a
F20101206_AACHDP degwekar_s_Page_041.tif
f01c0e449908b590c992072e2e1e2609
f3e04fda86ee4bb6f406408b6255867d25e3b57e
47130 F20101206_AACGYK degwekar_s_Page_018.jp2
be8184e0746f2ff295c67b2129b9a951
ec38d619c72c31f3c76cf60923609d80e0e6b063
25661 F20101206_AACGXW degwekar_s_Page_001.jp2
e77a5998f0083b49bde8dc792a0371af
fa5a26bd693ebcfeeabf653490a886a2b1723196
F20101206_AACHEF degwekar_s_Page_060.tif
1e6c4b792f28d00dc33834f19192cedb
43188c211eff1c4561535a86213d323ab6b1dd80
F20101206_AACHDQ degwekar_s_Page_042.tif
f74a59bf043e8d3d8c868d0a5fc0a62e
65ae4d7b51dc3bad32973bb97dc33f1a411922b5
91886 F20101206_AACGYL degwekar_s_Page_019.jp2
70238e118d52acf517b484ffc33f7cd1
d109852e09be0fef5d1c926e477cdac138b9432b
5969 F20101206_AACGXX degwekar_s_Page_003.jp2
18b5a370dfd8c6f6807a45d0b622af28
0cf9a7850b15bb5215fdeca4cc31543b0d172621
F20101206_AACHEG degwekar_s_Page_062.tif
94b8a945fa144669b36e607976c78d4d
ce4c97f87a85eae3dae0bc41231501ba3b08f083
F20101206_AACHDR degwekar_s_Page_044.tif
fc36ef01f8e2791217efb829517a5eea
a0e0a938980e634920336eb326f11c6011c448f3
108271 F20101206_AACGYM degwekar_s_Page_020.jp2
6f75215ef1596cd33691536c293bdecd
8643faf999c85774249205a45152c0be0bfd9162
109526 F20101206_AACGXY degwekar_s_Page_004.jp2
bffc631da980f3b915289080a888dcab
04fe61da5ccabb915c468ff943d085dbe2417f43
F20101206_AACHEH degwekar_s_Page_063.tif
35373530e0e6770c6c3190617cb55de1
98b001580bfa1974defe0cac59b711d44baa9223
59411 F20101206_AACGZA degwekar_s_Page_039.jp2
7a72940dfbc221593621862c1c380c59
e50efa1da29169d2fa4565cc743f95d68b6226c8
F20101206_AACHDS degwekar_s_Page_046.tif
b5394e7028cc98cf2b39f930651fca2b
5ad0fb39d6b7218953222a1418f52ef0144b20ac
107744 F20101206_AACGYN degwekar_s_Page_021.jp2
40f5ec71e48148181004e180d7e3ef24
035de2aeccc240855733374dbae9e4146f81d300
25671 F20101206_AACGXZ degwekar_s_Page_005.jp2
96f5b83f631ccffd97f5258ddb2f2dee
69a405c408b53776619dcf2955e70e3ea82362b8
F20101206_AACHEI degwekar_s_Page_066.tif
9e2b3e69e7e982032ef78e4125e060b7
8d5db0389ff7c3a0fc71dcd561708fd4039886c0
118575 F20101206_AACGZB degwekar_s_Page_042.jp2
163b1872d971aa86ebf3dfa2bf387868
26dc41e0677e3b57979d43b52bb1a36f1eac295e
F20101206_AACHDT degwekar_s_Page_047.tif
53ca162201dbc03347f0bcec0a4d98b3
acc5ae18b1f41c28c0ce6f392b6dcd0b7b0dc8e1
122380 F20101206_AACGYO degwekar_s_Page_022.jp2
bc8059b2d54d0e01213c6204455756db
ae228507cb92cb11c92e4de2453b7722eaa0d5bb
F20101206_AACHEJ degwekar_s_Page_067.tif
97f76a5e53e30d7696fa6a02736d0af6
9da9060055a71d441173cce064afa7675dcb1870
73109 F20101206_AACGZC degwekar_s_Page_043.jp2
92a54bb79ea5e1368169d78bda39e1a0
1d0fcc06af40a2bcab69ce4c8cc379abe28040f3
F20101206_AACHDU degwekar_s_Page_048.tif
68bae5423f6bad12fadf6ad575f5ecd2
e27a6e251023507c9907f2f451db88bc880a2169
112210 F20101206_AACGYP degwekar_s_Page_023.jp2
1610e7e03efaa3ad0851d96d5ff17481
49d2e7207460ceda05c311ab6162b675b3912c72
57706 F20101206_AACGZD degwekar_s_Page_044.jp2
a85d53045dc91291a78cc3bec71d74a5
38cfb9ab37860f60edc6220e95aae3d465c7be0c
F20101206_AACHDV degwekar_s_Page_049.tif
fa59d64b2b99cf62f97783257c8532bf
9f0c8458de98aad1fd87eeccbaff9ac03e536802
119997 F20101206_AACGYQ degwekar_s_Page_024.jp2
11036c47069e09d0993abc7e1e8d1956
58a33175b70e584d8da3f00303e25f81f423d72e
F20101206_AACHEK degwekar_s_Page_068.tif
e8449b8b49474522453af964294977c6
25bd3b7def79eb62ea647e92af5df0d0939ecd51
89233 F20101206_AACGZE degwekar_s_Page_047.jp2
1c9f487455cb0d04e59a9a7a45a5cd33
98f2d175c47bf10c1084dd6f17e7acd2c2a0670e
F20101206_AACHDW degwekar_s_Page_050.tif
2836f9f3fea01d9fa36b648c6b0754fa
117f10fcb1ec12bd6ba75234270a2dac49f02983
80307 F20101206_AACGYR degwekar_s_Page_026.jp2
d1658db679e8572da044ee05eda31612
c1c5fb239f7b66c2d9fdc2a9758e18c8f3c92cee
F20101206_AACHFA degwekar_s_Page_089.tif
cd7e9175e30aa4388abf2eb3357e820e
cb52333e90df8b8a604c78992fe110b9d41e9c32
F20101206_AACHEL degwekar_s_Page_069.tif
417e076554522c322d51901dcca28018
83e3e829cb7b713c3a791dc281dbeb029e158038
20214 F20101206_AACGZF degwekar_s_Page_048.jp2
1174f379984f15a25699955df856ab7b
08f0357538bfb90870604fbe450bee2e5a96637d
F20101206_AACHDX degwekar_s_Page_051.tif
95c0ad9d4dd7a7022cdc67e5efa1d4e7
f0c789d760e31fb5a1bddc2c37943b69d19910b8
102915 F20101206_AACGYS degwekar_s_Page_028.jp2
97cfa1014d1756db915b16d857e34696
e9e38342228a16650f84ef828689842b6551ac6a
F20101206_AACHFB degwekar_s_Page_090.tif
9c146d7a0d55f4929aba6c7c1138ce91
9ad1eae299bf5e2b9cd82062a4c30a024f91fca2
F20101206_AACHEM degwekar_s_Page_070.tif
8921f9758a187a6d3fdbcf43d251e814
fed8654de2011121f91584608b301c5131fa291e
108386 F20101206_AACGZG degwekar_s_Page_049.jp2
059e5fd33f5180b2ecfb3ff7eebb7947
ee14eccea9fcd088612f6d62700782f180809717
F20101206_AACHDY degwekar_s_Page_052.tif
1cfe30bd9be317668c3c70859ff7f7ee
627eba1436f5843f98462dadc2488367447c9b69
100580 F20101206_AACGYT degwekar_s_Page_029.jp2
16fc2b6c05cfdb80630854f005829fd6
1d37ca1614f891843fb07b09f3ad29394a62c9f5
F20101206_AACHFC degwekar_s_Page_091.tif
f0a9a57f15be06c1efb58e8278c9d98a
cd6144f20927fd40664c6d64175f16d8bef59037
F20101206_AACHEN degwekar_s_Page_071.tif
0fc61ce3d20a4be47ad8255681b46aaa
7ea72502806f1d8e4f159e2e247bb37bf6a4bebc
110762 F20101206_AACGZH degwekar_s_Page_050.jp2
0c276f1877199678d0ffa75fcdeb1e1c
3d45bf2cd9fd0d83507795346036b11dd3ba3f0a
F20101206_AACHDZ degwekar_s_Page_053.tif
5f15bd5aea5160d47ab723cd3740fb9d
a5b99d9e222eb7b56259626e3647f04826507b5b
107973 F20101206_AACGYU degwekar_s_Page_030.jp2
dc21d0af764e52b21f5ede73bd432855
7edaf6292f2dd07419335849286bb6c9ac131f2d
F20101206_AACHFD degwekar_s_Page_092.tif
ae1f48d6fd1544fb60930d67a1f26915
e6ae995f7e32cd72193ecd2494b85364a83ab75f
F20101206_AACHEO degwekar_s_Page_073.tif
1c1d17e15e463232bf11bf441f2d9a71
e9b8649c88b6277186f7d681cbe01dd3e0a3087f
115489 F20101206_AACGZI degwekar_s_Page_051.jp2
4b9d24c691a62f4cac09f5c8fc46ec1b
7af80c21b8cdbf0b82158f1570283299e52773fc
93618 F20101206_AACGYV degwekar_s_Page_032.jp2
2c9136354c79608b0994f31d2c230b43
edcceae2b070e7dd16e30d6d37da7454207d3ba9
F20101206_AACHFE degwekar_s_Page_093.tif
ca91364d699ce41d705b7baa14d34a5b
4d3b5829d7269149814e83b74c02e334dd16e478
F20101206_AACHEP degwekar_s_Page_075.tif
95813fc3769caf877bf9e5931e9a4fec
dd2d60c2237cc3c0056148a73d9f76d025d13243
114300 F20101206_AACGZJ degwekar_s_Page_052.jp2
94233ca20dc1430dff5402f97600d8bf
473e4af86116d95a71d59d62cb9b6d41023b0b0e
106975 F20101206_AACGYW degwekar_s_Page_034.jp2
8bbb1ef25da274e86a900b40c00302dd
65633502ff52ad0bfed5333d5aae855709bed05c
F20101206_AACHFF degwekar_s_Page_094.tif
2ddda25bb80cbbcc9f73fb276c3cc1fd
36ebf7c6a7f623812d31197ee3f66876ae4f306a
F20101206_AACHEQ degwekar_s_Page_077.tif
414729c199e07e1aac078d2fffe98ad6
44019fc8ddf45f007a881a0e20ffe91c851c5e89
113672 F20101206_AACGZK degwekar_s_Page_053.jp2
34cc85485ac593fd28f4a04c5872594e
db773f85de30fa43e08fedce63dfefa54d457ad7
105843 F20101206_AACGYX degwekar_s_Page_035.jp2
972ea9adeb2eeb5e05eb0b13bed7a152
f73c9f52603382d12a75f579afefb0fd28081e92
F20101206_AACHFG degwekar_s_Page_095.tif
b296617501eef58c355b49db113d1874
aa5d197c443980d6a9fc73750b3556e80d06886f
F20101206_AACHER degwekar_s_Page_078.tif
3f8bef28e9153bf063f9c022ac40f946
2af9aff8c0c21672853c578cf0f82a268f33b9bd
90216 F20101206_AACGZL degwekar_s_Page_054.jp2
8b3c79b119bad73c97cf5c90ce8c1622
589c859bc251cfeb6ef8912f3ee05029634c239f
112560 F20101206_AACGYY degwekar_s_Page_036.jp2
4b7429bae674bc3601f49df103c59d47
b069880549d3b5a14e99adc3b8bab2ffc7b54276
F20101206_AACHFH degwekar_s_Page_097.tif
e95964a81247aefa5b5319b3494baf32
a82d15230a0769674db60f3a71e962e9a37057bb
F20101206_AACHES degwekar_s_Page_079.tif
2f1fae40aaab18a38141d75daa0ee9c3
bf4387dad786e70fc5f4075a7aa7841b0dfbec3a
25862 F20101206_AACGZM degwekar_s_Page_055.jp2
cbd706a62d79386f4fb1e66b142c0874
8add942f81e029033b56770b26a180db4774e259
61196 F20101206_AACGYZ degwekar_s_Page_037.jp2
7715230443df987d06a603f9dd5416f9
0c091260b6e1587850bee1b40536110be0a62fb0
F20101206_AACHFI degwekar_s_Page_098.tif
e7a6f8e387111f0922325a9c74d82a91
ca1766860f7a2f6929c02e6656e7601feabde968
F20101206_AACHET degwekar_s_Page_080.tif
3416df306924ecc4dd9b738ee35b5e5a
cccde5a005110ddf2ea49cfa6a482f1a1501592c
96990 F20101206_AACGZN degwekar_s_Page_056.jp2
a2021963b72800cc0e1bfbe4457f607c
a61b3ee45670f766860f9da2a5d079c5de45a9e7
F20101206_AACHFJ degwekar_s_Page_099.tif
ae53cabf734d4eec2fe92bb44100f15a
eebfcc628c700dfdc45fd4df24f39f0c0a8e244c
F20101206_AACHEU degwekar_s_Page_081.tif
fdfabe03df93f2a876e6649a8ff32402
c1cde6f09d38b4c8b47665e74eec09af5a40b90b
86268 F20101206_AACGZO degwekar_s_Page_058.jp2
8691dafe2cff6de9d791ae9445a80541
9e152ba826e4c984b1f4403075bc0deaa62ea08d
F20101206_AACHFK degwekar_s_Page_100.tif
a75a73c5664bf32154d9bd1517f2f5ea
8019a7b95ff591f8682bb50e30f14b3f1f6dae21
F20101206_AACHEV degwekar_s_Page_083.tif
9fc72e41111eca0670a85b1bd2319e8c
2c544a8b190e63f6c8dbe0fdd26c750392831c25
90111 F20101206_AACGZP degwekar_s_Page_059.jp2
616f4e680f2fe3c2bb6550166e27251e
86b0cf84025c8212a80bc997585515a70904b3bb
F20101206_AACHEW degwekar_s_Page_084.tif
4a501b26320c5a3fe0340e0dd1865196
b481885c3b4bbb1a12add29b5bc8e83e91f191c3
93520 F20101206_AACGZQ degwekar_s_Page_060.jp2
535bfeec66fab76ec804c01d7f7f75ed
be66ceaae4ec59625aae18b20e36348c3a6e2e50
F20101206_AACHFL degwekar_s_Page_101.tif
786a043aa467449ce404221cf13d2f6f
90bd0e223bdbf5e59a1718372f14165051d733e9
F20101206_AACHEX degwekar_s_Page_085.tif
d06e256f7a45437d3b867f23a2ffc644
443f161693c5872ccebd510c452e613fd47c3ab0
113043 F20101206_AACGZR degwekar_s_Page_061.jp2
f5dc44620d8181de34c89177ea06d483
0c023632056de766b87094818fb397c6f6948a7a
F20101206_AACHGA degwekar_s_Page_120.tif
acd2291b65da9febc235fbe9fa722ce3
f77e24e24d1a4c74ba32c494d017f6205e8b44ed
F20101206_AACHFM degwekar_s_Page_102.tif
1e05083717b29ed816d24601bb7dca0a
73310507b3313ec46015570f76f6fd88947e30e1
F20101206_AACHEY degwekar_s_Page_086.tif
f09b002f940aed5ff390944aba15296e
43e198cc046671674350ba8343eb6c1fe13de0e8
56413 F20101206_AACGZS degwekar_s_Page_062.jp2
0285723d4b3d905c7f0d19c729753431
5735c2b393a151b6d8e52ac0edabec4930353f48
F20101206_AACHGB degwekar_s_Page_121.tif
5576ff1ef057c258ccfc9bded353d073
b4b2307e76de68d09f3e1929f4e323d898470fe2
F20101206_AACHFN degwekar_s_Page_103.tif
3125e8929fddb2afef0db08b88340eed
93f10495ffe350c1e2e3af83eec1f1f607fdff36
F20101206_AACHEZ degwekar_s_Page_088.tif
b35a3d798e742e7c0576a64a9b9d542d
24f094899e907ec8dbe1b04473bb5f715261aaea
113972 F20101206_AACGZT degwekar_s_Page_064.jp2
ecfcae4c5f44fe625caf3bcb11721ed1
0465212210e8ebc05ad58680b277b3c12559188e
F20101206_AACHGC degwekar_s_Page_122.tif
8b1557fd69f8bd1bb5b1d58d8c50b1fb
54f5ea681804f43f70ade2aed0d9e1e31f88395b