🕸️ Knowledge Graph Extractor - Entities & Typed Relationships
Pricing
Pay per event
🕸️ Knowledge Graph Extractor - Entities & Typed Relationships
🕸️ Crawl a site or corpus and get back a real graph: typed ENTITIES and typed RELATIONSHIPS, no LLM. ✅ JSON-LD first, then headings/tables/breadcrumbs/pricing tables. ✅ Cross-page entity resolution merges aliases into one node. ✅ Edges built from structure, every one with an evidenceUrl.
Pricing
Pay per event
Rating
0.0
(0)
Developer
mohamed alaya
Maintained by CommunityActor stats
0
Bookmarked
2
Total users
1
Monthly active users
5 days ago
Last modified
Categories
Share
Knowledge Graph Extractor
Crawl a site (or hand over a corpus directly) and get back a real graph: typed entities and typed relationships, deterministically, with no LLM and no NER model anywhere in the pipeline.
What it actually does
1. Entity extraction without an NER model. JSON-LD/schema.org blocks are
read first (highest precision, reusing the same jsonLdBlocks parser
structured-data-generator and llms-txt-generator rely on). Wherever a page has
no JSON-LD, structural signals fill the gap instead of free-text NLP: heading
hierarchy, breadcrumbs, tables (including pricing tables), definition lists,
and — as a last resort — capitalised multiword phrases in body text, filtered
by a stopword guard so sentence starts don't get scooped up as entities.
2. Eight entity types. Organization, Product, Feature, Person, Location,
PricingPlan, Technology, Document. schema.org @types map onto these
directly; structural signals get a lightweight heuristic classifier (legal
suffixes -> Organization, API/SDK/Platform-style words -> Technology, country
names and street/city words -> Location, two-to-three-word Title Case names ->
Person, plan-ish words like Free/Pro/Enterprise -> PricingPlan).
3. Relationships from structure, never from parsing free text. Breadcrumb
trail -> parentOf chain. A table's own layout -> row/column edges, or, when
the table looks like a pricing grid,
PricingPlan -[includesFeature]-> FeatureH2 under H1 -> partOf. A JSON-LD Product's
additionalProperty list -> Product -[hasFeature]-> Feature. Every entity
pair that shares a page also gets a weak coOccursWith edge (capped per page,
can be turned off). Every single edge carries the evidenceUrl of the
page it was observed on plus a confidence score.
4. Entity resolution across pages. "Acme Corp" on one page and "ACME,
Inc." on another collapse into one node — reusing entity-resolver's own
normalizeCompany (legal-suffix stripping) and normalizePerson (nickname
expansion) for the exact-match pass, then a Jaro-Winkler fuzzy pass
(resolutionThreshold, default 0.90) inside the same type for spelling drift
that survives normalisation. The merged node keeps every distinct spelling it
was seen with as an aliases list, plus every page it was mentioned on as
sourceUrls.
Input
Either crawl a live site:
or hand over the corpus directly (also how the offline test suite runs it):
Both can be combined — inline pages are extracted alongside anything
crawled from siteUrl.
Output
node rows: id, label, nodeType, aliases, sourceUrls, mentionCount.
edge rows (the flat edge-list, ready to import into any graph tool):
from, edgeType, to, evidenceUrl, confidence, value. One summary row with
counts by type, counts by edge type, and the most-connected nodes.
outputMode can restrict the run to nodesOnly or edgesOnly.
Honest limitations
- This is structural extraction, not NLP or NER. There is no language model reading sentences for meaning — every entity comes from a schema.org tag, a heading, a table cell, a breadcrumb, or a capitalised phrase pattern. A page that is one giant unstructured wall of prose with no markup, no headings and no JSON-LD will yield a thin or empty graph. Recall tracks how well-structured the source site is, not how "important" the entities are.
- The capitalised-phrase heuristic is the noisiest source by design and is
gated by
minPhraseMentions(default: a phrase must appear at least twice across the whole corpus to survive) — raise it further on prose-heavy sites, or disable the heuristic entirely withextractCapitalizedPhrases: false. - Person detection from free text is a coarse two/three-Title-Case-word pattern, not a real name model — it will occasionally misfire on brand names that happen to look like "Firstname Lastname".
- Entity resolution merges within a type only. A
Productnamed "Acme" and anOrganizationnamed "Acme" are never merged into one node, even though a reader would recognise them as related — cross-type identity is out of scope here. - Nav/header/footer/sidebar/cookie-banner/social-share regions are stripped
before any extraction runs, so site chrome should never surface as an
entity — but a site that puts real content inside a
<nav>or<footer>tag will lose that content along with the boilerplate.
