1

Features as Constraints

Rafael Accorsi Univ. FreiburgCarlos Areces Univ. AmsterdamWiet Bouma KPN ResearchMaarten de Rijke Univ. Amsterdam

2

Overview of talk

Background & motivation Non-monotonicity & constraint programming Stable model semantics, Smodels Using Smodels Evaluation Discussion

3

Background & motivation

Wanted: User-oriented view of FI: encoding of behavior graphs Systematic approach to non-monotonicity

Try to avoid complications with model-oriented approaches like modelling IN-CSn in LOTOS, SDL or

Process Algebra Co-operation with UvA since 1999

Description Logic and Constraint Programming Work on DL appeared independently in:

Proceedings MASCOTS’99, October 1999,IEEE Computer Society ISBN 0-7695-0381-0

4

Non-monotonicity & constraint programming

Idea: use constraints as a natural way to model non-monotonicity, or:give semantics to a system by the set of its possible models

Add features by constraining it further. Prune some models, generate new ones non-monotonic additions

Model construction as well as querying can be implemented efficiently

Chose Smodels because of efficient implementation, and its facilities for querying

5

Stable model semantics, Smodels

Standard logic programming semantics:

where are atomic properties (predicates) Clean semantics, but …

no negation possible Stable model semantics elegant way to model negation:

if are in the model, and are not,

then A should be included.

Such models should be minimal (as in the classic case)

.,,1 nBBA nBBA ,...,, 1

..,,,,, 11 mn CnotCnotBBA nBB ,,1 mCC ,,1

6

Stable model semantics, Smodels -2-

A program can have 0, 1 or many stable models Provided we

don’t use functions,

and look only at domain-restricted programs,

there are efficient procedures for finding stable models of a logic

program Smodels is an implementation of these procedures with attractive

extra features Connection to non-monotonic reasoning is obvious The compute statement enables to search for a specified number

of models that include/exclude specified atomic predicates

7

Stable model semantics, Smodels -3-

Model behavior graphs (Transition Systems) in such a way that the stable models correspond to the valid runs of the system is modeled as:

S

S2

S1A1

A2

.,,: 21 SAAfalse

.,: 11 SAS .,: 22 SAS

.,:

.,:

12

21

SAnotA

SAnotA

8

Using Smodels

Need some refinements to encode subscribers, cycles and runs

Need new atoms to record state changes for other users Use constraints on the dial action to prune unwanted

behavior, like A subscriber can only establish one call in a given cycle

9

Using Smodels -2-

Testing the BCS:1. Generate all models, i.e. all valid runs for all subscribers.

Current limit is 4 subscribers, 3 cycles (not included).Example: 3 subscribers, 3 runs gives ~18M models, and takes plm. 14hrs, 45 minutes

2. Ask queries by looking for (a number of) models with specific properties. Examples: Two independent calls can be set up in a given cycle.

compute 1 {path(s1, t1, s2,t1), path(s3,t1,s4,t1)}Plm. 15 minutes execution time

In 3 cycles, a user can establish 3 different calls.compute 1 {path(s1,1,_,_),

path(s1,2,_,_),path(s3,3,_,_)}Plm. 11 minutes execution time

10

Using Smodels -3-

Add features by adding constraints that prune the set of models, and enlarge it by adding new atoms

Simple methodology for adding features:1. Define behavior2. Identify how the feature explicitly modifies the behavior of BCS3. Check properties on the featured system

11

Using Smodels -4-

TCS

CFU

+ axioms that refine BCS. Needed because a naive implementation loses models that one wants to keep.

),,,,(:),( TMEUSHEdialUSHErejecting ).(),(),,( TcycleUcycleSHEMEtcs

).(),(),,(),,,,(: TcycleUcycleSHEMEtcsTMEUSHEcallingfalse

).(),(),(

),,(),,,,(:

TcycleUcycleSHEsubs

OTHERMEcfuTMEUSHEcallingfalse

12

Evaluation

Features can be added without changing code for BCS or other features

Checking properties on the featured BCS discovers interaction, because no valid runs are left for a specific configuration (modeled by a compute statement)

This way we show the existence of suspected interactions

So, have to write a sufficient set of properties in advance for each feature, or discover suspeced interactions by aqnother technique, e.g. model checking

13

Discussion

Main aim: use stable model semantics as a means to model non-monotonicity. Proof of concept has been delivered

Advantage: used standard notions, methods and tools form the field of computational logic. So, a connection between Knowledge Engineering and FI has been made

Other implementations of stable model semantics like DeRes or XSB should be tested

A LOT more work has to be done