Description

This command can be used to add an annotation layer to an existing signal. The annotation has to be available as an XML file containing the same text (whitespace may vary) as the target signal. The layer will be added with the name layout. An existing layer with the same name will be overwritten if present.

Arguments

Examples

Add a HTML annotation from the file manual.html to the signal at annolab://default/manual.

$ annolab add-layer manual.html annolab://default/manual

Description

These commands offer different ways of employing UIMA Analysis Engines to create annotation layers. Signals are recursively loaded signal from the given AnnoLab URI(s), analysed and the analysis results are saved as new layers.

If the cpe command is invoked any collection reader specified in the CPE descriptor will be ignored and the AnnoLab collection reader will be used instead. An AnnoLab-internal CAS consumer is automatically added to the CPE and used in addition to any CAS consumers already present.

If the destination of this command is a location on the file system, the command runs in export mode. In this mode it accepts all parameters and switches also accepted by the export command. Those are marked with export mode below.

Arguments

Options

Switches

Mapping specification

The mapping controls how annotations are translated from XML to the UIMA CAS model and vice versa. While the CAS is based on an object-graph formalism to encode annotations, AnnoLab uses either a list or a tree. Thus the CAS has to be decomposed into a set of list and tree layers for AnnoLab to make use of it. The decomposition is controlled by the mapping file.

The mapping file is an XML file and its root is the <mapping> element. Children of is are any number of <layer> and <segment> sections. The <layer> section specifies how types from the CAS are converted to and from XML. The <segment> sections specify how stand-off anchors are extracted from the CAS.

A layer has a name, a type and a segment type (segType). The name specified the name of the layer extracted from the CAS and can be anything. The type has to be either tree or positional. A positional layer can hold a list of annotations on non-overlapping segments - it can be used e.g. for simple part-of-speech annotations. A tree layer is more flexible. Annotated segments may overlap and annotation elements may form a hierarchy. If in doubt use the type tree. AnnoLab currently only supports the segment type sequential (segments with integer start and end offsets).

A <layer> contains any number of <element> sections. Each of these defines how one UIMA type, determined by the casType attribute, is mapped to an XML element. The last component of the UIMA type name is used as the XML element name - for de.julielab.jules.types.Constituent it is Constituent. A feature declared in an UIMA type is either of a primitive type (integer, string, etc.) or of another UIMA type. Features of primitive types are mapped by a <feature> section. The attribute casName specifies the feature to be mapped while the mapAs attribute controls how it is mapped to XML:

Non-primitive features are mapped using <relation> section. Per default non-primitive features are not mapped to XML. They can be explicitly mapped as

If attribute inverted is set to true the specified feature does not have to be present in the mapped type. Instead it has to be present in some other type and reference the mapped type. In the example below the feature with the name constituent is present in the UIMA type Theme and it references the Constituent type. Whenever a Theme annotation references a Constituent annotation, the value of the primitive feature label (as indicated by the select attribute) is mapped to the XML attribute theme (as per the xmlName attribute).

<mapping>
 <layer type="tree" name="Parse-Theme" segType="sequential">
 	<element casType="de.julielab.jules.types.Constituent">
 		<feature casName="begin" mapAs="ignore"/>
 		<feature casName="end" mapAs="ignore"/>
 		<relation casName="parent" mapAs="dominance" inverted="true"/>
 		<relation casName="cat" mapAs="feature"/>
 		<relation casName="constituent" xmlName="theme" mapAs="feature" 
             inverted="true" select="label"/>
 	</element>
 	<element casType="org.annolab.uima.pear.stanford.Token">
 		<feature casName="begin" mapAs="ignore"/>
 		<feature casName="end" mapAs="ignore"/>
 		<feature casName="componentId" mapAs="ignore"/>
 		<relation casName="parent" mapAs="dominance" inverted="true"/>
 		<relation casName="this" mapAs="segments"/>
 		<relation casName="posTag" mapAs="feature" select="value"/>
 		<relation casName="lemma" mapAs="feature" select="value"/>
 	</element> 
 </layer>
</mapping>

Filter rules specification

Each line of the filter specification file corresponds to one rule. The first part of the line (before the colon) is the name of a feature (XML attribute). After the colon follows a regular expression. The rule matches if an annotation element bears the given feature and the feature value matches the regular expression.

