system option group contains options that have a special status, because they control the overall system. These options can only have one value each. For instance, you cannot specify more than one option file. ]]> option file. The option_file option can be used to specify the path to this option file. ]]> Path to option file Show options Apache log4j logging services. To find out more about the different levels please consult the Apache log4j documentation. The default verbosity level is info, which means that all error, warning and informational messages are displayed. ]]> Verbosity level Logging turned off Logging of very severe error events Logging of error events Logging of harmful situations Logging of informational messages Logging of debugging messages config option group contains general options for a configuration.]]> .mco. The name is your own choice, but it is appropriate to give the configuration a name that reflects the content. This option must always be specified, except when the url option is used instead of name. ]]> Configuration name URL to the configuration file instead of specifying the configuration name. For example, if you have a configuration file with the following URL: http://maltparser.org/mco/test.mco you can write -u http://maltparser.org/mco/test.mco.]]> URL to configuration file Flow chart Learn a Single MaltParser configuration Parse with a Single MaltParser configuration Prints the info file of a configuration Unpacks a configuration Simple format converter Projectivizes input data using a configuration Deprojectivizes input data using a configuration Same as learn, but also outputs the graphs to file specified by the flag -o Generates test instances to run experiments with a learner outside MaltParser. Use for example the flag -li true to save instances. singlemalt. Later releases may contain additional configuration types. For example, one type could be an ensemble parser configuration containing many single malt configurations. ]]> Configuration type Single Malt Parser configuration workingdir option. ]]> Working directory system-verbosity option, the logging option controls the level of verbosity of an individual configuration. The different verbosity or logging levels are the same as for the system-verbosity option. ]]> Configuration logging level Logging turned off Logging of very severe error events Logging of error events Logging of harmful situations Logging of informational messages Logging of debugging messages standard output stream, but it is possible to direct this output stream to a logging file by specifying the logfile option. ]]> Log file name (default: standard output) singlemalt option group is used when the singlemalt configuration type is specified. ]]> Single Malt Parser Configuration mode nivre, for controlling the behavior of the algorithm, Covington's algorithms have a corresponding option group called covington. For more information about the parsing algorithm see the user guide: Parsing Algorithms.]]> Parsing algorithm Nivre arc-eager Nivre arc-standard Covington non-projective Covington projective Stack projective Stack eager Stack lazy Planar eager 2-Planar eager single. Later releases may contain additional guide model types. ]]> Guide model type Classic guide POSTAG it is possible to differentiate two null-values:

• NO NODE: There exists no corresponding dependency graph node (e.g., because the lookahead extend beyond the end of the string), which means that the feature is really undefined.
• ROOT NODE: The dependency graph node is a root node, which means that it is not possible to extract an input column value (for example, the word form or the part-of-speech).

In addition to the two null value categories for input columns, there is one more for the output columns:

• NO VALUE: The dependency graph node exists and is not the root, but has not yet been assigned a value for the output column requested (e.g., has not been assigned a head and therefore does not have a dependency type).

With this option it is possible to specify the degree of differentiation of null-values.

• none: Excludes all kinds of null-values when extracting the feature vector, this option value is not possible for learning methods that have symbolic feature vector encoding.
• one: Maps all kinds of null values to one symbol.
• rootnode: Distinguishes between NO NODE and ROOT NODE, and the NO VALUE null-value case is mapped to the ROOT NODE null-value for output columns.
• novalue: Distinguishes between NO NODE and ROOT NODE for both input and output columns, and NO VALUE for output columns.

]]> The degree of differentiation of null-values Excludes all types of null values Maps all kinds of null values to one symbol Distinguish between no node and root node Distinguish between no node and root node, and no value for output column true ,then diagnostics is written to standard out or the file specified by option diafile. By default this option is false. ]]> diagnostics standard output stream, but it is possible to direct this output stream to a diagnostics file by specifying the diafile option. ]]> Diagnostics file name (default: standard output) true, then partial trees are allowed as input and the parser will construct these partial trees before parsing. By default this option is false. Please see the user guide: Partial trees ]]> Use partial trees during parsing propagation option is used for specifying the propagation specification file, which is an XML file (see user guide: Propagation) ]]> Propagation specification file input option group contains options that control the input data. In MaltParser @version@, the values of options in the input option group must match the values of corresponding options in the output option group. This restriction is likely to be removed in later releases. ]]> infile option. It is important that the input data file is formatted according to the format specified by the format option. For example, if format=conllx the input file should at least contain eight columns during learning and six column during parsing. ]]> Path to input file Input and output format. There are two data format specification files in the MaltParser distribution (included in maltparser-@version@.jar):

