TMW-API Preprocessors | API-Version: 1.0.2-2022 |
Fileversion: 2022-08-17
For simple help see here.
For detailed documentation see
here.
All preprocessors can be called automatically when retrieving data from a certain domain. In this case, the call is set in the config.ini. For each domain a list of preprocessors can be defined, which are executed in the order of the list in the config file.
; config.ini entry in the processor section [processor] ={processor_name1} [.{parameter1} ] ={processor_name2} [.{parameter2} ] ... ={processor_name}[.{parameter}] ...
The second way to call a preprocessor is adding the processor name (with an optional parameter) after the domain name in the http request:
http://root/domain/
{processor_name}
[.
{parameter}
]/query...
It is possible to call a list of preprocessors by separating the name-parameter with a pipe charachter:
http://root/domain/
{processor_name1}
[.
{parameter1}
]|
{processor_name2
[.
{parameter2}
]/query...
In any case the processor list from the http request is worked off after the predefined list in the config.ini file.
Not yet implemented
If a processor supports multiple parameters to be given, this is done by separating the values with the pipe character |.
http://root/domain/{processor_name}.
{parameter1}
|
{parameter2}
|../query...
The linkcheck processor looks for broken internal links to SolR datasets. If the linked dataset does not exist, the entry in the controlled dataset is removed. The linkcheck needs a parameter to define the domain to which the links will be checked:
; definition in the config.ini [processor] =link.{domain2} ; call from the http request http://root/domain1/link.{domain2} /query...
For each domain a
; link check settings in the {domain}.ini file of the link check postprocessor [{field_to_check}] ="{domain_name}" ; domain of the link target ="{field_name}" ; field name of the referenced field ="{ref_field_name}" ; field name of the reference number in the checked record ="{ref_field_name_lref}" ; lref of the reffield [...] ...
The link resolver is used to get detailed information from internal linked records. Resolving data returns field information, which is inserted as a group in the corresponding entry. If the inserted block contains extern open data link, these are resolved by the open data resolver.
<broader_term>{term} ; added data from hierarchy processor <linkedData> <pageName>Technisches Museum Wien </pageName> <id>{broader_term_id} </id> <term>{broader_term} </term> <scopeNote>{broader_term_scopenote} </scopeNote>; optional external open data links [<link>{open_data_links} </link>] </linkedData> </broader_term> ...
The resolver is used to read certain data from a open data link
directly to the output from the api. The resolver has a plugin
interface to handle different api concepts.
The resolve preprocessor is simply called by adding
<link>{link_name} ; added data from resolve processor <linkedData> <pageName>{name_of_the_open_data_platform} </pageName> <id>{page_ID} </id> <term>{page_title} </term> <scopenote>{content_summary} </scopenote> </linkedData> </link>
With the additional parameter the internal links inside the open data resource, as well as the external links to other resources can be added too.
http://root/domain/resolve /query...; resolve data http://root/domain/resolve.links /query...; resolve data with all links
<link> <text>; link with optional additional parameters <uri>{link_name} </uri>; added data from resolve processor <linkedData> <pageName>{name_of_the_open_data_platform} </pageName> <id>{page_ID} </id> <term>{page_title} </term> <scopenote>{content_summary} </scopenote> <ilinks type="list"> <link> <url>{page_url} <url> <title>{page_title} <title> <link> ... </ilinks> <elinks type="list"> <link> <url>{page_url} <url> <title>{page_title} <title> <link> ... </elinks> </linkedData> </text> <text>; link with optional additional parameters ... </text> </link>
Still in developement
The topterm preprocessor can follow a hierarchy and add the records linked to the starting data. The content of a field can be used to define the topterm to stop the walk process. If no end condition is defined, the walk process continues to the record without a further link.
When the processor is called, additional records are added to the starting record in the order of the hierarchical linking. The parameters for the walk process are layed down in a .ini file, named by the domain: .
The ini file contains three parameters:
="{record_field_to_be_followed}" ="{record_field_for_end_condition}" ="{end_field_value_for_walk_end}"