\chapter{Other XSB Packages} \label{sec:otherpackages}

Many of the XSB packages are maintained somewhat independently of XSB
and have their own manuals.  For these packages: {\em Flora2}, {\em
XMC}, {\em xsbdoc}, {\em XASP}, and {\em Cold Dead Fish} we provide
summaries; full information can be obtained in the packages
themselves.  In addition, we provide full documentation here for two
of the smaller packages, {\tt slx} and {\tt GAP}.

\section{Summary of {\tt FLORA-2}: Programming with FLORA-2}
\label{package:flora2} 

\input{florablurb}

%===============================================================

\section{Summary of {\tt xmc}: Model-checking with XSB}
\label{package:xmc} 

No documentation yet available.
%===============================================================

\section{Summary of {\tt xsbdoc}: A Documentation System for XSB based
on {\tt lpdoc}}
\label{package:xsbdoc} 

{\tt xsbdoc} is an {\em automatic program documentation generator} for
Tabled (C)LP systems written using XSB.  Its code is based in part on
the Ciao \cite{ciao-man} system's {\em lpdoc} which has been adapted
to generate a reference manual automatically from one or more XSB
source files.  The target format of the documentation can be
Postscript, HTML, PDF, or nicely formatted ASCII text.  {\tt xsbdoc}
can be used to automatically generate a description of full
applications, library modules, README files, etc.  A fundamental
advantage of using {\tt xsbdoc} to document programs is that it is
much easier to maintain a true correspondence between the program and
its documentation, and to identify precisely to what version of the
program a given printed manual corresponds.  Naturally, the {\tt
xsbdoc} manual is generated by {\tt xsbdoc} itself.

The quality of the documentation generated can be greatly enhanced by
including within the program text:

\begin{itemize}

\item {\em assertions} (indicating types, modes, etc. ...) for the
predicates in the program, via the directive {\tt pred/1}; and

\item {\em machine-readable comments} (in the ``literate programming''
style).

\end{itemize}

The assertions and comments included in the source file need to be
written using the forthcoming XSB {\em assertion language}, which
supports most of the features of Ciao's assertion language within a
simple and (hopefully) intuitive syntax.

{\tt xsbdoc} is distributed under the {\em GNU general public
license}.

Unlike {\tt lpdoc}, {\tt xsbdoc} does not use Makefiles, and instead
maintains information about how to generate a document within Prolog
{\em format files}.  As a result, {\tt xsbdoc} can in principle be run
in any environment that supports the underlying software, such as
{\tt XSB}, \LaTeX, {\tt dvips} and so on.  It has been tested on
Linux and Windows running with Cygwin.

%===============================================================

\section{Summary of {\tt XASP}: Answer Set Programming using XSB}
\label{package:xsm} 

The term {\em Answer Set Programming (ASP)} describes a paradigm in
which logic programs are interpreted using the (extended) stable model
semantics.  While the stable model semantics is quite elegant, it has
radical differences from traditional program semantics based on
Prolog.  First, stable model semantics applies only to ground
programs; second stable model semantics is not goal-oriented --
determining whether a stable model is true in a program involves
examing each clause in a program, regardless of whether the goal would
depends on the clause in a traditional evaluation.

Despite (or perhaps because of) these differences, ASP has proven to
be a useful paradigm for solving a variety of combinatorial programs.
Indeed, determining a stable model for a logic program can be seen as
an extension of the NP-complete problem of propositional
satisfiability, so that satisfiability problems that can be naturally
represented as logic programs can be solved using ASP.  

The current generation of ASP systems are very efficient for
determining whether a program has a stable model (analogous to whether
the program, taken as a set of propositional axioms, is satisfiable).
However, ASP systems have somewhat primitive file-based interfaces.
XSB is a natural complement to ASP systems.  Its basis in Prolog
provides a procedural couterpart for ASP, as described in Chapter 5 of
Volume 1 of this manual; and XSB's computation of the Well-founded
semantics has a well-defined relationship to stable model semantics.
Furthermore, deductive-database-like capabilities of XSB allow it to
be an efficient and flexible grounder for many ASP problems.

The XASP package provides various mechanisms that allow tight linkage
of XSB programs to the SModels \cite{smodels:engine} stable model
generator.  The main interface is based on a store of clauses that can
be incrementally asserted or deleted by an XSB program.  Clauses in
this store can make use of all of the cardinality and weight
constraint syntax supported by SModels, in addition to default
negation.  When the user decides that the clauses in a store are a
complete representation of a program whose stable model should be
generated, the clauses are copied into SModels buffers.  Using the
Smodels API, the generator is invoked, and information about any
stable models generated are returned.  This use of XASP is roughly
analagous to building up a constraint store in CLP, and periodically
evaluating that store, but integration with the store is less
transparent in XASP than in CLP.  In XASP, clauses must be explicitly
added to a store and evaluated; furthermore clauses are not removed
from the store upon backtracking, unlike constraints in CLP.