• conllx defines the CoNLL-X shared task format
• conllu defines the CoNLL-U format
• malttab defines the Malt-TAB format.

]]> Path to format specification file CoNLL-X data format CoNLL-U data format MaltTAB data format

tab reads tab-separated files and with columns defined by the input format.

]]> Data reader Tab-separated reader charset option defines the character set of the input data file, for example, UTF-8 or ISO8858-1. ]]> Character set Specific reader options Number of iterations. output option group contains options that control the output data. In MaltParser @version@, the values of options in the output option group must match the values of corresponding options in the input option group. This restriction is likely to be removed in later releases. ]]> outfile option. ]]> Path to output file Define your own input/output format. There are two data format specification files in the MaltParser distribution (included in maltparser-@version@.jar):

• conllx defines the CoNLL-X shared task format
• conllu defines the CoNLL-U format
• malttab defines the Malt-TAB format.

]]> Path to format specification file CoNLL-X data format CoNLL-U data format MaltTAB data format

tab writes tab-separated files with columns defined by the input format.

]]> Data writer Tab-separated writer charset option defines the character set of the output data file, for example, UTF-8 or ISO8858-1. ]]> Character set Specific writer options graph option group controls internal data structures, such as the sentence and the dependency graph. ]]> Max sentence length Default label for root dependents Head-finding rules. ]]> An URL or a file name to file that contains a list of head rules nivre option group controls the Nivre arc-eager and Nivre arc-standard parsing algorithms. ]]> allow_root=true, the parser treats the special root node as a token during parsing, allowing root dependents to be attached with a RightArc transition; otherwise root dependents are not attached during parsing. In both cases, unattached tokens are attached to the special root node with the default label after parsing is completed. ]]> Allow root allow_reduce=true, the Reduce transition is permissible even if the node on top of the stack does not have a head. As a result, this node will be attached to the special root node after parsing is completed, which may give rise to non-projective trees. ]]> Allow reduce enforce_tree=true, the parser will use an extended transition system that makes sure that the output parse is a tree by (if necessary) unshifting unattached tokens remaining on the stack after the buffer has been emptied and forcing them to be attached. ]]> Enforce tree constraint multiplanar option group contains options that are common to the multiplanar family of algorithms (planar and 2-planar algorithms). ]]> planar_root_handling option specifies how dependents of the special root node are handled in the planar or 2-planar parser. ]]> Root handling Root dependents not attached during parsing (attached with default label afterwards). Root dependents attached by RightArc transition during parsing (unattached tokens attached with default label afterwards). planar option group controls the Nivre planar parsing algorithm. ]]> connectedness=true, the parser only generates connected dependency graphs. ]]> Enforce connectedness Don't enforce connectedness at all, words whose head the parser doesn't know will be linked to the root node. With this option, the parser will work with planar dependency forests. A forest may be seen as a tree by considering all the roots linked to the dummy root node, but it needn't be planar when seen this way. The last node in a connected component cannot be reduced. No restrictions on shift transitions. This option guarantees that the dependency graph obtained counting links to the dummy root node is planar and connected. Enforce full connectedness by not only not allowing to reduce the last node in a component, but not allowing to shift the last word if the graph is not connected. The produced graph will be connected and planar even without considering the dummy root node. acyclicity=true, the parser only generates acyclic dependency graphs. ]]> Enforce acyclicity covered_roots=true, the parser disallows covered roots (i.e. disallows non-projective structures, while with this option set to false, it allows planar structures that are not projective). ]]> Disallow covered roots 2-planar option group controls the 2-planar parsing algorithm. ]]> reduceonswitch=true, the parser reduces the active stack immediately after switching stacks. ]]> Force reduce after switch allow_root=true, the parser treats the special root node as a token during parsing, allowing root dependents to be attached with a RightArc transition; otherwise root dependents are not attached during parsing. In both cases, unattached tokens are attached to the special root node with the default label after parsing is completed. ]]> Allow root allow_shift=true, Shift is a valid transition, allowing the parser to skip remaining tokens in Left; otherwise all tokens in Left must be inspected before the next token is shifted. ]]> Allow shift transition LIBSVM Documentation). Note that all whitespace is replaced by underscore if this option is specified in the command-line prompt. For example, it could look like this: -lo -s_0_-t_1_-d_2_-g_0.2_-c_1_-r_0_-e_1.0. Liblinear have several options (see liblinear Documentation) that you can specify with this option. Note that all whitespace is replaced by underscore if this option is specified in the command-line prompt. For example, it could look like this: -lo -s_4_-c_0.1 ]]> LIBLINEAR options (see liblinear Documentation) train or svm-train executable file of the liblinear or the libsvm package. ]]> Path to train or svm-train save_instance_files=true, training instance files are saved in the configuration, otherwise these files are deleted. The training instance files are not used during parsing. ]]> If save_instance_files=true, instance files are saved in the configuration. Verbosity of the liblinear or the libsvm package No output from the liblinear or the libsvm package is logged. Only the error stream of the liblinear or the libsvm package is logged. All output of the liblinear or the libsvm package is logged. features option is used for specifying the feature model specification file, which is an XML file (see user guide: Feature model) or a text file with the file suffix .par (see user guide of MaltParser 0.x (C-impl) Feature Models). If no feature specification file is specified, the parser will use a default feature model specification for the given parsing algorithm that is included in the MaltParser distribution (included in the maltparser-@version@.jar file). ]]> Feature model specification Nivre arc-eager default model Nivre arc-standard default model Covington non-projective default model Covington projective default model Stack projective default model Stack projective default model Stack projective default model Planar arc-eager default model 2-Planar arc-eager default model data_split_column, data_split_structure and data_split_threshold options it is possible to define how the guide should split up the training instances to train several models. Note: Usually this will result in a slight drop in accuracy but a significant decrease in learning time. The option data_split_column indicates which input column in the data format specification file should be used for splitting up the training instances, for example, -d POSTAG or -d CPOSTAG. It is not a good idea to use fine-grained features, such as LEMMA or FORM, since this would result in thousands of models. ]]> Data split input column data_split_column, data_split_structure and data_split_threshold options it is possible to define how the guide should split up the training instances to train several models. Note: Usually this will result in a slight drop in accuracy but a significant decrease in learning time. The option data_split_structure specifies the data structure that should be used for splitting up the traning instances. For example, with Nivre's parsing algorithm it is possible to use the top token on the stack (-s Stack[0]) or the next input token (-s Input[0]); for Covington's algorithms it should be either -s Left[0] or -s Right[0]. ]]> Data split data structure data_split_column, data_split_structure and data_split_threshold options it is possible to define how the guide should split up the training instances to train several models. Note: Usually this will result in a slight drop in accuracy but a significant decrease in learning time. The option data_split_threshold specifies the frequency threshold for training a separate model. For example, -T 100 means that all training sets that contain less than 100 instances will be merged into a default training set. ]]> Data split threshold kbest option indicates how many items the k-best list should contain. If -k -1, all possible parser actions are ranked in the k-best list. If -k 1, there is only one prediction in the k-best list. MaltParser @version@ (behavior ≠ malt0.4) only makes use of the k-best list when the parser action is not permissible. Later releases of MaltParser will make use of the k-best list in a more intelligent way. If --malt0.4-behavior=true, this option will be overridden with k=1. ]]> Number of items in k-best list Type of k-best list Only ranked list Learner LIBSVM learner LIBLINEAR learner Prediction strategy.]]> Decision settings classitem_separator should be used in this case. ]]> Class item separator Marking strategy for pseudo-projective transformation No pseudo-projective transformation Projectivizes input data Projectivizes input data with head encoding for labels Projectivizes input data with path encoding for labels Projectivizes input data with head and path encoding for labels Attachment strategy for covered roots No covered root transformation; covered roots treated as any other node No covered root transformation; covered roots ignored in projectivity tests (old implementation of none) Attach covered roots to the left end of the shortest covering arc Attach covered roots to the right end of the shortest covering arc Attach covered roots to the head of the shortest covering arc Lifting order, in case a dependency graph contains multiple non-projective arcs Lift the shortest arcs first (break ties from left to right) Lift the most deeply nested arcs first (break ties from left to right)