Rule-Based Information Extraction and Relation Patterns

MetaCyberGuru Academy

IntermediateEstimated learning effort: 65 minutesFree, no sign-up requiredPublished by Muhammad AzharCourse version: August 2026

Back to Linguistic Analysis and Information Extraction

Rules remain valuable when the target has stable language, limited data and a need for explanations, but they need tests and abstention paths.

Token rules can match lemmas, part-of-speech tags, dependencies and nearby phrases. They usually outperform a giant raw-text regex once spacing and inflection vary.

A rule should emit evidence, rule ID and confidence class. That lets reviewers see why the record exists and lets developers measure each rule separately.

Turn Domain Language into Auditable Extraction Rules

  • Write a token pattern for a narrow business relation.
  • Return evidence spans and a rule identifier instead of a bare value.
  • Prefer a small tested rule set over hundreds of interacting exceptions.
  • Test each relation rule against a positive example, a near miss and a deliberate counterexample.

Choose a relation you can define

Purchase, employment and version references have different arguments. Write the output schema before the pattern.

Include counterexamples such as planned to buy or did not acquire so the rule does not confuse mention with fact.

Layer deterministic and statistical methods

Use rules for stable formats and precise language. Use a model for varied wording, then route low-confidence cases to review.

Negation and scope matter

The word not can modify a distant predicate. A local window rule may still misread reported speech or hypothetical language.

Treat extracted relations as claims supported by text, not verified facts about the world.

Version every rule

Store a rule ID with output and keep an example suite for each revision.

Compare rule-level precision before adding coverage.

Build the Rule-Based Information Extraction and Relation Patterns example

The rule matches a version cue followed by a constrained version token. It does not pretend to understand deployment status.

Return offsets so a reviewer can read the phrase in context. Add document ID and rule version in a real output record.

Install:

python -m pip install spacy
python -m spacy download en_core_web_sm
import spacy
from spacy.matcher import Matcher
nlp = spacy.load('en_core_web_sm')
matcher = Matcher(nlp.vocab)
matcher.add('PRODUCT_VERSION', [[
    {'LOWER': {'IN': ['version','release']}},
    {'TEXT': {'REGEX': r'^v?\d+(?:\.\d+){0,2}$'}}
]])
text = 'We deployed version 3.2.1, but version soon is not a valid match.'
doc = nlp(text)
for match_id, start, end in matcher(doc):
    span = doc[start:end]
    print(nlp.vocab.strings[match_id], span.text, span.start_char, span.end_char)

Expected Relation Records and Evidence Spans

PRODUCT_VERSION version 3.2.1 12 25

Test release v2, version 3, malformed versions and negated sentences. Decide which are valid for your schema.

If version formats are governed by a product registry, validate the candidate against that registry after extraction.

Diagnose failures in Rule-Based Information Extraction and Relation Patterns

Run positive and negative examples per rule and report results by rule ID.

Checks for the Rule-Based Information Extraction and Relation Patterns example
SymptomLikely causeUseful check
A rule matches version soonA wildcard token is too broadConstrain token text and add a negative regression case
A valid 3.2.1-beta is missedThe accepted version grammar excludes suffixesUpdate the documented grammar only if the product supports them
Output implies deployment happenedThe matcher identifies a mention, not event truthName the field version_mention or add a separate event-status classifier

Build a version-mention extractor

Define the version formats used by one real or sample product and create a reviewed test suite.

  1. Write the output schema and rule ID
  2. Add fifteen positive and fifteen negative examples
  3. Emit text, offsets and surrounding sentence
  4. Report precision and recall on the suite

Definition of done: The extractor passes documented cases and labels its output as a mention rather than a verified deployment event.

Stretch task: Add a second rule for product name plus version and resolve overlapping matches deterministically.

Check your Rule-Based Information Extraction and Relation Patterns reasoning

Evaluate the rule boundaries before opening the explanations. The cases test negation, scope and versioned pattern behaviour.

1. Why store a rule ID with each result?
Check the answer

Answer: To trace, debug and measure the exact rule that produced the result.

2. What does the sample pattern prove?
Check the answer

Answer: Only that a matching version phrase occurred in the text.

3. What is a useful negative example?
Check the answer

Answer: A realistic near-match that the rule must reject.

Primary references for Rule-Based Information Extraction and Relation Patterns

Review the extractor whenever domain terminology or spaCy matching behaviour changes. Keep the rule version and false-match ledger with the release.

Save your place

Completion is stored only in this browser on this device.

Share this page

Share this page with the people who will use it next.

X Facebook LinkedIn WhatsApp Email

Discussion

No comments yet. Add the first useful question or observation.