Please note: File access for templates must be set in the following manner:The syntax of template definitions and of queries which involve template calls is described in section 9, chapter III. In the current section, you learn how templates are loaded into the TIGERSearch tool, and how to handle error messages concerning templates.
Currently, template definitions have to be 'hard-wired' individually for each corpus. This means that only 'power users' can change the template definitions for a corpus. Or, to put it the other way round: If you want to develop your own template definitions, you need your personal copy of a corpus. Please refer to subsection 4.5, chapter VI to see how a corpus template path, i.e. the directory which holds the template definitions, is associated with a corpus.
Template definitions have to be stored in template files, i.e. files which have the extension .tig (tiger template). The corresponding, automatically created binary code will be stored in files with extension .tgc (tiger template, compiled).
Please note: File access for templates must be set in the following manner:
Users of a corpus which comes with template definitions, need
read access not only to the corpus itself but also to the whole
directory hierarchy below the template path.
Template developers need read and write access to the whole
template directory hierarchy.
Please note: In certain situations,corpus users may get write access error messages wrt. the
template directories. In this case, a person with write access to
the template directory hierarchy should reload the corpus which
produced the error messages in order to have the binary template
files created newly.
Template loading is carried out automatically when a corpus is (re-)loaded (cf. subsection 2.1). For template developers, this means that you have to reload the corpus in order to make changes of the template definitions known to the TIGERSearch tool.
The template definitions which are associated with a corpus are loaded from the given template path in the following order:
depth-first
Files from subdirectories will be loaded before the .tig files in the given directory.
alphabetical order
Subdirectories resp. files are loaded in alphabetical order.
Please note: Based on the above order, only the first template definition for a
template head (template name/arity) will be loaded. All other
definitions for the same template head will be ignored.
For faster processing, templates are translated ('compiled') into Java objects. In order to avoid unnecessary recompilation steps, compiled template code is stored on the hard disk in binary form (files with extension .tgc). The compilation of a template source file filename.tig is triggered automatically during the template loading process, in the following situations:
The compiled file filename.tgc does not exist yet.
The compiled file filename.tgc is older than
source file filename.tig.
The TIGERSearch system has been updated in the meantime, i.e.
the internal data structures of the compiled files are outdated.
The fact that compiled code is written on hard-disk means that file access properties have to be set in an appropriate manner (cf. subsection 6.1).
If there are any template loading problems during the corpus loading process, all error messages are stored for inspection. These messages can be inspected by clicking on the warning symbol in the corpus information tab (cf. also subsection 2.2):
Figure: Inspection of template loading errors
The handling of file access errors has already been explained in subsection 6.1.
If a template call does not match the head of any template definition with respect to template name and number of parameters, an undefined template error message is caused if the template is called. Therefore, you should
verify the template name and the number of argument parameters,
both in the template call and in the corresponding template
definition. Correct the template call according to your template
definitions, or vice versa.
check whether the corresponding template definition has been
compiled properly. If the compilation process has failed for a
template definition, e.g. due to syntax errors or read/write access
errors, obviously, the definition is not available in the
internal template store.
Variable-related error messages, e.g. 'undefined type of variable' or 'variable type clash' will be produced in the following situations:
The type of an argument parameter in a template call cannot be
determined from the context of the template call.
The type of an argument parameter of a template head cannot be
determined from the template body.
An argument parameter of a template call and the corresponding
parameter in a template head have disjoint types.
For example, the type of variable #n5 cannot be derived from the other constraints in the body of the following template definition:
VerbPhrase(#n0) <- #n0:[cat="VP"] > #n1:[pos="VVFIN"] & #n0 > #n2 & #n1.#n2 & arity(#n0,2) & PrepPhrase(#n5) ;
This problem is solved by either correcting the name of the variable, or by inserting the same variable name somewhere else in the graph description, so that the type of the variable becomes clear (node variable vs. feature constraint variable vs. feature value variable).
A cyclic template definition error will be issued if a template definition embeds a call to itself, either directly or indirectly. The error message lists the 'ancestors' of the cyclic call in order to give you a hint how the cycle could have been created. Currently, the ancestors are listed in arbitrary order - which may be somewhat confusing.
Although a file may contain several defining clauses for
the same or for different templates, only the first clause for
each template will be retained.
Workaround: Use the disjunction operator | in order to pack alternative template bodies into a single defining clause.