🔎 Resolver Config
Resolver config (or resolver-config) is the technical backbone of entity resolution. 🔎 Interested in learning more? Why not explore these Community posts (did you know if you're logged in, you'll unlock even more resources): Read about resolver config in the best practice library section on Entity Resolution Explore Community posts related to resolver config: Resolver config All posts tagged with resolver config Further documentation can be found on the Docs site: Resolver configuration reference Resolver YAML configuration Resolver JSON configuration Resolver Elasticsearch configuration Resolver security Resolver custom Attributes Resolver Attributes migration
Auto-coldlisting - primary vs secondary Elements
Auto-coldlisting is a powerful feature when it comes to tuning and improving Entity Resolution. Auto-coldlisting enables you to deactivate Compound values when sufficient contrary information, in the form of Elements, has been found to suggest that the Compound is overlinking distinct real-world Entities. Typically, Quantexa recommends using Elements that are primary to an Entity Type when Auto-coldlisting. For example, for individual Entities it is recommended to Auto-coldlist on primary Elements such as forename, middle name, surname, or date of birth as opposed to secondary Elements such as postcode, road, phone number. The reason for this is it is reasonable for an individual to have multiple addresses or phone numbers. For more and to see a worked example for how Auto-coldlisting is applied read the full article in our Community library: 1. Auto-coldlisting - Primary vs. Secondary Elements - Quantexa Community Typically, Quantexa recommends using Elements that are primary to an Entity Type when Auto-coldlisting. For example, for individual Entities it is recommended to Auto-coldlist on primary Elements such as forename, middle name, surname, or date of birth as opposed to secondary Elements such as postcode, road, phone number.…
