QDATR is an implementation of the DATR formalism developed at the University of Sussex by Roger Evans and Gerald Gazdar.
(Roger Evans & Gerald Gazdar (1989): "Inference in
DATR".
in: Evans/Gazdar: The DATR Papers, School of Cognitive
and Computing Sciences, University of Sussex, Brighton, U.K.)
The system is freely available to universities and
research organizations for instruction purposes.
For specific system commands see the section "Command
Description" at the end of this file. QDATR provides an interpreter for
A DATR theory is a set of equations with a defined syntax and semantics.
In order to work with QDATR you need a DATR theory and some knowledge about
that theory to formulate interpreter queries. There are some sample DATR
theories on the disk with filename extension "DTR" (i.e. "workers.dtr").
To load a DATR theory into the internal database of QDATR you first have
to compile it. This is done with the "cp(Filename)" command. The compiler
transduces DATR code in standard (Sussex) into an internal format. The
latter, so-called Duesseldorf syntax, is Prolog-based and represents each
DATR sentence as a Prolog term. Now QDATR is ready for your queries to
the specific DATR theory. The system provides the commands "Node:Path",
"Node", "Path" and "datr_theorem" to formulate queries. Try the example
session described in the following section.
Input at the QDATR Interpreter Prompt
QDATR is written in Sicstus Prolog. All inputs have either the form of QDATR commands or of expressions in standard (Sussex) DATR notation, which are interpreted as queries to the DATR interpreter. The QDATR commands look like Prolog predicates (it is possible although not necessary to use a fullstop after a command). Those allowed by the command line parser and interpreter are listed and explained below. Expressions in Sussex DATR notation which are allowed at the user prompt are:
Example session: | Input Type: |
>> cp(workers)
>> Blue_collar1 >> Blue_collar1:<night rate> >> datr_theorem >> traceon >> Blue_collar1:<night rate> >> quit |
QDATR command
node node:path QDATR command QDATR command node:path QDATR command |
tracing/debugging options: | Command Description: |
l
n a ?, h, help any_other_key* |
leap (until next spypoint)
nonstop abort evaluation display this option table go on in tracing mode |
Spypoints can be removed with "nospy(Node)" or "nospyall".
The current spypoints are displayed with "spypoints". If the interpreter
trace and debugger are switched off a fast version of the interpreter is
used.
Since QDATR does not depend on Arity/Prolog anymore, there
should no longer be the typical problems with stack overflow errors (but
we have no experience with smaller machines so far). To avoid having to
kill QDATR if your DATR theory contains an endless loop, the maximum number
of inferences can be specified as before. The default value of this limit
is 1000, but you may change it to another value N with the "inferences(N)"
predicate (i.e. inferences(10000)). If the limit is reached for a specific
node-path combination, you will receive "! stack overflow error !" as a
message. In this case you can increase the inference limit. You must experiment
with different settings because the best value depends on your DATR theory,
but it is better to receive "! stack overflow error !" than to have to
kill QDATR.
>> help | Gives some hints how to get help. |
>> info | Displays the most important command descriptions on the main screen. |
>> options | Displays the option-switch descriptions and current settings on the main screen. |
>> switches | Displays current settings of switches but, unlike "options", without descriptions. |
>> readme | Displays this document. |
>> quit (or 'bye' or 'halt' or 'stop') | Exits QDATR. To return to the Unix prompt you may have to kill the editor. |
>> cp(Filename)
Example calls:
>> cp('workers.dtr')
|
Loads a DATR theory from a file into the internal database.
The file must contain DATR code in standard notation. The example files
provided with QDATR with extension ".dtr" (i.e. "workers.dtr") all contain
DATR theories. If no file extension is specified, the extension ".dtr"
is added by default. If you want to process a file without an extension,
you have to terminate the filename with a period (i.e. "cp(file)"). Previously
loaded DATR theories will be overwritten.
The compiler writes the internal notation to a file "internal.tmp", which is loaded at the end of the compilation process. If you want to take a look at this internal notation, see "internal.tmp". |
>> c(Filename) | You can use "c" instead of "cp" for all compile commands if you don´t want to confuse it with the Unix copy command. |
>> cp([File1,...,FileN])
>> c([File1,...,FileN]) |
Loads the DATR theories specified in the list. As noted above, you should make sure that files containing atom or node declarations relevant to other files are compiled first, i.e. appear at the beginning of the file list. |
>> cp(InFile, OutFile)
>> c(InFile, OutFile) Example call:
|
Compiles a file "InFile" in standard notation and writes
the internal QDATR format to a file "OutFile".
The DATR theory is NOT loaded into the internal database, the internal notation is NOT written at "internal.tmp". |
>> cp
>> c |
Repeats the last compile command. |
>> dump(File.dtr) | Compiles 'File.dtr', evalutates datr_theorem and writes output to 'File.dmp'. |
>> cpon | This switch gives you detailed information about each node definition compiled, the number of sentences it contains, and its line numbers. |
>> cpoff | Switches the detailed compiler information off (default setting). Only the number of node definitions and declarations will be displayed. |
>> Node:Path | Evaluates the specified Node:Path pair using the seven DATR inference rules. If the query is evaluable, you get exactly one value back. |
>> Node | Pairs the specified node with all paths which are declared with 'show' in the current DATR theory and tries to evaluate each Node:Path pair. |
>> Path | Pairs the specified path with all nodes which are not declared with 'hide' in the current DATR theory and tries to evaluate each Node:Path pair. |
>> datr_theorem
>> dt |
Combines all non-hidden nodes with all paths which are
declared with 'show' in the current DATR theory and tries to evaluate each
Node:Path pair created in this way. The "hide" declaration has the following
format:
# hide Node1 Node2 Node3 ... NodeN. If there is no "hide" declaration, all Nodes are evaluated with all paths that are declared with "show". If there is no "show" declaration, nothing is evaluated. The 'hide' declaration is useful for excluding nodes from explicit evaluation which only serve as intermediate nodes. |
>> r | Repeat last query. |
>> traceon | Switches the DATR interpreter trace on. You get information about the application of every inference rule and thus about each step in the evaluation of a Node:Path pair. The amount of information you receive on the display is usually large, depending on the number of inheritance steps during the evaluation. If sequences and evaluable paths are used extensively, this number grows very fast. |
>> traceoff | Switches the DATR interpreter trace off (default setting). |
>> debugon | Switches the DATR interpreter debugger on. It only stops when a local node with a spypoint placed on it is reached (see above: "The most important changes"). It is useful to enter debug-mode when you are developing large theories. You don´t have to step through the parts of the evaluation you are not interested in. To make use of this mode you have to set spypoints on the relevant nodes first (see below "spy(Node)" ). |
>> debugoff | Switches the DATR interpreter debugger off (default setting). |
>> spy(Node) | Places a spypoint on Node. The spied node is indicated with '+' in the interpreter debugger output. >> nospy(Node) Removes the spypoint from Node. |
>> nospyall | Removes all spypoints. |
>> spypoints | Displays all current spypoints. |
>> inconson | Finds possible inconsistencies resulting from the use of variables in LHS- Paths (see above: "The most important changes"). |
>> inconsoff | Switches the inconsistency check off (the default setting). |
>> queryon | The Node:Path combination of the query is displayed together with simple equations before the evaluated value, i.e. each theorem is a complete extentional sentence (the default setting). |
>> queryoff | Only the evaluated value is displayed. This can be useful if you want to write the output of a DATR theory to a file (with "tell(File)", see below), and then use this file as the input to another program. |
>> shorton | Switches the DATR interpreter trace into short mode. Only local environments and matching axioms are displayed. |
>> shortoff | Switches the DATR interpreter trace into full mode (default setting). |
>> paron | Switches the display of sequence parentheses in the theorem output on. |
>> paroff | Switches the display of sequence parentheses in the theorem output off (default setting). |
>> inferences(N) | Sets the limit of inference depth for the evaluation of a specific Node:Path pair. The default value for N is 2000. You can experiment with this value, but if you get memory problems you should reduce it. |
>> inferenceson | Displays the number of inference steps needed for the evaluation of a specific Node:Path pair. |
>> inferencesoff | Switches the inferences display off (the default setting). |
>> list | Lists all definitions of all nodes of the currently loaded DATR theory. |
>> list(Node)
Example:
|
Lists all definitions of the specified node as they appear
in the currently loaded DATR theory.
|
>> list(NodeList)
Example:
|
Lists all definitions of the specified nodes in NodeList
as they appear in the currently loaded DATR theory.
|
>> list(hide) | Lists all nodes in hide declarations. |
>> list(show) | Lists all paths in show declarations. |
>> list(atom) | Lists all declared atoms. |
>> list(node) | Lists all declared nodes. |
>> list(nc) | Lists node conversion declarations (see below). |
>> list(qnode) | Lists qnode declaration (see below "External global inheritance"). |
>> list(qpath) | Lists qpath conversion declaration (see below "External global inheritance"). |
>> clear_db | Deletes the contents of the current internal database. |
>> tell(File) | Redirects the theorem and tracing output from user screen to File. The interpreter debugger is turned into stepoff-mode. This does not affect other the user messages, e.g. listings continue to appear on the user screen. |
>> told | Redirects output to user screen and turns the interpreter debugger into stepon mode. |
>> version | Displays the number of the QDATR version and the date of the last compilation. Additionally, the Prolog version your QDATR is based on is displayed. |
>> stat | Displays statistics on system resources. |
>> flags | Displays the setting of Prolog flags. |
>> line_length(N) | Sets the line length of the theorems displayed on the user screen to N. This is especially useful in combination with datr_theorem. The default setting is 80. |
>> r (or "rpt" or "repeat)" | Repeats the last query (but not the last QDATR command). This can be quite useful e.g. if you just change a switch and then want to repeat the query without retyping it. |
>> backon | Activate backtracking option. |
>> backoff | Turn backtracking option off. |
The Node Conversion Declaration
Syntax:
# nc {seq} {Format:} Path. (constituents enclosed in
{} are optional)
Semantics:
The path Path is implicitly defined for all nodes in
the current DATR theory. The value of the thus constructed axiom depends
on the context in which the path Path occurs. If you use Path in your DATR
theory as a value descriptor with local inheritance, the path Path evaluates
to the name of the node in the local context as an atom or a sequence of
the format Format. Correspondingly, if you use it with global inheritance,
it evaluates to the name of the node in global context. Valid formes of
"Format:" are:
Node:
(first character capitalized)
NODE: (all
characters capitalized)
node:
(no characters capitalized)
If you don't use a format parameter, the atomic name of the node will have the same orthography as the node itself. The parameter "seq" as a prefix of the "{Format:} Path" expression will convert a single atom into a sequence of characters. The path Path is freely definable.
Example theory:
# nc <nodename>.
# nc Node:<node name>.
# nc NODE:<nn>
# nc node:<@>.
# nc seq <name of node>.
# nc seq node:<>.
NodE1:
<1> == <nodename>.
<2> == <node name>.
<3> == <nn>.
<4> == <@>
<5> == <name of node>.
<6> == Node2.
Node2: <> == "<>".
From the above theory you get the following theorems of NodE1:
NodE1: <1> = NodE1.
NodE1: <2> = Node1.
NodE1: <3> = NODE1.
NodE1: <4> = node1.
NodE1: <5> = N o d E 1.
NodE1: <6> = n o d e 2.
Search Paths for '*.dtr' Files:
A file "customs.pl" can be used to define search paths
for QDATR. The ordering is as follows: first, QDATR searches in the current
directory for a file called with the compile command "c(file)". If it cannot
be found the first defined path is used as a search path, then the second
and so on. The syntax of this definitions can be seen in the example file
contained in
this distribution (they are ordinary Prolog predicates).
Just change the examples given in "customs.pl".
'Switch' Declaration:
It is possible to specify in a file which switches should
be set when the file is compiled, e.g.:
# switch: cpoff inconson.
]
Backtracking Interpreter:
Use the backon/backoff command to experiment with non-functional
DATR theories like the following:
A: <> == a
<> == b.
When the 'backon' switch is set the compiler won't complain
about functionality violations. After the first result has been displayed
the interpreter will ask if you want more solutions.
This section will contain recently added changes to the
QDATR distribution, starting with QDATR version 4.0:
Syntax | Expression Type | Description | Limitations | QDATR version |
# uses Node1 .... NodeN.
|
Declaration | Imports additional node definitions from a library, including the possibility to rename them | Only Syntax implemented, no functionality until now. | 4.0 |
>> dump(File) | QDATR Command | Compiles 'File.dtr', evalutates datr_theorem and writes output to 'File.dmp'. | not known | 4.0 |
Sebastian Varges
Last Modified: Sebastian Varges,
02/09/1998.