#4590 Knowledge Graph: Thomas Edison and Nikola Tesla Patents

#4590 The following web page lists all of Thomas Edison's and Nikola Tesla's patents: https://en.wikipedia.org/wiki/List_of_Edison_patents and https://en.wikipedia.org/wiki/List_of_Nikola_Tesla_patents. How can I create a knowledge graph of his patents and use it to identify patterns of invention.

Deconstructing tabular historical data into a high-density, semantic graph database is an exceptionally powerful approach for identifying structural trends in innovation. By treating patents as a networked canvas of inventors, temporal sequences, and technological subsystems, you can transcend basic chronological lists and reveal the systemic archetypes of how Edison and Tesla built their intellectual empires.

Here is a step-by-step engineering blueprint to design, populate, and analyze a patented knowledge graph using Neo4j and Cypher.

Phase 1: Semantic Data Modeling (Ontology)

To capture the underlying mechanics of invention—including evolution over time, co-invention, and technological convergence—you need an ontology that supports both discrete attributes and rich relationships.

1. Node Labels (`:` Labels)

:Inventor – The human agent (e.g., name: "Nikola Tesla", birth_year: 1856).
:Patent – The primary asset (e.g., id: "US381968", title: "Electro magnetic motor", date_filed: "1887-10-12", date_issued: "1888-05-01").
:Domain – High-level technical classifications (e.g., name: "Telegraphy", name: "Polyphase Systems", name: "Acoustics").
:Component – Specific sub-mechanisms or concepts extracted from titles/abstracts (e.g., name: "Armature", name: "Commutator", name: "Carbon Filament").
:Assignee – Corporate entities or investors who backed the patent (e.g., name: "Edison Electric Light Co.", name: "Westinghouse Electric").

2. Relationship Types (`-[:TYPE]->`)

(:Inventor)-[:INVENTED]->(:Patent)
(:Inventor)-[:PARTNERED_WITH]->(:Inventor) (Can be derived or explicitly stored with properties like on_patent: "US102320")
(:Patent)-[:CLASSIFIED_UNDER]->(:Domain)
(:Patent)-[:UTILIZES]->(:Component)
(:Patent)-[:ASSIGNED_TO]->(:Assignee)
(:Patent)-[:EVOLVED_INTO]->(:Patent) (Temporal chaining of subsequent or derivative designs)

Phase 2: Data Extraction & Pipeline

Because Wikipedia data is cleanly structured in HTML tables, your ingestion pipeline can use standard Python toolsets to scrape, clean, and format the data before sending it to Neo4j.

Extraction: Use pandas.read_html() or BeautifulSoup to parse the Wikipedia tables. Capture the Patent Number, Title, Application/Filing Date, Issue Date, and any notes (which often contain co-inventor names like Franklin L. Pope for Edison).
Entity Resolution & Cleaning: Clean the patent IDs to standard formats (e.g., stripping commas to get integer or alphanumeric formats like US381968).
Domain Tagging: You can build a small dictionary to auto-tag rows based on string matching in titles (e.g., titles containing "Telegraph" $\to$ :Domain {name: "Telegraphy"}; "Motor" or "Dynamo" $\to$ :Domain {name: "Rotary Electrical Machinery"}). For deep analytical precision, pass the titles/descriptions through a local LLM to map them into functional domains or extract key physical components.

Phase 3: Graph Construction (Cypher Ingestion)

Assuming you output your cleaned data into CSV files (edison_patents.csv, tesla_patents.csv), you can ingest them into a local Neo4j instance using the following patterns:

// 1. Enforce Constraints
CREATE CONSTRAINT UNIQUE_PATENT_ID IF NOT EXISTS
FOR (p:Patent) REQUIRE p.id IS UNIQUE;

// 2. Load Tesla's Patents
LOAD CSV WITH HEADERS FROM 'file:///tesla_patents.csv' AS row
MERGE (i:Inventor {name: "Nikola Tesla"})
MERGE (p:Patent {id: row.PatentNumber})
ON CREATE SET 
    p.title = row.Title,
    p.year = toInteger(row.Year),
    p.date_issued = date(row.IssueDate)

MERGE (i)-[:INVENTED]->(p)

// Dynamic Domain Separation
MERGE (d:Domain {name: row.DerivedDomain})
MERGE (p)-[:CLASSIFIED_UNDER]->(d);

Temporal Chaining (Connecting the Lineage)

To map the evolutionary velocity of their ideas, connect each inventor's patents chronologically:

MATCH (i:Inventor {name: "Nikola Tesla"})-[:INVENTED]->(p:Patent)
WITH p ORDER BY p.date_issued ASC
WITH collect(p) AS patents
UNWIND range(0, size(patents)-2) AS idx
WITH patents[idx] AS current, patents[idx+1] AS next
MERGE (current)-[:EVOLVED_INTO]->(next);

Phase 4: Identifying Patterns of Invention

With the graph wired up, you can use Cypher and Neo4j's Graph Data Science (GDS) library to uncover structural patterns.

1. Tracking Domain Migration (Pivot Dynamics)

How did an inventor pivot from one industry to another over time? This query isolates periods of intense context-switching versus sustained domain iteration:

MATCH (i:Inventor)-[:INVENTED]->(p1:Patent)-[:CLASSIFIED_UNDER]->(d1:Domain)
MATCH (p1)-[:EVOLVED_INTO]->(p2:Patent)-[:CLASSIFIED_UNDER]->(d2:Domain)
WHERE i.name = "Thomas Edison" AND d1 <> d2
RETURN p1.year AS PivotYear, d1.name AS FromDomain, d2.name AS ToDomain, count(*) AS Frequency
ORDER BY PivotYear ASC;

Insight: This will vividly illustrate Edison's structural transition from printing telegraphs in the early 1870s to acoustic phonographs and incandescent systems by the turn of the decade.

2. Identifying "Linchpin" Patents (Centrality & Degree)

By running Degree Centrality or parsing localized component reuse, you can identify which specific patents served as structural platforms for an entire ecosystem of subsequent variants. If a single foundational patent maps to multiple component nodes that are repeatedly referenced down the temporal chain, that patent is a architectural bottleneck.

MATCH (p:Patent)-[:UTILIZES]->(c:Component)<-[:UTILIZES]-(other:Patent)
RETURN p.id AS FoundationPatent, p.title AS Title, count(distinct other) AS DownstreamDependents
ORDER BY DownstreamDependents DESC LIMIT 10;

3. Analyzing Structural Contradictions & Modality (Tesla vs. Edison)

You can apply structural network metrics to compare their respective inventive styles:

The Solitary Genius vs. The R&D Factory: Query the degree of the PARTNERED_WITH relationship. Edison's graph will immediately bloom into a dense, hub-and-spoke cluster featuring co-inventors, assistants, and assignees (e.g., Charles Batchelor, Upton, Pope), demonstrating a factory-model approach to innovation. Tesla's graph will appear highly linear and isolated, demonstrating a solitary, continuous system-architecture approach.
Component Monogamy vs. Polygamy: Look at how fluidly components bridge separate domains. Tesla’s components (like "Rotating Magnetic Field") will show highly tight, mathematically unified topologies across power transmission and motor control, while Edison's components (like "Carbon") switch fluidly from acoustic microphones to vacuum lamp filaments—indicative of an empirical, trial-and-error optimization strategy.

From <https://gemini.google.com/app/> Google Gemini (3.5 Flash)

Search This Blog

Learning from ChatGPT