Extractor Node - Revision history

Dgreenwood: Redirected page to Data Extractor (Concept)#Extractor Nodes

2025-08-27T16:36:53Z

Redirected page to Data Extractor (Concept)#Extractor Nodes

← Older revision		Revision as of 11:36, 27 August 2025
Line 1:		Line 1:
	~~<blockquote>{{~~#~~lst:Glossary\|Extractor Node}}</blockquote>~~		#REDIRECT [[Data Extractor (Concept)#Extractor Nodes]]

	~~== About ==~~
	~~<section begin="Extractor Nodes" />~~
	~~=== Types of Extractor Nodes ===~~
	~~There are three types of Extractor Nodes in '''Grooper''':~~
	~~: {{ValueReaderIcon}} '''[[Value Reader]]'''~~
	~~: {{DataTypeIcon}} '''~~[[Data ~~Type]]'''~~
	~~: {{FieldClassIcon}} '''[[Field Class]]'''~~
	~~:*<li class="attn-bullet"> Advances in large-language models (LLMs) have largely made Field Classes obsolete. LLM-based extraction methods in Grooper~~ (~~such as [[AI Extract]]~~) ~~can achieve similar results with nowhere near the amount of set up.~~
	~~All three of these node types perform a similar function. They return data from documents. However, they differ in their configuration and utility.~~

	~~Extractor Nodes are tools to extract/return document data. But they don't do anything by themselves. They are used by extractor properties on other nodes in Grooper.~~
	* Example: [[Data Element]]s, such as [[Data Field]]s, are ultimately collect document data. It is the Data Field's "Value Extractor" configuraiton that does this. However, you may configure a Data Field's Value Extractor with an Extractor Node to do so.
	* Example: The [[Pattern-Based Separation]] provider's "Value Extractor" is ultimately what identifies patterns to separate Batch Pages into Batch Folders. However, you may configure the Value Extractor with an Extractor Node to do so.
	* Example: When [[Classify]] runs on a document, a [[Document Type]]'s "Positive Extractor" will be used to assign a Batch Folder the Document Type if it returns a value. You may configure the Positive Extractor with an Extractor Node to do so.
	* And so on and so on for any extractor property for any node in Grooper.


	~~To that end, Extractor Nodes serve three purposes:~~
	~~# To be re-usable units of extraction~~
	~~# To collate data~~
	~~# To leverage machine learning algorithms to target data in the flow of text~~
	#*<li class="attn-bullet"> Advances in large-language models (LLMs) have largely made Field Classes obsolete. LLM-based extraction methods in Grooper (such as [[AI Extract]]) can achieve similar results with nowhere near the amount of set up.
	~~<div style="padding-left: 1.5em">~~

	~~=== Re-usability ===~~
	~~Extractor nodes are meant to be referenced either by other extractor nodes or, importantly, by Data Elements such as '''Data Fields''' in a '''Data Model'''.~~

	For example, an individual '''Data Field''' can be configured on its own to collect a date value, such as the "Received Date" on an invoice. However, what if another '''Data Field''' is collecting a different date format, like the "Due Date" on the same invoice? In this case you would create one extractor node, like a '''Value Reader''', to collect any and all date formats. You could then have each '''Data Field''' reference that ''single'' '''Value Reader''' and further configure each individual '''Data Field''' to differentiate their specific date value.

	~~=== Data collation ===~~
	Another example would be configuring a '''Data Type''' to target entire rows of information within a table of data. Several '''Value Reader''' nodes could be made as children of the '''Data Type''', each targeting a specific value within the table row. The parent '''Data Type''' would then collate the results of its child '''Value Reader''' nodes into one result. A '''Data Table''' would then reference the '''Data Type''' to collect the appropriate rows of information.

	~~=== Machine learning ===~~
	Many documents contain important pieces of information buried within the flow of text, like a legal document. These types of documents and the data they contain require an entirely different approach to extracting data than a highly structured document like an invoice. For these situations you can use a "trainable" extractor known as a '''Field Class''' to leverage machine learning algorithms to target important information.
	*<li class="attn-bullet"> Advances in large-language models (LLMs) have largely made Field Classes obsolete. LLM-based extraction methods in Grooper (such as [[AI Extract]]) can achieve similar results with nowhere near the amount of set up.

	~~=== Extractor Nodes vs Value Extractors ===~~
	Extractor nodes should not be confused with "Value Extractors". There are ''many'' places in '''Grooper''' where extraction logic can be applied for one purpose or another. In these cases a Value Extractor is chosen to define the logic required to return a desired value.

	~~In fact, the~~ Extractor Nodes ~~themselves will leverage specific Value Extractors to define their logic.~~
	* Example: "Value Readers" are configured using a single property "Extractor". This property specifies a single Value Extractor which determines how data is extracted. Value Readers are essentially an encapsulation of a single Value Extractor configuration that can be reused by multiple other extraction elements and properties, such as Data Fields and Data Types.
	* Example: "Data Types" have several properties that can be configured with Value Extractors, including its "Local Extractor", "Input Filter", and "Exclusion Extractor" properties.
	* Example" "Field Classes" cannot function without its "Value Extractor" and "Feature Extractor" properties configured, both of which specify a Value Extractor.

	~~However, Extractor Nodes are used when you need to ''reference'' them for their designated strengths:~~
	* re-usability
	* collation
	* machine learning
	**<li class="attn-bullet"> Advances in large-language models (LLMs) have largely made Field Classes obsolete. LLM-based extraction methods in Grooper (such as [[AI Extract]]~~) can achieve similar results with nowhere near the amount of set up.~~

	~~=== Related Node Types ===~~
	~~<div style="padding-left: 1.5em">~~
	~~==== Value Reader ====~~
	~~{{#lst:Glossary\|Value Reader}}~~

	~~==== Data Type ====~~
	~~{{#lst:Glossary\|Data Type}}~~

	* For example, if you're extracting a date that could appear in multiple formats within a document, you'd use various extractor nodes (each capturing a different format) as children of a '''Data Type'''.

	The '''Data Type''' also defines how to collate results from one or more extractors into a referenceable output. The simplest type of collation (''Individual'') would just return all individual extractors' results as a list of results.

	'''Data Types''' are also used for recognizing complex 2D data structures, like address blocks or table rows. Different collation methods would be used in these cases to combine results in different ways.

	~~==== Field Class ====~~
	~~{{#lst:Glossary\|Field Class}}~~
	~~</div>~~
	~~</div>~~
	~~<section end="Extractor Nodes" />~~

Dgreenwood: /* Types of Extractor Nodes */

2025-08-06T21:18:46Z

Types of Extractor Nodes

← Older revision		Revision as of 16:18, 6 August 2025
Line 7:		Line 7:
	: {{ValueReaderIcon}} '''[[Value Reader]]'''		: {{ValueReaderIcon}} '''[[Value Reader]]'''
	: {{DataTypeIcon}} '''[[Data Type]]'''		: {{DataTypeIcon}} '''[[Data Type]]'''
	: {{FieldClassIcon}} '''[[Field Class]]''' ~~''Uncommonly used~~ in ~~current~~ Grooper ~~implementations''~~		: {{FieldClassIcon}} '''[[Field Class]]'''
	All three of these node types perform a similar function. They ~~are configured to~~ return data from documents. However, they differ in their configuration and ~~data extraction purpose~~.		:*<li class="attn-bullet"> Advances in large-language models (LLMs) have largely made Field Classes obsolete. LLM-based extraction methods in Grooper (such as [[AI Extract]]) can achieve similar results with nowhere near the amount of set up.
			All three of these node types perform a similar function. They return data from documents. However, they differ in their configuration and utility.

	Extractor ~~nodes~~ are tools to extract/return data. ~~Ultimately~~, "[[Data ~~Element~~]]s" are ~~what collects~~ data. ~~They~~ may ''~~use'~~' extractor ~~nodes to help collect data~~ in ~~a '''Data Model'''~~.		Extractor Nodes are tools to extract/return document data. But they don't do anything by themselves. They are used by extractor properties on other nodes in Grooper.
			* Example: [[Data Element]]s, such as [[Data Field]]s, are ultimately collect document data. It is the Data Field's "Value Extractor" configuraiton that does this. However, you may configure a Data Field's Value Extractor with an Extractor Node to do so.
			* Example: The [[Pattern-Based Separation]] provider's "Value Extractor" is ultimately what identifies patterns to separate Batch Pages into Batch Folders. However, you may configure the Value Extractor with an Extractor Node to do so.
			* Example: When [[Classify]] runs on a document, a [[Document Type]]'s "Positive Extractor" will be used to assign a Batch Folder the Document Type if it returns a value. You may configure the Positive Extractor with an Extractor Node to do so.
			* And so on and so on for any extractor property for any node in Grooper.

	To that end, ~~extractor nodes~~ serve three purposes:
			To that end, Extractor Nodes serve three purposes:
	# To be re-usable units of extraction		# To be re-usable units of extraction
	# To collate data		# To collate data
	# To leverage machine learning algorithms to target data in the flow of text		# To leverage machine learning algorithms to target data in the flow of text
			#*<li class="attn-bullet"> Advances in large-language models (LLMs) have largely made Field Classes obsolete. LLM-based extraction methods in Grooper (such as [[AI Extract]]) can achieve similar results with nowhere near the amount of set up.
	<div style="padding-left: 1.5em">		<div style="padding-left: 1.5em">

	=== Re-usability ===		=== Re-usability ===
	Extractor nodes are meant to be referenced either by other extractor nodes or, importantly, by Data Elements such as '''Data Fields''' in a '''Data Model'''.		Extractor nodes are meant to be referenced either by other extractor nodes or, importantly, by Data Elements such as '''Data Fields''' in a '''Data Model'''.

Dgreenwood: /* Extractor Nodes vs Value Extractors */

2025-08-06T21:04:49Z

Extractor Nodes vs Value Extractors

← Older revision		Revision as of 16:04, 6 August 2025
Line 41:		Line 41:
	* collation		* collation
	* machine learning		* machine learning
			**<li class="attn-bullet"> Advances in large-language models (LLMs) have largely made Field Classes obsolete. LLM-based extraction methods in Grooper (such as [[AI Extract]]) can achieve similar results with nowhere near the amount of set up.

	=== Related Node Types ===		=== Related Node Types ===

Dgreenwood: /* Machine learning */

2025-08-06T21:04:38Z

Machine learning

← Older revision		Revision as of 16:04, 6 August 2025
Line 27:		Line 27:
	=== Machine learning ===		=== Machine learning ===
	Many documents contain important pieces of information buried within the flow of text, like a legal document. These types of documents and the data they contain require an entirely different approach to extracting data than a highly structured document like an invoice. For these situations you can use a "trainable" extractor known as a '''Field Class''' to leverage machine learning algorithms to target important information.		Many documents contain important pieces of information buried within the flow of text, like a legal document. These types of documents and the data they contain require an entirely different approach to extracting data than a highly structured document like an invoice. For these situations you can use a "trainable" extractor known as a '''Field Class''' to leverage machine learning algorithms to target important information.
			*<li class="attn-bullet"> Advances in large-language models (LLMs) have largely made Field Classes obsolete. LLM-based extraction methods in Grooper (such as [[AI Extract]]) can achieve similar results with nowhere near the amount of set up.

	=== Extractor Nodes vs Value Extractors ===		=== Extractor Nodes vs Value Extractors ===

Dgreenwood: /* Extractor Nodes vs Value Extractors */

2025-08-06T21:02:12Z

Extractor Nodes vs Value Extractors

← Older revision		Revision as of 16:02, 6 August 2025
Line 36:		Line 36:
	* Example" "Field Classes" cannot function without its "Value Extractor" and "Feature Extractor" properties configured, both of which specify a Value Extractor.		* Example" "Field Classes" cannot function without its "Value Extractor" and "Feature Extractor" properties configured, both of which specify a Value Extractor.

	However, ~~extractor nodes~~ are used when you need to ''reference'' them for their designated strengths:		However, Extractor Nodes are used when you need to ''reference'' them for their designated strengths:
	* re-usability		* re-usability
	* collation		* collation

Dgreenwood at 21:01, 6 August 2025

2025-08-06T21:01:35Z

← Older revision		Revision as of 16:01, 6 August 2025
Line 3:		Line 3:
	== About ==		== About ==
	<section begin="Extractor Nodes" />		<section begin="Extractor Nodes" />
			=== Types of Extractor Nodes ===
	There are three types of Extractor Nodes in '''Grooper''':		There are three types of Extractor Nodes in '''Grooper''':
	: {{ValueReaderIcon}} '''[[Value Reader]]'''		: {{ValueReaderIcon}} '''[[Value Reader]]'''

Dgreenwood: Created page with "
{{#lst:Glossary|Extractor Node}}
== About ==
There are three types of Extractor Nodes in '''Grooper''': : {{ValueReaderIcon}} '''Value Reader''' : {{DataTypeIcon}} '''Data Type''' : {{FieldClassIcon}} '''Field Class''' ''Uncommonly used in current Grooper implementations'' All three of these node types perform a similar function. They are configured to return data from documents. However, they diff..."

2025-08-06T20:08:10Z

Created page with "<blockquote>{{#lst:Glossary|Extractor Node}}</blockquote> == About == <section begin="Extractor Nodes" /> There are three types of Extractor Nodes in '''Grooper''': : {{ValueReaderIcon}} '''Value Reader''' : {{DataTypeIcon}} '''Data Type''' : {{FieldClassIcon}} '''Field Class''' ''Uncommonly used in current Grooper implementations'' All three of these node types perform a similar function. They are configured to return data from documents. However, they diff..."

New page

<blockquote>{{#lst:Glossary|Extractor Node}}</blockquote>

== About ==
<section begin="Extractor Nodes" />
There are three types of Extractor Nodes in '''Grooper''':
: {{ValueReaderIcon}} '''[[Value Reader]]'''
: {{DataTypeIcon}} '''[[Data Type]]'''
: {{FieldClassIcon}} '''[[Field Class]]''' ''Uncommonly used in current Grooper implementations''
All three of these node types perform a similar function. They are configured to return data from documents. However, they differ in their configuration and data extraction purpose.

Extractor nodes are tools to extract/return data. Ultimately, "[[Data Element]]s" are what collects data. They may ''use'' extractor nodes to help collect data in a '''Data Model'''.

To that end, extractor nodes serve three purposes:
# To be re-usable units of extraction
# To collate data
# To leverage machine learning algorithms to target data in the flow of text
<div style="padding-left: 1.5em">
=== Re-usability ===
Extractor nodes are meant to be referenced either by other extractor nodes or, importantly, by Data Elements such as '''Data Fields''' in a '''Data Model'''.

For example, an individual '''Data Field''' can be configured on its own to collect a date value, such as the "Received Date" on an invoice. However, what if another '''Data Field''' is collecting a different date format, like the "Due Date" on the same invoice? In this case you would create one extractor node, like a '''Value Reader''', to collect any and all date formats. You could then have each '''Data Field''' reference that ''single'' '''Value Reader''' and further configure each individual '''Data Field''' to differentiate their specific date value.

=== Data collation ===
Another example would be configuring a '''Data Type''' to target entire rows of information within a table of data. Several '''Value Reader''' nodes could be made as children of the '''Data Type''', each targeting a specific value within the table row. The parent '''Data Type''' would then collate the results of its child '''Value Reader''' nodes into one result. A '''Data Table''' would then reference the '''Data Type''' to collect the appropriate rows of information.

=== Machine learning ===
Many documents contain important pieces of information buried within the flow of text, like a legal document. These types of documents and the data they contain require an entirely different approach to extracting data than a highly structured document like an invoice. For these situations you can use a "trainable" extractor known as a '''Field Class''' to leverage machine learning algorithms to target important information.

=== Extractor Nodes vs Value Extractors ===
Extractor nodes should not be confused with "Value Extractors". There are ''many'' places in '''Grooper''' where extraction logic can be applied for one purpose or another. In these cases a Value Extractor is chosen to define the logic required to return a desired value.

In fact, the Extractor Nodes themselves will leverage specific Value Extractors to define their logic.
* Example: "Value Readers" are configured using a single property "Extractor". This property specifies a single Value Extractor which determines how data is extracted. Value Readers are essentially an encapsulation of a single Value Extractor configuration that can be reused by multiple other extraction elements and properties, such as Data Fields and Data Types.
* Example: "Data Types" have several properties that can be configured with Value Extractors, including its "Local Extractor", "Input Filter", and "Exclusion Extractor" properties.
* Example" "Field Classes" cannot function without its "Value Extractor" and "Feature Extractor" properties configured, both of which specify a Value Extractor.

However, extractor nodes are used when you need to ''reference'' them for their designated strengths:
* re-usability
* collation
* machine learning

=== Related Node Types ===
<div style="padding-left: 1.5em">
==== Value Reader ====
{{#lst:Glossary|Value Reader}}

==== Data Type ====
{{#lst:Glossary|Data Type}}

* For example, if you're extracting a date that could appear in multiple formats within a document, you'd use various extractor nodes (each capturing a different format) as children of a '''Data Type'''.

The '''Data Type''' also defines how to collate results from one or more extractors into a referenceable output. The simplest type of collation (''Individual'') would just return all individual extractors' results as a list of results.

'''Data Types''' are also used for recognizing complex 2D data structures, like address blocks or table rows. Different collation methods would be used in these cases to combine results in different ways.

==== Field Class ====
{{#lst:Glossary|Field Class}}
</div>
</div>
<section end="Extractor Nodes" />