The XNMR interpreter provides a second, somewhat more implicit use of
XASP.  In the XNMR interface a query $Q$ is evaluated as is any other
query in XSB.  However, conditional answers produced for $Q$ and for
its subgoals, upon user request, can be considered as clauses and sent
to SModels for evaluation.  In backtracking through answers for $Q$,
the user backtracks not only through answer substitutions for
variables of $Q$, but also through the stable models produced for the
various bindings. 

The current version of XASP is based on the SModels API.  Other stable
model generators that provide low-level C interfaces may be
incorporated in XASP in the future.

%===============================================================

\comment{
\section{Summary of {\tt CDF}: The ColdDeadFish Ontology Management
System}
\label{package:cdf} 

Logic programming in its various guises, using the well-founded or
stable semantics, can provide a useful mechanism for representing
knowledge, particularly when a program requires default knowledge.
However, many aspects of knowledge can be advantageously represented
as {\em ontologies}.  In our viewpoint ontologies describe various
na\"\i{}ve sets or {\em classes} that are ordered by a subclass ordering,
along with various members of the sets.  Each class $C$ has a {\em
description}.  In the simplest case, a description can consist just of
$C$'s name and a specification of where $C$ lies on the subclass
hierarchy.  In a more elaborate case, $C$ may also be described by
{\em existential relations} that are defined for every element of $C$.
Conversely, $C$ may also be described by {\em schema relations} that
describe the typing of any of $C$'s relations.  For instance, if in a
given ontology, $C$ is the class of {\tt people} it may be described
as a subclass of {\tt animals} (along with other subclasses); an
existential relation {\tt has\_mother} can be defined for elements of
$C$ and whose range is the class of {\tt female\_people}.
Intuitively, this relation indicates that elements of $C$ must have a
mother relation to a female.  $C$ may also be described by the schema
relation {\tt has\_brother} whose range is {\tt male\_people} again
defined for all elements of $C$ but intuitively indicating that $if$
an element of $C$ has a brother, that brother must be male
\footnote{Support for more complex class expressions over the
description logic ${\cal ALCQ}$ is under development.}.  

Because existential and schema relations are defined for all elements
of a class, a simple semantics of inheritance is obtained: an
existential or schema relation defined for $C$ is defined for all
subclasses and all elements of $C$.  Of course relations can be
defined directly on these subclasses, and analgously, {\em attributes}
can be defined on objects of $C$.

Representing knowledge by means of ontologies has several advantages.
First, knowledge obtained from various web taxonomies or ontologies
can be mapped directly into XSB.  Second non-programmers often feel
more comfortable reviewing or updating knowledge defined through
ontologies than they do logic programs.  Knowledge is somewhat
object-oriented; and can be updated by adding or deleting facts that
have a simple and clear set-theoretic semantics.  Such knowledge
management can be aided by GUIs, such as Protoge \cite{protege} or a
special-purpose editor based on InterProlog \cite{interprolog}.

The CDF package has several functions.  First, it compiles ontology
information into a form efficiently accessable and updatable by XSB,
and implements inheritance for various relations.  Many aspects of
semantic consistency of ontology information are checked automatically
by CDF.  Ontology information itself can be speficied either as Prolog
facts using the {\em external format} or as Prolog rules that perhaps
access a database using the {\em external intensional format}.
Persistency of ontology information is handled in various ways, either
using a backing file system via the {\em components} mechanism, or
using the updatable database inteface.

As of 3/03, CDF is under rapid development, and many of its functions
are changing.  However, it has been used in several large commercial
projects so that its core functionality is stable and robust.
Accordingly, in the manual, modules subject to change are marked as
being under development.
}
%===============================================================

\section{{\tt slx}: Extended Logic Programs under the Well-Founded
Semantics}
\label{package:wfsx} 
%===============================================================

