This is the hompage of the freely available DATR implementation of the University of Duesseldorf.
 

Features

Overview

 

QDATR Manual version 4.0

 Introduction

QDATR is an implementation of the DATR  formalism developed at the University of Sussex by Roger Evans and Gerald Gazdar.

QDATR was written by Petra Barg, James Kilbury, Ingrid Renz, Christof Rumpf and Sebastian Varges at the University of Duesseldorf within the research project "Dynamic Extension of the Lexicon (Dynalex)" which forms part of the Sonderforschungsbereich 282 "Theorie des Lexikons".
 

The system is freely available to universities and research organizations for instruction purposes.
 
 




Installation: What to do with the downloaded file?
 v
 




Working with QDATR (informal summary)
 

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
 
 




Debugging DATR theories
 
Compiler: Interpreter: Memory Problems: Inference Depth

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.
 



Command Description

Online Help
 
>> 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.
 

Exiting the System
 
>> quit (or 'bye' or 'halt' or 'stop') Exits QDATR. To return to the Unix prompt you may have to kill the editor. 
 

Compiling a DATR Theory
 
>> cp(Filename) 
 
 

Example calls: 
>> cp('qdatr/dtr/workers')  
      [in Unix and in Dos!] 

>> cp('workers.dtr') 
>> cp(workers)  
 

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: 
>> cp('workers.dtr', 'workers.out'). 

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. 
 

DATR Interpreter Commands
 
>> 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).
 

Database
 
>> list Lists all definitions of all nodes of the currently loaded DATR theory. 
>> list(Node) 

Example:  
>> list(Blue_collar1) 

Lists all definitions of the specified node as they appear in the currently loaded DATR theory. 
 
 
>> list(NodeList)  

Example:  
>> list([Blue_collar1,Blue_collar2]) 

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. 
 

Miscellanous Commands
 
>> 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.
 
 




Nonstandard QDATR extensions to the DATR language

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.
 




User Customization

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.
 ]

 



Experimental Features

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.
 




Implementation History

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
 



Known Bugs and Limitations  


Downloading QDATR

 


DATR links



Contact

We are interested in any kind of feedback. Please send comments and bug reports to:

Sebastian Varges
 
 
 
 


Last Modified:    Sebastian Varges, 02/09/1998.