Difference between revisions of "End-user workflows for name matching"
(Created page with "The details of workflows that end-users follow very strongly depends on the individual use case, which may range from checking a single name to uploading a regional or monogra...") |
|||
| Line 1: | Line 1: | ||
| − | The details of workflows that end-users follow very strongly depends on the individual use case, which may range from checking a single name to uploading a regional or monographic checklist with thousands of names. | + | The details of workflows that end-users follow very strongly depends on the individual use case, which may range from checking a single name to uploading a regional or monographic checklist with thousands of names. |
| + | Three types of the checking process itself can be distinguished: | ||
| + | #Directly using the name matching mechanisms the aggregator provides | ||
| + | #Using a tool that accesses the aggregator's name matching services (such as [[https://openrefine.org/ OpenRefine]]) | ||
| + | #Using local tools (following a download of the aggregator's data) | ||
| + | The choice of method mainly depends on the expected result but also on the number of records to be matched and on the technical in-house expertise available to the user. A type 3 process usually requires some expertise in biodiversity data management. TETTRIs provides links to [[Downloads_from_aggregators|download sites]] to get the aggregator's data. For type 2, TETTRIs will provide some example use cases that have been successfully tested. For type 1 (direct use of the aggregator’s services, the respective documentation will be pointed out in a list paralleling the [[Existing_name_checking_mechanisms|list of general capabilities of aggregators]]. | ||
| + | |||
| + | For the process itself, we can in principle distinguish 4 phases: | ||
*Preparing the data | *Preparing the data | ||
| + | In all cases, a list of names is needed in text-only format, which can be created from a spreadsheet column or be part of a table containing these names. One name only in one line is always required. | ||
*Submitting the data | *Submitting the data | ||
| + | Depends on the type of checking process. | ||
*Getting and interpreting the results | *Getting and interpreting the results | ||
| + | Essentially, for process type 1 and 2 the results are provided by listing exact matches and possible candidates, i.e. names that match the input to a certain extent. Interpretation refers to assessing the candidates and, if appropriate, selecting one of them as the correct match. | ||
*Incorporating the results locally | *Incorporating the results locally | ||
| − | + | On the one hand, this refers to corrections of names made locally as a result of candidate matching. On the other hand, once matches were made unambiguously, this may result in incorporating the aggregator's name ID into the local dataset, to allow linkage to the aggregator and (if such functionality is made available) interaction with the aggregator. | |
| − | |||
| − | |||
| − | |||
Revision as of 11:00, 23 May 2024
The details of workflows that end-users follow very strongly depends on the individual use case, which may range from checking a single name to uploading a regional or monographic checklist with thousands of names. Three types of the checking process itself can be distinguished:
- Directly using the name matching mechanisms the aggregator provides
- Using a tool that accesses the aggregator's name matching services (such as [OpenRefine])
- Using local tools (following a download of the aggregator's data)
The choice of method mainly depends on the expected result but also on the number of records to be matched and on the technical in-house expertise available to the user. A type 3 process usually requires some expertise in biodiversity data management. TETTRIs provides links to download sites to get the aggregator's data. For type 2, TETTRIs will provide some example use cases that have been successfully tested. For type 1 (direct use of the aggregator’s services, the respective documentation will be pointed out in a list paralleling the list of general capabilities of aggregators.
For the process itself, we can in principle distinguish 4 phases:
- Preparing the data
In all cases, a list of names is needed in text-only format, which can be created from a spreadsheet column or be part of a table containing these names. One name only in one line is always required.
- Submitting the data
Depends on the type of checking process.
- Getting and interpreting the results
Essentially, for process type 1 and 2 the results are provided by listing exact matches and possible candidates, i.e. names that match the input to a certain extent. Interpretation refers to assessing the candidates and, if appropriate, selecting one of them as the correct match.
- Incorporating the results locally
On the one hand, this refers to corrections of names made locally as a result of candidate matching. On the other hand, once matches were made unambiguously, this may result in incorporating the aggregator's name ID into the local dataset, to allow linkage to the aggregator and (if such functionality is made available) interaction with the aggregator.