The following example of a filter specification defines two rules. The first rule matches all XML elements bearing an attribute class with either the value table or abstract. The second rule matches all XML elements bearing an attribute speaker ending in Smith. Data covered by XML elements matching either of these rules is not included in the output.

class: table|abstract
speaker: .*Smith

Examples

To add layers to documents already in a data store simply do not specify any source. The following command will run the pipeline pos-pipe.xml and on each signal in the data store default and add the resulting annotations as layers to those signals.

$ annolab pipeline pos-pipe.xml annolab://default

Description

This command copies data from the file system into a data store, from a data store into another data store, or from a data store to the file system. Importers are used to convert data originating from the file system. AnnoLab ships with importers for plain text, HTML, XML, PDF and FLOB/FROWN. The info command shows all installed importers.

If the destination is on the file system, AnnoLab will dump signals as raw data (e.g. as text files) and layers as XML files. If the source is a file system directory or a collection within a data store, it is copied recursively.

Arguments

Switches

Examples

Import the PDF file test.pdf into the store default to the collection test.

$ annolab copy test.pdf annolab://default/test

Convert the PDF file test.pdf to text and HTML using AnnoLab's PDF importer and save the results on the file system in the directory some/directory.

$ annolab copy test.pdf some/directory

Convert the XHTML file file.html to text and HTML using AnnoLab's XML importer and save the results on the file system in the directory some/directory.

$ annolab copy file.html some/directory
    

Description

This command recursively deletes resources. Per default all resources are deleted. The --layer option can be used to delete only particular layers.

Arguments

Options

Examples

Delete all contents within the data store default.

$ annolab delete annolab://default   

Delete only the layer Token from all signal in the data store default.

$ annolab delete --layer Token annolab://default

Description

AnnoLab comes with an embedded eXist XML database. This command starts the eXist GUI client that ships with the embedded eXist and configures it to access the data store underlying location given. The given location has to point to an eXist-based data store.

Arguments

Login Problems

It may happen that AnnoLab fails to pre-configure the database login dialog. If the log in fails, make sure the username is admin, the type is Remote and the URL is xmldb:store:///. Replace store in the URL with the name of the data store addressed by the location argument given on the command line when starting the client. All other fields should remain empty.

Figure 18. eXist login settings

Examples

This command starts the eXist client on the data store default.

$ annolab exist client annolab://default

Description

This command recursively exports all signals and their layers to the given destination. A so-called integrated representation is created for each signal. This is an XML document containing all layers on that signal plus the signal itself. Such a document is suitable for transformation to arbitrary target formats using XSLT style sheets.

Arguments

Options

Switches

Examples

In the following example we create a directory called integrated and then export all data in the data store default to that directory.

$ mkdir integrated
$ annolab export annolab://default integrated

In the next example we use an XSLT style sheet called plaintext.xslt to extract only the signal (text) from the integrated representation. The suffix of the exported files is explicitly set to .txt.

$ annolab export --xslt plaintext.xslt --suffix .txt 
          annolab://default text

Description

This command copies signals (without layers), optionally filtering the signals by removing parts of the signal annotated for a particular features in the specified layer. The features causing a part of the signal to be removed are either a built-in default set or the set of features given in the optional rule file. If the source is a collection, all signals are filtered recursively.

Arguments

Options

Filter rules specification

Each line of the filter specification file corresponds to one rule. The first part of the line (before the colon) is the name of a feature (XML attribute). After the colon follows a regular expression. The rule matches if an annotation element bears the given feature and the feature value matches the regular expression.

The following example of a filter specification defines two rules. The first rule matches all XML elements bearing an attribute class with either the value table or abstract. The second rule matches all XML elements bearing an attribute speaker ending in Smith. Data covered by XML elements matching either of these rules is not included in the output.

class: table|abstract
speaker: .*Smith

Examples

The following command recursively copies a filtered version of the complete data store annolab://default/ to the directory filteredOutputDirectory.

$ annolab filter --filter Layout annolab://default/ 
    filteredOutputDirectory/

Assuming the above is the content of a file named filterRules.properties, the following command uses this file to control the filter.

