Unix:
% $MAT_PKG_HOME/bin/MATWorkspaceEngine
Windows native:
> %MAT_PKG_HOME%\bin\MATWorkspaceEngine.cmd
Usage: MATWorkspaceEngine [options] <dir> create ...
MATWorkspaceEngine [options] <dir> import ...
MATWorkspaceEngine [options] <dir> list ...
MATWorkspaceEngine [options] <dir> remove ...
...
Provide the directory and operation followed by --help for more detailed help.
--other_app_dir <dir> |
If present, a directory to
look in to find a MAT task specification. This directory
must contain a task.xml file which describes the task. This
is only necessary if 'MATManagePluginDirs install' has not
been called on the task directory. |
--help |
Prints the core help message
and exits |
MATWorkspaceEngine also makes the common options available.
All workspace operations have fairly consistent syntax; first the
core options, then the workspace directory, then the operation
name, then any operation options, and then the operation
arguments. If the operation is a folder operation, its first
operation argument is the folder name.
The available operations are:
topic |
operation |
folder |
---|---|---|
creation |
create |
(global) |
file management |
import |
(global) |
remove |
(global) |
|
assign |
(global) |
|
open_file
(only when --debug is provided) |
(global) |
|
markgold
(only when --debug is provided) |
core |
|
unmarkgold
(only when --debug is provided) |
core |
|
save
(only when --debug is provided) |
core, reconciliation |
|
inspection |
list |
(global) |
workspace_configuration |
(global) |
|
dump_database |
(global) |
|
logging |
enable_logging |
(global) |
disable_logging |
(global) |
|
rerun_log |
(global) |
|
users |
register_users |
(global) |
list_users |
(global) |
|
add_roles |
(global) |
|
remove_roles |
(global) |
|
automated tagging |
modelbuild |
core |
autotag |
core |
|
experimentation |
list_basename_sets |
(global) |
add_to_basename_set |
(global) |
|
remove_from_basename_set |
(global) |
|
run_experiment |
(global) |
|
reconciliation (not yet enabled) |
configure_reconciliation |
(global) |
submit_to_reconciliation |
core |
|
remove_from_reconciliation |
reconciliation |
|
administration |
force_unlock |
core |
There are also internal operations which are not publicly visible
(release_lock, update_ui_log) and are not accessible via
MATWorkspaceEngine.
We'll review each of these operations in turn.
The create operation creates a workspace. It requires a task and an initial user.
Usage: MATWorkspaceEngine [options] <dir> create [create_options]
Command line option |
Description |
---|---|
--task <task> |
The name of the task to be
associated with this workspace. Required if more than one
task is available. The tasks are the same tasks as those
available to MATEngine. |
--initial_users
<s(,s..)> |
A comma-separated list of
initial registered users. Required. The names of the users
do not need to correspond to login names - they're used as
distinctive mnemonics to distinguish between annotators.
However, using login names may be the least confusing
option. |
--max_old_models |
Number of previous models to
retain after model building. Default is 0. |
--help |
Print the help message and
exit. |
Unix:
% $MAT_PKG_HOME/bin/MATWorkspaceEngine /home/user/myworkspace create --task 'Sentence tagging' --initial_users user1
Windows native:
> %MAT_PKG_HOME%\bin\MATWorkspaceEngine.cmd c:\home\user\myworkspace create --task "Sentence tagging" --initial_users user1
The import operation ingests documents into the workspace. The documents are all converted to MAT JSON format, and are prepared for annotation. Optionally, the documents are assigned to users.
Historically, the import operation could target multiple
folders, but in MAT 2.0, only the core folder is eligible for
import.
Usage: MATWorkspaceEngine [options] <dir> import [import_options] <folder> <file> ...
<folder>: The name of the folder to import documents into.
<file>: The file to import into the folder (can be repeated).
Available folders are:
core: for all files during normal annotation
Command line option |
Description |
---|---|
--strip_suffix <suff> |
Remove this suffix from the
file name when determining the basename for the file in the
workspace. By default, the original file basename is used. |
--encoding <encoding> |
For raw documents, input
encoding. Default is ASCII. All imported raw documents will
be converted to utf-8. |
--file_type <type> |
The file type of the
document. One of the readers.
The default file type is mat-json. |
--mark_gold_standard_reference |
Use this flag for documents
which are gold standard reference documents. |
--workflow <w> |
By default, the workflow used during
import is the one specified in the settings for the import
operation in the <workspace> block in your task.xml
file. Use this flag to overwrite that value. |
--steps <s(,s...)> |
By default, the steps used during
import are the ones specified in the settings for the import
operation in the <workspace> block in your task.xml
file. To overwrite that value, specify a comma-separated
sequence of steps with this option. |
--users <s(,s...)> |
By default, the document
state of a document is inferred from the document itself.
But when the document has been annotated already, the
workspace may not be able to tell what user the annotations
should be attributed to. You can use this flag to fix the
attribution. If the document has been tagged automatically
but not corrected by a human, use MACHINE as your value;
otherwise, use the name of the registered workspace user.
This value will overwrite any attributions that are already
in the document. The import process will usually signal an
error if there are annotated segments which are not
attributed. |
--document_status
<status> |
By default, the document
status of a document is inferred from the document
itself. But when the document has been annotated, the
workspace sometimes can't distinguish between documents
which has been partially annotated, documents which are gold
standard documents (reconciled), and documents which are
simply asserted by a user to be completed (gold). The
default is to judge the document to be incomplete; use this
flag to override that default. If the document is already
explicitly marked as gold or reconciled, this setting will
be ignored (so you can't use it, for instance, to import a
reconciled document as merely gold). |
--assign |
If present, assign the
imported document to the specified user or users in the
--users option. MACHINE is not an eligible target. Ignored
if --document_status is reconciled. |
--add_to_basename_set
<set> |
Add the basenames to a given
basename set.
You might want to do this if, e.g., you were importing
gold-standard documents which you wanted to set aside for
evaluation. |
--help |
Print the help message and exit. |
The reader referenced in the --file_type option may introduce
additional options, which are described here.
Let's say the directory /home/user/myrandomfiles contains the
files first.txt and second.txt, and these are both raw text files
in latin1 encoding. Then:
Unix:
% $MAT_PKG_HOME/bin/MATWorkspaceEngine /home/user/myworkspace import --encoding 'latin1' \
--strip_suffix '.txt' "core" /home/user/myrandomfiles/*
Windows native:
> for %f in ("c:\home\user\myrandomfiles\*") do call %MAT_PKG_HOME%\bin\MATWorkspaceEngine.cmd \
c:\home\user\myworkspace import --encoding "latin1" --strip_suffix ".txt" "core" %f
will import these two files, apply the appropriate steps to
prepare them for annotation, and name them "first" and "second".
(Note that in Windows, you can't do globbing the way you can in
Unix, so you have to use the loop.)
Let's say the directory /home/user/myrandomfiles contains the files first.xml and second.xml, and these are both rich annotated files which user1 has partially hand-annotated and saved in XML inline format. Then:
Unix:
% $MAT_PKG_HOME/bin/MATWorkspaceEngine /home/user/myworkspace import \
--strip_suffix '.xml' --file-type xml-inline --users user1 core /home/user/myrandomfiles/*
Windows native:
> for %f in ("c:\home\user\myrandomfiles\*") do call %MAT_PKG_HOME%\bin\MATWorkspaceEngine.cmd \
c:\home\user\myworkspace import --strip_suffix ".xml" --file-type xml-inline --users user1 core %f
will import these two files, and name them "first" and "second".
Like the previous example, except these documents are completed and you want them to be treated as gold. Then:
Unix:
% $MAT_PKG_HOME/bin/MATWorkspaceEngine /home/user/myworkspace import \
--strip_suffix '.xml' --file-type xml-inline --users user1 core --document_status gold \
home/user/myrandomfiles/*
Windows native:
> for %f in ("c:\home\user\myrandomfiles\*") do call %MAT_PKG_HOME%\bin\MATWorkspaceEngine.cmd \
c:\home\user\myworkspace import --strip_suffix ".xml" --file-type xml-inline \
--users user1 --document_status gold core %f
will import these two files, and name them "first" and "second".
The remove operation removes all copies of the basename from the
workspace. Warning: this
operation will remove all traces of the basenames from the
workspace folders and the database. Do not use it unless you
really want them removed.
Usage: MATWorkspaceEngine [options] <dir> remove <basename> ...
<basename>...: the basename(s) to be removed from the workspace.
Available basenames are: ...
Command line option |
Description |
---|---|
--help |
Print the help message and exit. |
Unix:
% $MAT_PKG_HOME/bin/MATWorkspaceEngine /home/user/myworkspace remove first
Windows native:
> %MAT_PKG_HOME%\bin\MATWorkspaceEngine.cmd c:\home\user\myworkspace remove first
This operation assigns the specified basenames to the specified
users. Each user gets his or her own copy of the document to
annotate. If the document's annotations have been already altered
by a human, the basename cannot be assigned.
Usage: MATWorkspaceEngine [options] <dir> assign [assign_options] <basename>...
<basename>...: the basename(s) to be assigned to the specified users.
Command line option |
Description |
---|---|
--user <users> |
Assign the basename to the
named user or users (comma-separated). Required. |
--help |
Print the help message and exit. |
This operation is available via MATWorkspaceEngine only when
--debug is provided in the core options. This operation is
typically available only to the MAT UI. On the command line, it
locks the document and prints out the transaction ID. When
debugging, you can subsequently edit the document in question by
hand, and then save it.
Usage: MATWorkspaceEngine [options] <dir> open_file [open_options] folder basename
<folder>: the folder to find the file in
<basename>: the basename to open
Available basenames are: ...
Command line option |
Description |
---|---|
--user <users> |
Open the file with a
particular user. Required unless --read_only is present. |
--read_only |
If present, open the document
for reading and don't lock it. Used by the MAT UI; not
particularly useful here. |
--help |
Print the help message and exit. |
This operation is available via MATWorkspaceEngine only when
--debug is provided in the core options. This operation is
typically available only to the MAT UI. This operation marks all
of the "non-gold" segments in a document "human
gold".
Usage: MATWorkspaceEngine [options] <dir> markgold [operation_options] <folder> [ <basename> ... ]
<folder>: The name of the folder to operate on.
<basename>: (optional) The basename or basenames to restrict the operation to.
Supported by folder 'core'.
Command line option |
Description |
---|---|
--user <u> |
Specify a user responsible
for the gold marking. |
--lock_id <s> |
Lock ID for marking gold
(obligatory if document is locked). |
--help |
Print the help message and exit. |
This operation is available via MATWorkspaceEngine only when
--debug is provided in the core options. This operation is
typically available only to the MAT UI. This operation marks all
of the "human gold" or "reconciled" segments in a document "non-gold".
Usage: MATWorkspaceEngine [options] <dir> unmarkgold [operation_options] <folder> [ <basename> ... ]
<folder>: The name of the folder to operate on.
<basename>: (optional) The basename or basenames to restrict the operation to.
Supported by folder 'core'.
Command line option |
Description |
---|---|
--user <u> |
Specify a user for the lock
ID. |
--lock_id <s> |
Lock ID for unmarking gold
(obligatory if document is locked). |
--help |
Print the help message and exit. |
This operation is available via MATWorkspaceEngine only when
--debug is provided in the core options. This operation is
typically available only to the MAT UI. On the command line, it
can be used to update the workspace metadata associated with a
document and release the document lock.
Usage: MATWorkspaceEngine [options] <dir> save [operation_options] <folder> [ <basename> ... ]
<folder>: The name of the folder to operate on.
<basename>: (optional) The basename or basenames to restrict the operation to.
Supported by folders 'core', 'reconciliation'.
Command line option |
Description |
---|---|
--doc <s> |
Document to save, as a JSON
string. Used by the MAT UI; not particularly useful here. |
--lock_id <s> |
The transaction ID with which
this document was opened. |
--release_lock |
Release the lock after save
(if you're done with the document). |
--log <s> |
Log fragment (from UI) to
trigger fine-grained progress monitoring. Only available in
the 'core' folder. |
--log_format <f> |
The format of the log fragment. Only available in the 'core' folder. |
--timestamp <s> |
Millisecond timestamp of log upload from the UI's point of view. Only available in the 'core' folder. |
--next_op <json> |
JSON string describing operation to perform after the save (for UI connectivity, mostly). Only available in the 'core' folder. |
--help |
Print the help message and exit. |
Usage: MATWorkspaceEngine [options] <dir> list ( <folder> ...)
<folder>: (optional) the name of the folder to list the contents of. For certain folders,
extended information will be shown. If no folders are named, all folders will be listed.
Available folders are:
core: for all files during normal annotation
export: for exported files
Your task may make other folders available.
Unix:
% $MAT_PKG_HOME/bin/MATWorkspaceEngine /home/user/myworkspace list "core"
Windows native:
> %MAT_PKG_HOME%\bin\MATWorkspaceEngine.cmd c:\home\user\myworkspace list "core"
This operation describes a number of properties of the workspace.
Most of these properties are capabilities of MAT which are
currently in development, but not yet publicly released. We've
included the infrastructure for supporting these emerging
capabilities in order to ensure that users of MAT will not have to
update their workspaces when these capabilities are released. The
properties reported are:
Usage: MATWorkspaceEngine [options] <dir> workspace_configuration
Command line option |
Description |
---|---|
--help |
Print the help message and exit. |
This operation describes all the tables in the workspace
database. It is a useful debugging tool for the technically
inclined.
Usage: MATWorkspaceEngine [options] <dir> dump_database [<table>...]
<table>: the name of a table to dump. If none are provided, the entire database will be dumped.
See the workspace documentation for a description of the workspace
database.
Command line option |
Description |
---|---|
--help |
Print the help message and exit. |
MAT provides a rich and extensive logging infrastructure
specifically for workspaces. When logging is enabled, MAT
workspace operations log every action and data modification, so
that the activities in the workspace can be rerun from the point
that logging was enabled, exactly as they were originally
performed.
Workspace logging is distinct from UI logging. The MAT UI has the capability of capturing all the user gestures, and save these gestures to a CSV file at the user's request. If workspace logging is enabled, the UI turns on this capability specifically for the current workspace, and uploads the log fragments to the MAT server with every save operation in the "core" folder. The format of this log is identical to the format of the UI logger. Unlike general UI logging, this logging cannot be configured or controlled from the UI. Finally, this logging does not interfere with general UI logging; if you choose to enable UI logging, you'll still get all the user gestures, including those that are captured for workspace logging.
This operation enables logging. The log will be saved in the
_checkpoint subdirectory of the workspace directory.
Usage: MATWorkspaceEngine [options] <dir> enable_logging
Command line option |
Description |
---|---|
--help |
Print the help message and
exit. |
This operation disables logging. If a log is being collected, it
is either moved aside or deleted.
Usage: MATWorkspaceEngine [options] <dir> disable_logging
Command line option |
Description |
---|---|
--remove_log |
By default, logs are moved aside to the first
available _checkpoint_<n> location. If this flag is
provided, the log will be removed instead. |
--help |
Print the help message and
exit. |
This operation allows you to rerun the log. It will use the
_checkpoint/_rerun subdirectory of the workspace directory to
store the rerun state. If you've used the --stop_at option to halt
the rerun before it completes, the next call to rerun_log will
continue from that point, unless you provide the --restart option.
Usage: MATWorkspaceEngine [options] <dir> [rerun_options] rerun_log
Command line option |
Description |
---|---|
--stop_at <ts> |
The log timestamp to stop
immediately before. |
--restart |
If present, go back to the
beginning. |
--verbose |
If present, describe the
state of the workspace at each timestamp. |
--help |
Print the help message and
exit. |
Users in these workspaces are simply labels with which human
annotations are associated. When you set up users for your
workspace, it probably makes the most sense to use the user logins
of the people who will be using the workspace. However, there is
no per-user password authentication, or any formal connection or
dependency between workspace users and your computer user
accounts.
This operation allows you to add registered users to your workspace. Perhaps you want to be able to track the contributions of multiple annotators, or you might want to actually assign documents to multiple annotators and do multiple annotation. You cannot unregister users once they're registered.
Users can have roles, as described here.
Usage: MATWorkspaceEngine [options] <dir> register_users <user>...
<user>: the name of a user to register for the workspace.
Command line option |
Description |
---|---|
--roles <roles> |
Available roles. If omitted,
roles will be
core_annotation,human_vote,crossvalidation_challenge. The
string 'all' adds all roles. Otherwise, a comma-separated
list of roles. Available roles are: core_annotation
human_vote human_decision crossvalidation_challenge |
--help |
Prints the help message and
exits. |
This operation lists the users in a workspace. It is also available as part of the workspace_configuration operation.
Usage: MATWorkspaceEngine [options] <dir> list_users
Command line option |
Description |
---|---|
--no_roles |
Don't show the roles. |
--help |
Prints the help message and
exits. |
The add_roles operation adds roles to existing users.
Usage: MATWorkspaceEngine [options] <dir> add_roles [add_roles_options] <user>...
<user>: the name of a user to update the roles for.
Command line option |
Description |
---|---|
--roles <roles> |
Roles to add. The string
'all' adds all roles. Otherwise, a comma-separated list of
roles. Available roles are: core_annotation human_vote
human_decision crossvalidation_challenge |
--help |
Prints the add_roles help
message and exits. |
The remove_roles operation removes roles from existing users.
Usage: MATWorkspaceEngine [options] <dir> remove_roles [remove_roles_options] <user>...
<user>: the name of a user to update the roles for.
Command line option |
Description |
---|---|
--roles <roles> |
Roles to remove. The string
'all' removes all roles. Otherwise, a comma-separated list
of roles. Available roles are: core_annotation human_vote
human_decision crossvalidation_challenge |
--help |
Prints the remove_roles help
message and exits. |
This operation builds a model which can be used to autotag other documents. Every document segment which is gold or reconciled is used to build this model; segments which are in the process of being corrected or annotated are not used. If there are multiple copies of a document because the document is multiply assigned, all copies will be used (so that document will be overrepresented in the model, and all conflicting annotations will be used as well). You can optionally ask the workspace to autotag documents after the model is built.
Usage: MATWorkspaceEngine [options] <dir> modelbuild [operation_options] <folder> [ <basename> ... ]
<folder>: The name of the folder to operate on.
<basename>: (optional) The basename or basenames to restrict the operation to.
Supported by folder 'core'.
If no basenames are specified, the modelbuild operation will use
all the eligible documents.
Command line option |
Description |
---|---|
--do_autotag |
If present, apply the autotag
operation after the model is constructed. |
--config_name <name> |
If present, use a model
settings configuration other than the default. |
--autotag_basename
<basename> |
If --do_autotag is present, a
single basename to autotag. This option can be repeated. If
neither this option nor --autotagged_basenames is present,
all eligible files will be autotagged. |
--autotag_basenames
<basenames> |
If --do_autotag is present, a
space-separated sequence of basenames to autotag. This
option can be repeated. If neither this option nor
--autotagged_basenam is present, all eligible files will be
autotagged. |
Let's say you want to build a model using all the eligible
documents, and you want to autotag all the eligible documents:
Unix:
% $MAT_PKG_HOME/bin/MATWorkspaceEngine /home/user/myworkspace \
modelbuild --do_autotag "completed"
Windows native:
> %MAT_PKG_HOME%\bin\MATWorkspaceEngine.cmd c:\home\user\myworkspace \
modelbuild --do_autotag "completed"
Usage: MATWorkspaceEngine [options] <dir> autotag [operation_options] <folder> [ <basename> ... ]
<folder>: The name of the folder to operate on.
<basename>: (optional) The basename or basenames to restrict the operation to.
Supported by folder 'core'.
Command line option |
Description |
---|---|
--lock_id <s> |
Lock ID (if document is
locked) |
--help |
Print the help message and exit. |
This operation lists the basename sets and their contents.
Usage: MATWorkspaceEngine [options] <dir> list_basename_sets ( <set_name>... )
<set_name>: the name of a basename set
Command line option |
Description |
---|---|
--help |
Print the help message and exit. |
This operation adds basenames to a given basename set (and implicitly creates the set if necessary).
Usage: MATWorkspaceEngine [options] <dir> add_to_basename_set <set_name> <basename>...
<set_name>: the name of a basename set
<basename>: a known workspace basename
Command line option |
Description |
---|---|
--help |
Print the help message and exit. |
This operation removes basenames from a given basename set (and implicitly removes the set if necessary).
Usage: MATWorkspaceEngine [options] <dir> remove_from_basename_set <set_name> <basename>...
<set_name>: the name of a basename set
<basename>: a workspace basename
Command line option |
Description |
---|---|
--help |
Print the help message and exit. |
This operation allows you to run an experiment based on this
workspace, either using an experiment
file or by specifying the properties of the test set in
terms of properties of the workspace basenames. You can do this
either by specifying an experiment file and an experiment file
variable to which the workspace directory should be bound, or by
specifying the specific properties of the workspace documents to
use as your test corpus. In the latter case, the training corpus
will be the remainder of documents at least partially
hand-annotated documents in the workspace.
If you do not use an experiment file, the defaults provided will
be different than those in the workspace file. The only documents
in the workspace that will be used are those which are at least
partially gold; the model trainer will train only on gold or
reconciled segments; and the scorer will only compare to gold or
reconciled segments in the test corpus. You can override these
restrictions by providing your own experiment file. You can
duplicate these restrictions in your experiment file by:
The experiments will be saved in the experiments/ subdirectory of
the workspace, in a directory named
<year><month><day>_<hr><min><sec>_<msec>.
Usage: MATWorkspaceEngine [options] <dir> run_experiment [options]
Command line option |
Description |
---|---|
--experiment_file
<file> |
Specify an experiment file to use. If specified, --workspace_binding is also required. Either this or one of the --test_* parameters must be provided. |
--workspace_binding
<var> |
A variable in the workspace
experiment file to which this workspace should be bound.
Required if --experiment_file is present. |
--test_users
<user(,user..)> |
A comma-separated sequence of
users to restrict the test corpus to. Not permitted if
--experiment_file is provided. |
--test_basename_sets
<set(,set...)> |
A comma-separated sequence of
basename set names to restrict the test corpus to. Not
permitted if --experiment_file is provided. |
--test_basename_patterns
<pat(,pat...)> |
A comma-separated sequence of
glob-style basename patterns to restrict the test corpus to.
Not permitted if --experiment_file is provided. |
--test_document_statuses
<status(,status...)> |
A comma-separated sequence of
document statuses to restrict the test corpus to. The
background corpus will already be restricted to 'partially
gold,gold,reconciled'. Not permitted if --experiment_file is
provided. |
--test_exclude_unassigned |
If present, exclude
unassigned documents from the test corpus. Not permitted if
--experiment_file is provided. |
--workflow <w> |
If --experiment_file is not
present, this must be a workflow which contains a tagging
step, specified in --tag_step. |
--tag_step <s> |
If --experiment_file is not
present, this must be a tag step in the workflow specified
in --workflow. |
--csv_formula_output
<fmt> |
The format for the CSV output
files. See the MATScore
documentation for details. |
--help |
Print the help message and
exit. |
Let's say you have an experiment file exp.xml whose corpora are
defined entirely using the <workspace_corpus> element, and
the workspace_dir attribute of <workspace_corpora> in that
file refers to the "WS" binding variable. Then, you can use that
experiment file as follows:
Unix:
% $MAT_PKG_HOME/bin/MATWorkspaceEngine /home/user/myworkspace \
run_experiment --experiment_file exp.xml --workspace_binding WS
Windows native:
> %MAT_PKG_HOME%\bin\MATWorkspaceEngine.cmd c:\home\user\myworkspace \
run_experiment --experiment_file exp.xml --workspace_binding WS
Performing document
reconciliation within workspaces is an advanced capability.
The operations in this section will support this capability when
it is available; it is not supported yet, due to UI limitations.
Use this operation to establish the active reconciliation phases
for your workspace.
Usage: MATWorkspaceEngine [options] <dir> configure_reconciliation [reconciliation_options] <phase> ...
<phase>: the name of a reconciliation phase to enable. Available phases are: human_vote human_decision crossvalidation_challenge
Use this operation to submit documents for reconciliation. The
phases that are assigned to the documents will be the phases
provided in the most recent configure_reconciliation operation.
Usage: MATWorkspaceEngine [options] <dir> submit_to_reconciliation [operation_options] <folder> [ <basename> ... ]
<folder>: The name of the folder to operate on.
<basename>: (optional) The basename or basenames to restrict the operation to.
The following folders support this operation: core
Command line option |
Description |
---|---|
--folds <n> |
If cross-validation is
enabled, number of cross-validation folds (i.e., number of
ways the corpus is split). Default is 8. |
--score_common_regions |
If present, generate a
pairwise score of all the common regions. The results can be
found in your workspace directory in
scores/<timestamp>. |
--human_decision_user
<user> |
If the human_decision phase
is enabled, a randomly-selected user with the human_decision
role handles the decisions, unless a substitute is specified
here. |
--help | Prints the remove_from_reconciliation help message and exits. |
If, for some reason, a document fails to exit reconciliation
naturally (if some of the users fail to complete their
reconciliation steps, for example), you can use this operation to
remove the document forcibly from reconciliation.
Usage: MATWorkspaceEngine [options] <dir> remove_from_reconciliation [operation_options] <folder> [ <basename> ... ]
<folder>: The name of the folder to operate on.
<basename>: (optional) The basename or basenames to restrict the operation to.
The following folders support this operation: reconciliation
Command line option |
Description |
---|---|
--dont_reintegrate |
By default, reconciliation
updates are integrated back into the core documents. Use
this flag to skip that step. |
--help | Prints the remove_from_reconciliation help message and exits. |
This operation forces a basename in the named folder to be
unlocked. The --user option is obligatory. Warning: be very certain that
you apply the force_unlock operation only to basenames whose locks have been stranded.
If you unlock a basename which is being annotated, the annotator
will not be able to save her changes.
Note: you can't use this lock to forcibly undo an
operation lock. In this situation you'll get an error "workspace
is currently unavailable (processing another request)". More on
how to deal with that here.
Usage: MATWorkspaceEngine [options] <dir> force_unlock [operation_options] <folder> [ <basename> ... ]
<folder>: The name of the folder to operate on.
<basename>: (optional) The basename or basenames to restrict the operation to.
Supported by folder 'core'.
Command line option |
Description |
---|---|
--user <user> |
The user who's locked the
basename. |
--help | Prints the force_unlock help message and exits. |