Mindbreeze GmbH, A-4020 Linz, 2018.
All rights reserved. All hardware and software names are brand names and/or trademarks of their respective manufacturers.
These documents are strictly confidential. The submission and presentation of these documents does not confer any rights to our software, our services and service outcomes or other protected rights. The dissemination, publication or reproduction hereof is prohibited.
For ease of readability, gender differentiation has been waived. Corresponding terms and definitions apply within the meaning and intent of the equal treatment principle for both sexes.
In order for the enrichment processes to be applied, the new metadata on the index must be added to the aggregated metadata keys. For example:
This chapter deals with the concept, setup, and troubleshooting methods for configuring entity recognition.
In this chapter, the concept of entity recognition is explained using a simple example.
Follow these steps to set up:
When configuring as a metadatum in Mindbreeze InSpire, the following fields must be filled in:
This chapter uses a simple example to explain entity recognition and its setup with Mindbreeze.
First the rules for the extraction have to be created:
UNCPath="\\\\" host "\\" share "\\" directory "\\".
If rule matches: UNCPath
In existing metadata: datasource/mes:key
If rule matches: UNCPath
In existing metadata: datasource/mes:key
Aggregated metadata keys (; separated)
Date formats for entity recognition are based on the ICU patterns (e.g. locale … de_AT)
Even a complex case in which the rules are ambiguous can be achieved using alternative rules and sequencing by name, as well as the correct sequencing of the multiple metadata extraction. The path, a metadatum, is lower-case and thus better for CSV mapping.
An OR (|) operator of sub-rules does not work!
> Simple solution without exception:
FullPath=LWPath "\\" FilePath.
> Solution with an exception (data\it):
LWPathA= BaseShare "\\" ASpecialPath.
LWPathOther= BaseShare "\\" OtherPath.
FullPathA=LWPathA "\\" FilePathA.
FullPathOther=LWPathOther "\\" FilePathOther.
The following screenshot demonstrates the configuration of the rules.
CSV-transform: the extracted value (file share) is case sensitive so the cases must match − that way the path can be used as source metadatum.
A match with mes:key goes in CSV transformation (as well as in ER rules) only with: In Property = datasource/mes:key.
Please note: /documents-Servlet does not provide values that only arise via index re-invert!
This chapter deals with troubleshooting the entity recognition rules.
Entity Recognition rules are usually greedy In the following example, the selected rows are matched:
R1=/ (?s)(test)(?P<line>.+)\s+(.*Page) /.
If greedy is deactivated, however, not everything is matched, but instead, only those blocks that start with test and end with Page:
An error with the following error message occurred while parsing the ER rules:
“MesQuery::Text::RE2Tokenizer ERROR: Matched empty (epsilon) token, pattern is”
… for instance, a „\“ at the end of a regex is not supported (LWPath=/\\\\[^\\]+\\/. … an error occurs better: LWPath=/\\\\[^\\]+/ “\\“.).
There can also be possible problems with “.*“ in rules.
Entity recognition rules are analyzed in alphabetical order and the first complete match wins.
Regex rules for German words do not match all characters (umlauts, etc.) with \w. Instead, you can use \pL to match all unicode characters.
+43 732 606162-0
+43 732 606162-609
z1 Dlmtr z2 Dlmtr z3 Dlmtr z4 Dlmtr z5 Dlmtr z6.
12 34 56-7
In this example a list of entries separated by semicolon will be interpreted as well as List in Mindbreeze InSpire.
Input: List of word, word,…
rule= /\s*/ value /\s*(,\s*|$)/.
This section focuses on metadata enrichment using a CSV file. In doing this, it is possible to compare a value in a metadatum (i.e. piece of metadata) with a value of a particular column in the CSV. If the value from the metadatum matches the value from the column, you can write the value of another column from the same row to a new metadatum and attach it to the result.
This chapter uses a concrete example to illustrate setting up CSV transformation. The following steps must be performed for the configuration:
Navigate to the Client Services tab, enable the Advanced Settings, and then expand the Client Services.
Search for the CSV transformation setting and set the function as shown in the example below.
CSV File Path: Path on the server of the CSV file copied by you
If Expression Matches: The name of the column in the CSV, which must match the value of a metadatum for the transformation
In Property: The existing metadatum that should be compared with the value from the column in the CSV
Name: The name of the metadatum that should contain the new enriched value
Value: The name of the column whose value is to be written to the new metadatum "Name" in order to enrich the result
Copy any CSV file to the /data/ directory on your Mindbreeze InSpire
The value of the existing metadatum (medication) is compared with the value from the Medication column. If a row was found in which these two values were equivalent, the value is extracted from the ATC_CODE column and attached to the metadatum ATC_CODE.
If you edit the CSV using a spreadsheet program such as Excel, you must ensure that the CSV is still in UTF8 format rather than UTF8-BOM format after processing.
This chapter deals with the use of the File Metadata Enricher. This plugin allows you to enrich indexed documents (e.g. PDF files) with external sources such as an XML file or a CSV file. This chapter differentiates between XML file metadata enrichment and catalog settings.
This mechanism is very similar to the mechanism of CSV transformation. In essence, this is about the possibility of comparing the value of a metadatum with the value in an XML file. If, for example, there is a file with content (e.g. mindbreeze.pdf) in a data source and another file that contains the metadata separately (e.g. mindbreeze.xml), they can be merged into one result to link the content to the metadata. This mechanism is explained in more detail in the following example:
File Path Source: Name of a metadatum used as a source for the enrichment. For example, a metadatum containing the path of the current result can be used. For instance, in the Microsoft File Connector, datasource/mes:key contains smb://myserver/testdaten/Content/.
File Path Pattern: Limits the enricher’s scope of application. All results whose mes:key values are not the same as the regex from File Path Pattern are ignored The enricher is not applied.
File Path Replacement: The path that contains the metadata of a file is specified here. The files must be located locally on the appliance or at least mounted on it. It is possible to reference a matching value of the regex specified in File Path Pattern as a variable here. The matching groups (REGEX) can be referenced in ascending order with $1 (e.g. $1, $2, $3, ...). The group (.*) can therefore be referenced with $1. In our case, the name of the file is extracted from the string that matches the File Path Pattern.
Metadata Node XPath: Each XML node that is made by this XPATH is interpreted by the enricher as an object with metadata.
Metadata Key XPath: The string that is matched by this XPATH expression is used by the enricher as the name of the new metadatum.
Metadata Value XPath: The string that is matched by this XPATH expression is used by the enricher as the value of the new metadatum.
Date Format: If a format is specified in Java Simple Date Format, the enricher will try to interpret each string that is matched by Metadata Value XPath as a date in the specified format to provide the entire functionality of the Mindbreeze date format. If the string is not in the specified format, the enricher performs a fallback and interprets the matching string as a string.
This chapter uses a concrete example of the enricher for illustration.
<?xml version="1.0" encoding="utf-8"?>
If it matches the regex from the file path pattern, the metadatum datasource/mes:key is compared with all local or mounted file names from the file path replacement path for each result that was configured for the index on which the metadata enricher is configured. In so doing, the file name that was defined as a regex group in the file path pattern is used in the File Path Replacement at the reference point.
Source file: …/1.pdf File Path Replacement: …/1.xml
If the paths match, the XML node /<Document>/* is searched for in the .xml and all child nodes of the node are interpreted as relevant information. The name of the node is interpreted as the metadatum name of the new metadatum to be created. If the current child node contains a text(), this is set as the value for the newly created metadatum, and the metadatum is attached to the current result in the index.
In our case, the following indexed metadata would be attached to the already indexed file 1.pdf:
This mechanism uses a CSV file as for enrichment. As with CSV transformation, information from Mindbreeze is compared with the value of a column in the CSV. Unlike CSV transformation, the metadatum cannot be selected for comparison because the plugin is actively searching for matches in the content of the file. Another important function of the plugin is the recognition of negations. If, for example, there is a match for renal failure, but renal failure is not mentioned in the text, renal failure is attached to the result as a negation in a separate metadatum. Additionally, this feature allows automatic links to be attached behind the hits and visualized in the PDF preview. The detailed operation of this function is explained in the following section.
Catalog File: This setting includes the path of the CSV file to be used for enrichment. The file must be located locally on the Mindbreeze InSpire Appliance or mounted on it.
Catalog Match On: This setting specifies which column of the CSV file is compared with the information from the content of the results in order to recognize a match.
Extract Metadata: In this field, the name of the metadatum is specified in which the text of the Metadata Value column is inserted if there is a match. The metadata is attached to the result.
Extract Negated Metadata: With this setting, you specify the name of the metadatum that contains the text of the Metadata Value column if it is matched in the case of a negation. This metadata is attached to the result. The match must be recognized as follows:
Negation Prefix Pattern + Catalog Match On (string for matching) + Negation Postfix Pattern
Extract Metadata Item: This metadatum contains a structured form of the entire applied CSV. This metadatum is not intended to be a filter and is only intended to support the development of search applications.
Metadata Value: This field must contain the column name of the CSV defined in the Catalog File setting. If the value of the Catalog Match On column matches the string currently compared from the content of the result, the value of the column specified in the Metadata Value field is attached as a string to the metadatum Extract Metadata.
Link HREF Pattern: In this setting, a link can be assembled using the extracted metadata. This link is then available in the PDF preview of the client. This link can be interpreted by the developer of the search application. The format of the link can be specified as follows:
Catalog ID Column: This setting determines which column of the CSV file is unique. This is used internally by Mindbreeze.
Sentence Split Pattern: This setting serves to divide the content of a sentence into sentence parts. The enricher is applied only in those parts of sentences that correspond to the regular expression given here.
Negation Prefix Pattern: This pattern specifies the prefix (usually text) to be used to recognize a negation. Here again, syntax means the syntax of the regular expressions.
Negation Postfix Pattern: This pattern specifies the Postfix (usually text) to be used to recognize a negation. Here again, the syntax means the syntax of the regular expressions.
Replacement Patterns: This field allows certain occurrences of words, sentences, or letters to be synonymous for the enricher. For example, this means it would be possible for ä to be ae and also for ae to be ä. The syntax for this is shown in the following example:
|>… Used as separator. Each rule must be entered as a separate line in the configuration field.