$ annolab filter --rules filterRules.properties 
    --filter Layout annolab://default/ filteredOutputDirectory/

Description

Invoking this command without any arguments prints a list of the available commands. Optionally a command can be given as the only argument. In this case detail help for the command will be printed.

Arguments

Examples

Get a list of all available commands.

$ annolab help

Get help for the copy command.

$ annolab help copy

Description

If a corpus is large the resources to annotate it completely and exhaustively may not be available. A query can be used to extract particularly interesting sections of the corpus for further annotation.

Arguments

Options

Switches

IMS CWB database requirements

This command can be used to convert a search result from the IMS CWB to a UAM Corpus Tool project. It retains information about the original location of the extracted data in a special layer of the UAM Corpus Tool project, which can be used later to integrate the annotation with the complete corpus.

The IMS CWB corpus database must have been created with at least the following positional attributes:

These must appear in exactly the given relative order: uri, s, e. There can be other positional attributes present in the database.

To integrate the partial annotations made in the generated UAM Corpus Tool project back onto the full texts, use the command uam2annolab.

Tolerance to changes

The data store from which the IMS CWB database has been created has to be available when this command is used. For best results the signals not have changed between the time the IMS CWB database has been created and the time the command is used. If the data has changed, AnnoLab tries its best to fix the offsets so that the generated UAM Corpus Tool project is aligned to the changed signals.

Examples

After you have prepared an IMS CWB database fulfilling the above requirements, you can log into it with cqp and perform queries as usual.

Once you wish to export a query result to UAM Corpus Tool, you need to CONFIGURE IMS CWB to produce the output format needed by ims2uam. Turn on only the display of the three positional parameters mentioned above (+uri +s +e) and turn off any other parameters:

MYCORPUS> show +uri +s +e;

Run the query again storing the results in a variable. The use the cat command to save to results to a file. Here we did a query extracting all sentences containing the word algorithm within all texts in annolab://default/A.

MYCORPUS> results = "algorithm" :: 
          match.document_uri="annolab://default/A/.*" within s;
MYCORPUS> cat results > "cqpresults.txt"; 

Now leave cqp and run ims2uam on the saved results. First create an empty directory to take up the project. For this example the directory is called target.

$ mkdir target
$ annolab ims2uam queryresults.txt target

After this you will find a UAM Corpus Tool project named project in the target directory.

Description

This command shows some pieces of information about the AnnoLab installation.

Examples

Get some basic information about the AnnoLab installation.

$ annolab info

Description

This command provides a small processing pipeline using a simple tokeniser and TreeTagger for part-of-speech tagging and lemmatisation.

The sub-command list prints a list of the available tagging models. One of these models has to be specified when using the process

The sub-command process runs the pipeline. It can optionally filter the texts (hide certain parts from the analysis components as not to confuse them) and transform the results from the integrated representation format using an XSLT style sheet.

This command is deprecated. It requires that the module org.annolab.module.treetagger.TreeTaggerModule has been configured in the annolab.xconf file. Instead the pipeline command should be used in conjunction with the treetagger-ae PEAR. This combination provides more flexibility and control and does not require a local installation of TreeTagger or modifications to the annolab.xconf file.

Arguments

Options

Switches

Built-in XSLT style sheets

The command comes with a few built-in XSLT style sheets.

Module configuration (annolab.xconf)

This command requires a local installation of TreeTagger. After you have installed TreeTagger on your system, AnnoLab has to be instructed where to find it and which tagging models are available. In order the following section has to be added to the modules section of the annolab.xconf file. You have to adapt the following example to your installation. Put the absolute path to your TreeTagger executable into the executable section. Maintain a model section for each tagging model you have. For each model specify a name (name section), the absolute path to the model file (file section), the model encoding (encoding section) and a simple full sentence in the language on which the model was trained (flushSequence section). Note that there has to be a space between each token of that sentence including before the final full-stop (.). Optionally a substitution file can be specified (substitutions section).

<module class="org.annolab.module.treetagger.TreeTaggerModule">
 <executable>/Applications/treetagger/bin/tree-tagger</executable>
	<models>
		<model>
			<name>english</name>
			<file>/Applications/treetagger/lib/english.par</file>
			<encoding>Latin1</encoding>
			<flushSequence>This is a dummy sentence .</flushSequence>
			<substitutions>/Applications/treetagger/lib/en.xml</substitutions>
		</model>
	</models>
