How to Set Up Search Types in GraphSearch

17/07/2025

This section contains a short overview on how to easily configure GraphSearch, using so-called Search Spaces, using existing thesauri and custom schemes maintained in PoolParty Thesaurus Server. It also includes a section on how to handle indexing errors caused by documents containing specific patterns commonly found in markdown links.

You should take a little time to plan ahead so the application looks well and does what you need it to do: find the content properly.

In the Search Spaces you can determine which data to use as well as its relations: the knowledge graph models of thesauri as well as custom schemes that you can later search, RDF data or tagged textual content. That way you will have your data displayed properly and easily accessible.

You should consider the following aspects, before setting up a Search Space in PoolParty GraphSearch:

What kind of data do you want to search? Has the data already been indexed with PoolParty, using thesauri and custom schemes? Does it have to be indexed yet?
Does the data reside outside of PoolParty and preliminary integration is necessary?
Where are the project (thesaurus or thesauri) and custom schemes you want to use, situated?
- On the local PoolParty instance, or in a remote graph database or a local search index (Solr, Elasticsearch) that already has been created for a PoolParty project?
What information is crucial for the search application's display?
- The display according to facets is the most basic usage concept in GraphSearch, therefore the custom scheme's relations and the concepts of the thesauri will be visible in the interface later.
Do you want images being displayed in your search application?
- In that case, the attribute 'image' should be properly configured in your custom scheme.

The pattern [text](identifier) is commonly used for links in markdown documents, but because it is reserved in Elasticsearch, you cannot use this syntax in content that will be indexed by Elasticsearch. Incompatible use of this syntax within documents, such as the text and title fields in the request body, can result in errors during indexing. For example, if you use the Content Create method, GraphSearch will return an internal server error because Elasticsearch rejects the index request for that text.

There are two cases in which this error occurs which can be detected by searching for their respective regex patterns and adjusting them before submitting them for indexing:

[<text>](<key>=<value>)
- Behavior: This pattern will be misinterpreted by the annotated text mapper plugin.
- Example Request:
```
{
    "searchSpaceId": "12345-abc",
    "identifier": "https://example-url.com/123",
    "title": "Example",
    "synchronize": false,
    "useExtraction": false,
    "author": "",
    "text": "Forbidden pattern: [Text](lhs=rhs)"
}
```
- Solution: It can be found via the regex \[([^]\[]*)]\(([^)(]*=[^)(]*)\) and the affected field or fields can be modified to adjust the clashing syntax.
[<text>](<*>%<*>)
- Behavior: If this pattern forms an invalid URL encoding it will be rejected. A valid URL encoding consists of a % sign followed by 2 or more characters.
- Example Request:
```
{
    "searchSpaceId": "12345-abc",
    "identifier": "https://example-url.com/123",
    "title": "Example",
    "synchronize": false,
    "useExtraction": false,
    "author": "",
    "text": "Forbidden pattern: [Text](%A)"
}
```
- Solution: It can be found via the regex \[([^]\[]*)]\(([^)(]*%[^)(]*)\) and the affected field or fields can be modified to adjust the clashing syntax.

In this section: