2004-09-27, 18:00 Lisbon time, just after the regular JELIA'04 sessions
Panelists:
José Júlio Alferes (Universidade Nova de Lisboa, Portugal),
Nicola Leone (Università della Calabria, Italy, WASP member),
Torsten Schaub (Universität Potsdam, Germany, WASP member),
Ken Satoh (National Institute of Informatics, Japan),
Yannis Dimopoulos (University of Cyprus, Cyprus, WASP member),
Tomi Janhunen (Helsinki University of Technology, Finland, WASP member)
Organizers:
Gerhard Brewka (Universität Leipzig, Germany, WASP member),
Jürgen Dix (Technische Universität Clausthal, Germany, WASP member),
Thomas Eiter (Technische Universität Wien, Austria, WASP member)
Audience: about 50
Jürgen Dix introduces the panel, WASP, the purpose of the panel, and
introduces the panelists. He then lists the questions posed to the
panelists:
Q1: Killer Applications for ASP (should one care about?)
Q2: For which application areas is ASP well-suited, for which it is
unsuitable?
Q3: In which ways should ASP be used?
Q4: What is the advantage of ASP over other approaches (e.g. LP
techniques) for applications?
Q5: Which language extensions and features of ASP are missing to make
it useful for practical applications?
(Q6: Is it a hype that will soon be over?) [not on the slide, but was
originally posed to the panelists]
The panelists then elaborate on these questions.
J.J. Alferes:
Q1: People should care about killer applications. ASP is already
application-oriented, therefore a killer application is needed.
Q2: ASP is used for several application areas, for which it is
well-suited, while it is sometimes also used in areas where constraint
solvers (CLP) are better suited (e.g. the 8-queens problem).
Q3: ASP should be used in conjunction with other systems
(e.g. smodels+XSB, DLV+DB, etc.) for full applications. Important
issue: Localization (magic sets, reducts etc).
Q5: Debugging, visualisation. In general: Programming tools. E.g. demo
by Thomas Linke on the same day. This is a difficult, but important task.
Q6: I don't hope so.
N. Leone:
Q1: Very tough question. Agrees with J.J. Alferes to some extent: One
should definitely care about killer applications. But is there a
single killer application?
Q2: Connected to Q1. Agrees with J.J. Alferes that often ASP is used
improperly. But there are many areas where it is well-suited: Complex
knowledge, incomplete knowledge and reason about it.
One concrete case is the data integration setting presented in the
systems track: Interaction with a database is needed, "evolution" of a
data has to be considered, reasoning by cases and solving a co-NP task
is needed (so well-founded semantics is not appropriate), query
answering is fundamental. Magic Set techniques make this task practical.
Another application area is reasoning about ontologies. Query
answering over huge and complex amounts of data is necessary there.
Yet another area is the classification of documents (as presented in
the system session before the panel), where constraint satisfaction is
definitely not appropriate (since there is no query).
Q3: ASP should usually be used by knowledge engineers and be
encapsulated in a "computational kernel". Frontends should be built
around this kernel in order to grant non-expert users easier access.
Q5: Agrees with J.J. Alferes. The need for debugging tools is
emphasized. Other minor issues are raised (e.g., real numbers).
T. Schaub
Q1: One should care about applications. If they are killer, that's
fine. Candidates: Gelfond etal's work for the Space Shuttle. Baral
etal's work in Bioinformatics. This is the way to go: Try to move to
the application areas in other communities. The "Guess and Check"
Paradigm can often be fruitfully applied there.
N-queens is useful for teaching. Emphasis on visualizations: E.g.,
Sokoban, Quake (as presented by Provetti in the system session before
the panel). Wrappers exist around ASP for visualization.
Q3: 2 directions: "general high-level language" vs. "assembler
language" (like SAT). The latter is used for encoding other
formalisms.
Q4: Shift from query oriented (Automated Theorem Proving view) to
model oriented (Knowledge Representation/SAT view). Working on models
is yet to be explored.
Q5: The "assembler language" direction gives rise to language
extensions. E.g., model checking, Linux configuration (both of HUT).
Q6: ASP is necessary. If it does not stay, it will be re-invented.
K. Satoh
General view of ASP:
Declarative and concise specifications, but no (explicit) control:
pro: people not wanting a search algorithm are happy
con: no direct influence
Programming is different than for standard logic programming, but
somewhat similar to linear/integer programming.
Q1: Therefore a candidate for a killer application could be from the
area of linear/integer programming, where modelling using numbers is
hard.
Q2: Not suitable for interactive systems.
Q3: Use as a batch system, combined with standard (procedural)
languages. E.g., Quake as in the presentation by Provetti.
Q5: Missing: declarative control mechanism, combination methods with
procedural methods.
Q6: Work hard!
Y. Dimopoulos
View: ASP is a CLP language: LP with SAT and minimality.
Competitors are identified as SAT and constraint programming.
Weak points: Debuggers and programming tools.
Exploit the relation to deductive databases and to inductive logic
programming (e.g., bioinformatics).
Q1: All applications where minimality is important.
Agrreement with previous panelists that 8-queens is not well-suited as
ASP application, because there is no minimality involved.
A bad point is that an "LP language" is not learned understood by many
people. In contrast, CP networks are easy to understand with "standard
education".
T. Janhunen
Q1+Q2: Configuration. Issues are that specification is not always
clear. Therefore revising the KR language is often necessary.
Chemical engineering, chromatography. Problems: Inexact definitions,
errors in the data.
Q3: Programmers often do not know how to characterize the
solutions. ASP seems to be suitable for "trial and error" approaches.
Q4: Compared to Prolog, ASP is more efficient and truly
declarative. Mathematical definitions exist.
Q5: Modularity is needed, e.g. subprograms, aggregates, and other
abstract features. Software Engineering techniques and tools are
needed. Combination with randomized computations (e.g., random
assignments for student exercises) is desirable.
Q6: Engineers are already trained to use ASP, so chances are low that
ASP is just a hype which will disappear soon. So the current state is
promising.
J. Dix thanks panelists and opens the discussion.
L.M. Pereira:
Shares views with J.J. Alferes. ASP should be integrated into
"standard" LP systems to get the best out of the two worlds.
Mentions problems with infinite grounding.
Interpreters are missing and problematic to produce. Top-down is not
feasible for ASP.
For abduction there is the problem that it is usually encoded in ASP
as an even loop, therefore relevance is not guaranteed. Magic Sets can
be used, but only to a certain degree.
Problem with odd loops, especially with respect to updates. Proposes
an alternative semantics termed 'revised stable models'.
M. Cadoli:
Three important features of Ilog solvers:
1. Not rule-based.
2. Rich syntax.
3. Declarative way to express procedural aspects.
Even with this, people are reluctant to buy these solvers.
Along these features, ASP needs to:
1. Hide rules.
2. Enrich the syntax.
3. Provide a declarative way to "guide" search.
Y. Dimopoulos (response to Pereira):
Why shift from "top-down" (goal-oriented, resolution) to "bottom-up"
(model-oriented, Davis-Putnam)? The answer is efficiency.
The Well-founded semantics is not sufficiently expressive.
F. Banti:
In Artificial Intelligence: How to build agents?
ASP has something to say here.
ASP as tool for agent. ASP is not suitable for everything in an agent,
though. E.g. functions.
Therefore one should aim at integrating ASP and goal-oriented approaches.
J. Dix closes the panel.
Protocol by: Stefan Woltran and Wolfgang Faber (Technische Universität
Wien, Austria, WASP members)