</module>

Substitution file

A substitution file can be used to substitute characters or sequences of characters that are known to be broken or to be misinterpreted by an analysis component. They can be replaced by the what is known to be the correct character or sequence or by some sensible substitute the analysis component can deal with.

For example a tagging model may not know about the Unicode quotes “ and ” and consequently tag them wrong. The example below substitutes such quotes with a regular quote " (written as the XML entity " here because in an XML file literal quotes have to be written as XML entities). The example also substitutes some greek letters with the letter x. The model does not know about greek letter, but knows that x is usually a mathematical symbol and thus tags it as SYM.

<?xml version="1.0" encoding="UTF-8"?>
<substitutionTable>
	<substitution orig="“" subst="&quot;"/>
	<substitution orig="”" subst="&quot;"/>

	<!-- x is tagged as SYM -->	
	<substitution orig="α" subst="x"/>
	<substitution orig="π" subst="x"/>
	<substitution orig="τ" subst="x"/>
	<substitution orig="Γ" subst="x"/>
	<substitution orig="Λ" subst="x"/>
</substitutionTable>

Examples

Print a list of available tagging models.

$ annolab lemmatize list

Create a new directory called results. Then process all files in the directory texts using the model english and write one result file per text. Transform the results using the XSLT file bnc.xslt.

$ mkdir results
$ annolab lemmatize process +split --format bnc.xslt english texts results

Description

This command recursively lists the content of a data store. Each signal is listed along with its annotation layers listed indented below it.

Arguments

Examples

List the contents of the data store default.

$ annolab list annolab://default  

Description

Given a collection or a directory this command generates a table with all children of the given collection or a directory listed on the X axis and tags or signal data on the Y axis. For example one can get a table showing the distribution of lemmas (Y axis) across all texts in a collection (X axis), with one row per lemma and column per one sub-collection. Or you can get a table showing the distribution of part-of-speech tags (Y axis) across a set of directories (X axis). The command uses TreeTagger to generate the part-of-speech and lemma. The output is a CSV file in UTF-8 (works well with OpenOffice Calc).

It is mandatory to specify a model using the parameter -m. To get a list of available models use the command lemmatize list. This command requires the same set up as the lemmatize command. Please refer to the documentation of that command to find out how to set up AnnoLab to work with a local installation of TreeTagger.

The source has to be a collection in a data store or a directory on the file system. For each child of the source a column will be created in the output table. Assuming the following data store structure the source annolab://default/A results in a table with the columns Text1 and Text2 while the source annolab://default results in a table with the columns A and B.

default
  +-- A
  |   +-- Text 1   
  |   +-- Text 2   
  +-- B
      +-- Text 3

Per default the Y axis of the table shows the lemma and part-of-speech. This can be changed using the option -f, which takes a comma-separated list of field names. Note that field names are case-sensitive.

Arguments

Options

Switches

Examples

The following example accesses the data store default. TreeTagger is invoked with the model english to generate the part-of-speech tags. Data on the horizontal axis consists of the signal and part-of-speech tags and is lowercase. The output is written to the file matchlist.csv.

$ annolab matchlist +lowercase -f SIGNAL,posTag -m english
    annolab://default matchlist.csv

Description

This command allows to manage UIMA PEARs in AnnoLab. A PEAR is a packaged analysis component that can be used in a pipeline. Before a PEAR can be used in AnnoLab it has to be installed. When it is no longer needed or before a new version is installed, a PEAR has to be uninstalled. It is also possible get a list of the currently installed PEARs and to get an detailed information about an installed PEAR.

The install sub-command is used to install a PEAR into AnnoLab. When a PEAR is installed, it receives a unique name. To work with an installed PEAR in a pipeline or with any commands, this name has to be used to address the PEAR.

The uninstall sub-command is used to uninstall a PEAR, either because it is no longer needed or as a preparation to install a newer version.

The explain sub-command prints detail information about a PEAR. In particular it prints a list of configuration parameters that can be changed in a pipeline descriptor file to configure the analysis component. Also a list of input and output capabilities is printed. Within a pipeline the analysis components need to be ordered in such a way that all data a particular PEAR lists as its inputs have been produced by previous pipeline stages. The data produced by an analysis component is listed as its outputs.