\index{WFSX}
\index{negation!explicit negation}
As explained in the section {\it Using Tabling in XSB}, XSB can
compute normal logic programs according to the well-founded semantics.
In fact, XSB can also compute {\em Extended Logic Programs}, which
contain an operator for explicit negation (written using the symbol
{\tt -} in addition to the negation-by-failure of the well-founded
semantics (\verb|\+| or {\tt not}).  Extended logic programs can be
extremely useful when reasoning about actions, for model-based
diagnosis, and for many other uses \cite{AlPe95}.  The library, {\sf
slx} provides a means to compile programs so that they can be executed
by XSB according to the {\em well-founded semantics with explicit
negation} \cite{ADP95}.  Briefly, WFSX is an extension of the
well-founded semantics to include explicit negation and which is based
on the {\em coherence principle} in which an atom is taken to be
default false if it is proven to be explicitly false, intuitively:
\[
-p \Rightarrow not\ p.
\]

This section is not intended to be a primer on extended logic
programming or on WFSX semantics, but we do provide a few sample
programs to indicate the action of WFSX.  Consider the program
{\small 
\begin{verbatim}
s:- not t.

t:- r.
t.

r:- not r.
\end{verbatim}
}
If the clause {\tt -t} were not present, the atoms {\tt r, t, s} would
all be undefined in WFSX just as they would be in the well-founded
semantics.  However, when the clause {\tt t} is included, {\tt t}
becomes true in the well-founded model, while {\tt s} becomes false.
Next, consider the program
{\small 
\begin{verbatim}
s:- not t.

t:- r.
-t.

r:- not r.
\end{verbatim}
}
In this program, the explicitly false truth value for {\tt t} obtained
by the rule {\tt -t} overrides the undefined truth value for {\tt t}
obtained by the rule {\tt t:- r}.  The WFSX model for this program
will assign the truth value of {\tt t} as false, and that of {\tt s}
as true.  If the above program were contained in the file {\tt
test.P}, an XSB session using {\tt test.P} might look like the
following:
{\small
\begin{verbatim}
              > xsb
              
              | ?- [slx].
              [slx loaded]
            
              yes
              | ?- slx_compile('test.P').
              [Compiling ./tmptest]
              [tmptest compiled, cpu time used: 0.1280 seconds]
              [tmptest loaded]
            
              | ?- s.
              
              yes
              | ?- t.

              no
              | ?- naf t.
              
              yes
              | ?- r.

              no
              | ?- naf r.
              
              no
              | ?- und r.
              
              yes
\end{verbatim}
}
In the above program, the query {\tt ?- t.} did not succeed,  because
{\tt t} is false in WFSX: accordingly the query {\tt naf t} did
succeed, because it is true that t is false via negation-as-failure,
in addition to {\tt t} being false via explicit negation.  Note that
after being processed by the SLX preprocessor, {\tt r} is undefined
but does not succeed, although {\tt und r} will succeed.

We note in passing that programs under WFSX can be paraconsistent.
For instance in the program.

\begin{verbatim}
              p:- q.

              q:- not q.
              -q.
\end{verbatim}

both {\tt p} and {\tt q} will be true {\em and} false in the WFSX
model.  Accordingly, under SLX preprocessing, both {\tt p} and {\tt
naf p} will succeed.

\begin{description}
\ournewitem{slx\_compile(+File)}{slx}
Preprocesses and loads the extended logic program named {\tt File}.
Default negation in {\tt File} must be represented using the operator
{\tt not} rather than using {\tt tnot} or \verb|\+|.  If {\tt L} is an
objective literal (e.g. of the form $A$ or $-A$ where $A$ is an atom),
a query {\tt ?- L} will succeed if {\tt L} is true in the WFSX model,
{\tt naf L} will succeed if {\tt L} is false in the WFSX model, and
{\tt und L} will succeed if {\tt L} is undefined in the WFSX model.
\end{description}


\section{{\tt gap}: Generalized Annotated Programs}
\label{library_utilities:gap} 
\index{Generalized Annotated Programs}

Generalized Annotated Programs (GAPs) \cite{KiSu92} offer a powerful
computational framework for handling paraconsistency and quantitative
information within logic programs.  The tabling of XSB is well-suited
to implementing GAPs, and the gap library provides a meta-interpreter
that has proven robust and efficient enough for a commercial
application in data mining.  The current meta-interpreter is limited
to range-restricted programs.

A description of GAPs along with full documentation for this
meta-interpreter is provided in \cite{Swif99a} (currently also
available at {\tt http://www.cs.sunysb.edu/$\sim$tswift}).  Currently, the
interface to the GAP library is through the following call.

\begin{description}
\ournewitem{meta(?Annotated\_atom)}{gap} 
%
If {\tt Annotated\_atom} is of the form {\tt
Atom:[Lattice\_type,Annotation]} the meta-interpreter computes bindings
for {\tt Atom} and {\tt Annotation} by evaluating the program
according to the definitions provided for {\tt Lattice\_type}.
\end{description}



%%% Local Variables: 
%%% mode: latex
%%% TeX-master: "manual2"
%%% End: 