The list sub-command prints a list of all installed PEARs.

Arguments

Examples

Uninstall a the PEAR java-sentence-ae so a new version can be installed..

$ annolab pear uninstall java-sentence-ae

Install the PEAR java-sentence-ae from the file java-sentence-ae.pear.

$ annolab pear install java-sentence-ae.pear

Get a list of all installed PEARs.

$ annolab pear list

Get more information about the java-sentence-ae PEAR.

$ annolab pear explain java-sentence-ae

Description

These commands allow to perform queries from the command line. Queries can be run completely manually using the mquery command or using query templates with the query command.

In manual mode, the query is read in from the terminal after the command has been started. Alternatively you can create a text file containing the query and feed it to the command using input redirection.

In template mode a query template descriptor file has to be specified as the template argument.

Arguments

Options

Switches

Query templates

A query template consists of a template descriptor file (actually a Java property file), a query file and optionally XSLT files that can be used to transform the query results.

For our example we will create a query template file called query-example.template and a directory query-example. Into the latter we put the query file and the XSLT files.

Each line of the template descriptor file consists of a property name followed by an equals sign (=) followed by the property value. For properties pointing to files, paths are always treated as being relative to the template descriptor file. The query-example.template file should look like this:

summary = This is an example query searching for a word
description = Here we would put a much longer description.
query = query-example/query.xq
xslt.default = query-example/html.xslt
xslt.html = query-example/html.xslt
xslt.csv = query-example/csv.xslt
variable.word.prompt = Search word
variable.word.description = Word to search for

The property summary specifies a short summary of what the query does. A longer description can be given using the property description.

The property query defines the name of the file containing the query. This is relative to the location of the template descriptor file. For more information on writing the query file xquery.xq itself, see the chapter on querying.

Following are optional properties starting with xslt.. These specify XSLT style sheets that can be used to transform the output of the query. If the property xslt.default is present, the specified XSLT file is always used unless a --xslt parameter is used to explicitly specify another. In the given case we could specify --xslt csv to use the XSLT style sheet specified with the property xslt.csv instead of the default. Since you have complete control of the query results, any discussion of how to do the XSLT style sheets is omitted here. It is suggested that to keep the query simple and the results plain and use XSLT style sheets to do aggregation and/or formatting.

Free query variables need to be declare using properties starting with variable.. The example above declares a variable named word. When the user does not specify a variable value using the -V parameter, the value is asked for. The description from variable.word.description is shown on the screen and the user can enter the value after the prompt specified in variable.word.prompt.

--- Unset variable ---
Description: Word to search for
Search word: _

Examples

Run a query against the data store default using input redirection. The file query.xq contains the actual query.

$ annolab mquery annolab://default < query.xq

Profile the query template word.template by running it 10 times in a row searching for the word be.

$ annolab query --repeat 10 -Vword=be word.template annolab://default

Run the query template word.template using the html XSLT style sheet specified in the template descriptor and saving the results to results.html.

$ annolab query --xslt html word.template annolab://default results.html

Description

This is the sister-command to ims2uam. It re-integrates the partial annotations made in an UAM Corpus Tool project generated with ims2uam back into the corpus.

Arguments

Options

Switches

Tolerance to changes

The data store into which the annotations should be integrated already has to contain the signals. For best results the signals not have changed between the time the IMS CWB database has been created and the time the command is used. If the data has changed, AnnoLab tries its best to find the annotated text in the changed signal and transfer the annotations accordingly.

Examples

The following command re-integrates the layer Transitivity from the UAM Corpus Toolproject in the directory meaning-C1. The --remap option is used to integrate the annotations on the results originally extracted from annolab://dfg/archive/ into annolab://default/dfg/.

$ annolab uam2annolab --remap annolab://dfg/archive/ annolab://default/dfg/
    --layer Transitivity meaning-C1
  

Description

This command starts AnnoLab as a server. Two services exposed by the server are provided directly by the embedded eXist database: the eXist REST service and the XML-RPC service.

The REST service runs at http://localhost:8080/stores/store/exist/rest.

The XML-RPC service runs at http://localhost:8080/stores/store/exist/xmlrpc.

In both URLs store has to be replaced by the name of the data store that was being addressed by the AnnoLab URL given as a parameter when starting the server.

Both services offer way of modifying the content of the eXist database but neither those methods nor the built XQuery management functions of eXist should be used. Instead the XQuery extensions provided by AnnoLab for data store management should be used to add or remove content.

Queries issued through these services have access to the same AnnoLab XQuery extensions that are available for the mquery and query commands.

For more information on how to use these services, please refer to the eXist documentation at http://exist.sourceforge.net/.

Per default the server can only be access locally. To access the server from remote machines or to change the port the server is running on, please refer to the file configuration/config.ini in the AnnoLab installation directory. There you can modify the two configuration items org.eclipse.equinox.http.jetty.http.host and org.osgi.service.http.port.

Press CTRL+C to terminate the server.

Arguments

Examples

To start a server for the data store default use:

$ annolab webserver annolab://default

Description

Find all layers of the given name. Layers can be searched for in the whole data store or only within a particular collection and its sub-collections.

Arguments

Examples

This example queries for all XHTML headers (h1) in the layer Layout within annolab://default.

$ annolab mquery annolab://default
               
Enter query. Press <CTRL-D> when done to start execution.
               
declare namespace xhtml="http://www.w3.org/1999/xhtml";
ds:layer($QUERY_CONTEXT, "Layout")//xhtml:h1
CTRL+D
               
            

Description

Get the meta data of the resource addressed by the given AnnoLab URI. Meta data can be stored with a layer when it is imported using the manage:import() function.

Arguments

Examples

This example gets the meta data of a signal at annolab://default/SomeText.

$ annolab mquery annolab://default
               
Enter query. Press <CTRL-D> when done to start execution.
               
ds:meta("annolab://default/SomeText")
CTRL+D
               
            

Description

Get the contents of the signal addressed by the given AnnoLab URI.

Arguments

Examples

This example gets the contents of a signal at annolab://default/SomeText.

$ annolab mquery annolab://default
               
Enter query. Press <CTRL-D> when done to start execution.
               
ds:signal("annolab://default/SomeText")
CTRL+D
               
            

Description

Delete the signal at the specified location. The second argument can be the name of a layer. In that case the layer is deleted from the signal. The signal is deleted as well if the layer being deleted is the last one on that signal.

The return value of the command is a sequence of messages stating which signal and layers have been deleted.

Arguments

Examples

This example deletes the layer Layout from the signal annolab://default/SomeText.

$ annolab mquery annolab://default
               
Enter query. Press <CTRL-D> when done to start execution.
               
manage:delete("annolab://default/SomeText", "Layout")
CTRL+D
               
            

Description

Import a layer from an URL or from a location within the XML database. If there is already a signal at the destination URI, the layer will be anchored on that signal. Otherwise the text is extracted from the layer and be used to create a new signal at the destination URI.

The return value of the command is a sequence of messages stating which signal and layers have been deleted.

Arguments

Examples

This example shows how to import the file README.xhtml from the current directory to the data store location annolab://default/README. Since no signal existed at this location before, a new signal is created and the XHTML is added as the layer Layout to that signal with the MIME-type for XHTML data application/xhtml+xml.

$ annolab mquery annolab://default
               
Enter query. Press <CTRL-D> when done to start execution.
               
manage:import("file:SomeText.xhtml", "annolab://default/SomeText",
              "application/xhtml+xml", "Layout")
CTRL+D
               
            

Description

These functions can be used to filter a set of elements A with respect to a set of elements B and a relation R between the two. These relations can be containing, contained-in, same-extent, overlapping, left-overlapping and right-overlapping.

The functions all work following the same principle: return each a in A which is in the given relation R with any b in B.

When an element a and/or b of the sequences A or B is not a segment, a segment is calculated from the left-most and the right-most positions addressed by any descendant segment of the element and used for comparing the two elements.

Arguments

Examples

Assume the layer Speaker contains turn elements with the speaker encoded in the attribute speaker. Assume also that the layer Token contains segment elements with the part-of-speech encoded in the attribute posTag. The following query extracts all nouns spoken by the speaker Chad.

$ annolab mquery annolab://default
               
Enter query. Press <CTRL-D> when done to start execution.
               
element results {
  seq:contained-in(
    ds:layer($QUERY_CONTEXT, "Token")//segment[starts-with(@posTag, "N")],
    ds:layer($QUERY_CONTEXT, "Speaker")//turn[@speaker="Chad"])
}
CTRL+D
               
            

Description

The function seq:grow calculates a segment from the left-most and the right-most positions addressed by any descendant segment of the sequence of elements passed to it. The result is a single segment that covers all the data addressed by the sequence. This function is commonly used in conjunction with txt:get-text to retrieve a meaningful and easily readable section of the signal that includes whitespace and line breaks.

Arguments

Examples

See the example for the function txt:get-text().

Description

These functions get $n ^th the following or preceding siblings of the nodes in the sequence of nodes $A. If the parameter $n is 0 the input list is returned, if it is 1 all immediately following siblings are returned, if it is 2, all 2^nd following siblings are returned, and so on. This function was implemented to be more efficient than using the following-sibling axis.

Arguments

Examples

Assume also that the layer Token contains segment elements with the part-of-speech encoded in the attribute posTag. The following query extracts all verbs and one token to the left and to the right of them.

$ annolab mquery annolab://default
               
Enter query. Press <CTRL-D> when done to start execution.
               

element results {
  for $v in ds:layer($QUERY_CONTEXT, "Token")//segment[
      starts-with(@posTag, "V")]
  return element result {
    tree:preceding-sibling($v, 1),
    $v,
    tree:following-sibling($v, 1)
  }
}
CTRL+D
               
            

Description

Search for the given regular expression pattern in the areas addressed by the elements and segments given in the first parameter. Returns a set of segments indicating the matches.

Arguments

Examples

Find all occurrences of the string zero knowledge within XHTML paragraphs (xhtml:p) of the layer Layout.

$ annolab mquery annolab://default
               
Enter query. Press <CTRL-D> when done to start execution.
               
declare namespace xhtml="http://www.w3.org/1999/xhtml";
txt:find(ds:layer($QUERY_CONTEXT, "Layout")//xhtml:p, "zero knowledge")
CTRL+D
               
            

Find all XHTML paragraphs (xhtml:p) in the layer Layout containing the string zero knowledge. The wildcards (.*) at the beginning and the end of the search pattern cause the whole paragraph to be returned as a result.

$ annolab mquery annolab://default
               
Enter query. Press <CTRL-D> when done to start execution.
               
declare namespace xhtml="http://www.w3.org/1999/xhtml";
txt:find(ds:layer($QUERY_CONTEXT, "Layout")//xhtml:p, ".*zero knowledge.*")
CTRL+D
               
            

Description

The function txt:get-text gets the contents addressed by the sequence of segments passed as the first argument. The functions txt:get-text-left and txt:get-text-right a number of characters left or right of each item in the sequence of segments passed as the first argument. The number of characters is specified as the second argument.

Arguments

Examples

In this example the PDF file SomeText.pdf is copied into the data store default. AnnoLab automatically extracts some layout information from the PDF and stores it as XHTML annotations in the layer Layout. Then a query is issued against that data store looking for all page breaks sections (xhtml:div[@class="pagebreak"]). For each an XML element result is created containing the text extracted from the page break sections by the txt:get-text function. Because the serialiser can only serialise XML fragments with a single root element, all is wrapped in the element results.

The function txt:get-text fetches the text addressed by each segment. Often segments addresses words, but not the whitespace between them. In order to get an actual piece of text, the seq:grow function can be used. It calculates a segment from the left-most and the right-most positions addressed by any descendant segment of the sequence of elements passed to it. Thus this function is commonly used in conjunction with txt:get-text to retrieve a meaningful and easily readable section of the signal that includes whitespace and line breaks.

$ annolab copy SomeText.pdf annolab://default
$ annolab mquery annolab://default
               
Enter query. Press <CTRL-D> when done to start execution.
               
declare namespace x="http://www.w3.org/1999/xhtml";
element results {
  for $pb in ds:layer($QUERY_CONTEXT, "Layout")//x:div[@class="pagebreak"]
  return element result { txt:get-text(seq:grow($pb)) }
}
CTRL+D