{
  "source_file": "0930",
  "source_platform": "Dev.to",
  "author": "Tae Kim",
  "title_listed": "Building an investing knowledge graph, part 3: same company, seven names",
  "keywords": "",
  "domain": "文本处理",
  "content_type": "深度技术解析",
  "is_paid_flag": "否",
  "url": "https://dev.to/hannune/building-an-investing-knowledge-graph-part-3-same-company-seven-names-b7d",
  "publish_date": "2026-08-31",
  "corpus_stage": "",
  "notes": "",
  "id": "398406bb8442",
  "collected_at": "2026-10-02T14:03:50",
  "title": "Building an investing knowledge graph, part 3: same company, seven names - DEV Community",
  "body_markdown": "Building an investing knowledge graph, part 3: same company, seven names\nI noticed a problem because a traversal that had been working stopped returning results. The ASML supply chain path I'd tested a week earlier came back empty. I spent a while thinking I'd broken the query. The query was fine. What had happened was that a new batch of articles from a different source used \"the Dutch lithography equipment maker\" and \"ASML Holding NV\" without ever using the string \"ASML.\" Both landed in the graph as separate nodes. The traversal starting from the ASML node I'd been accumulating edges on couldn't reach them.\nSeven names for one company\nWhen I checked the Samsung Electronics entry in the registry, it had resolved seven distinct aliases to a single entity:\n\"samsung\"\n\"samsung electronics\"\n\"samsung electronics co.\"\n\"samsung foundry\"\n\"samsung's\"\n\"the korean company\"\n\"the largest memory chipmaker in the world\"\nEnter fullscreen mode\nExit fullscreen mode\nThe foundry alias is a judgment call I went back on twice -- Samsung Foundry is technically a division with its own reporting, but in this corpus it was mostly used as shorthand for the parent in manufacturing capacity articles, so I kept it merged. The descriptive ones at the bottom are wire service shorthand. An article that opened with \"Samsung Electronics\" in the headline would use \"the Korean company\" three paragraphs later. Standard string matching returns near-zero similarity between \"the largest memory chipmaker in the world\" and \"samsung electronics.\" They share no tokens.\nBefore I had a proper setup for this, I was using token overlap to match entity mentions. The threshold was loose enough to catch most of the alias variations above. It was also loose enough to merge Samsung SDI into Samsung Electronics.\nSamsung SDI makes batteries. It is a separate publicly listed company. A lithium cell supply disruption hitting Samsung SDI's production line has nothing to do with Samsung Electronics' memory fab utilization. If those two ended up as the same node, events from one would show up in traversals that started from the other. I caught this specific case because I happened to be running a check on Samsung when a battery shortage article came through. Whether there are other pairs like this that I haven't caught, I genuinely don't know.\nThe descriptive ASML alias fails because it shares no tokens with the canonical name. Samsung SDI fails to separate because it shares the most salient token with an entity it should be distinct from. There's no threshold value that handles both. Loosening the threshold enough to catch the first kind of failure causes more of the second. These are actually different problems.\nWhat Splink does with this\nSplink\ntreats entity resolution as a classification problem. For any candidate pair of mentions, the model computes a match probability using multiple features simultaneously and learns weights from a training set of confirmed pairs and non-matches.\nFor corporate entities in news text, the features I ended up using: canonical name similarity is the obvious starting point -- it handles \"Samsung Electronics Co.\" but not \"the largest memory chipmaker in the world.\" For descriptive references, alias coverage matters more: once a mention form has been confirmed as belonging to a given entity, future occurrences match by lookup. The ASML case gets better over time this way, even though the string overlap never improves.\nFor the Samsung SDI case, what made the difference was article-level context. An article that mentions DRAM yields and fab capacity almost certainly isn't about the battery subsidiary. Whether that context gets encoded as co-occurring industry terms or co-mentioned company names is a feature engineering choice; either way, it's information that string matching on the entity name alone can't see. I also added a base-rate feature after a few early merges looked wrong -- a rare entity with one mention shouldn't get absorbed into a high-frequency entity just because they share a token.\nSplink learned weights across all of this from a training set of a few hundred manually verified pairs from the early corpus. Not large. But enough to get the Samsung SDI case right once I included the context features, which I hadn't initially.\nThe registry now has 47,853 resolved entities. That number has been climbing -- each new article either matches an existing entity or creates a new node that might get merged later as evidence accumulates. A few merges from early on are probably still wrong. Some entries I initially kept separate have since merged when more articles came in.\nStill a threshold\nSplink produces a probability, not a final answer. You still decide where to cut.\nFor this graph, I set that conservatively. A pair below a certain value stays split. Some valid aliases end up never linking to their entity -- nodes with few edges that mostly sit disconnected. I ran a check on a sample and most looked like genuine unknowns where there wasn't enough article evidence to confirm the connection. A few were probably real aliases I missed. That's the tradeoff: some fragmentation, in exchange for higher confidence that a merged entity represents one thing.\nHow that threshold gets set in practice, and what happens to the registry as new articles change the evidence picture, is part 4.\nBuilt on\nSplink\nfor probabilistic record linkage. Part 1 is\nhere\n. Part 2 is\nhere\n.",
  "metadata": {
    "title": "Building an investing knowledge graph, part 3: same company, seven names - DEV Community",
    "description": "When entity resolution fails, the same company becomes seven different graph nodes. What that looks like in practice, using Samsung Electronics, Samsung SDI, and ASML. Tagged with graphdb, knowledgegraph, dataengineering, entityresolution.",
    "keywords": "graphdb, knowledgegraph, dataengineering, entityresolution, software, coding, development, engineering, inclusive, community",
    "author": null,
    "og:type": "article",
    "og:url": "https://dev.to/hannune/building-an-investing-knowledge-graph-part-3-same-company-seven-names-b7d",
    "og:title": "Building an investing knowledge graph, part 3: same company, seven names",
    "og:description": "When entity resolution fails, the same company becomes seven different graph nodes. What that looks like in practice, using Samsung Electronics, Samsung SDI, and ASML.",
    "og:site_name": "DEV Community",
    "og:image": "https://media2.dev.to/dynamic/image/width=1200,height=627,fit=cover,gravity=auto,format=auto/https%3A%2F%2Fimages.unsplash.com%2Fphoto-1639322537228-f710d846310a%3Fixid%3DM3w5NjA5Njd8MHwxfGFsbHx8fHx8fHx8fDE3ODgxNDQ5NzJ8%26ixlib%3Drb-4.1.0%26w%3D1200%26h%3D630%26fit%3Dcrop",
    "twitter:site": "@thepracticaldev",
    "twitter:creator": "@HannuneTech",
    "twitter:title": "Building an investing knowledge graph, part 3: same company, seven names",
    "twitter:description": "When entity resolution fails, the same company becomes seven different graph nodes. What that looks like in practice, using Samsung Electronics, Samsung SDI, and ASML.",
    "twitter:card": "summary_large_image",
    "twitter:widgets:new-embed-design": "on",
    "twitter:image:src": "https://media2.dev.to/dynamic/image/width=1200,height=627,fit=cover,gravity=auto,format=auto/https%3A%2F%2Fimages.unsplash.com%2Fphoto-1639322537228-f710d846310a%3Fixid%3DM3w5NjA5Njd8MHwxfGFsbHx8fHx8fHx8fDE3ODgxNDQ5NzJ8%26ixlib%3Drb-4.1.0%26w%3D1200%26h%3D630%26fit%3Dcrop"
  },
  "paywall": {
    "listed_paid": false,
    "detected": false,
    "marker": "",
    "public_only": false,
    "policy": "付费/会员内容只保留页面公开可见部分，不绕过付费墙"
  },
  "crawl": {
    "success": true,
    "status_code": 200,
    "error": ""
  },
  "code_blocks": [
    {
      "file": "attachments/398406bb8442/code/body-000.txt",
      "chars": 153,
      "language": "text"
    }
  ],
  "images": [],
  "audio": [],
  "videos": [],
  "links": [
    {
      "href": "https://github.com/moj-analytical-services/splink",
      "label": "Splink",
      "type": "a"
    },
    {
      "href": "https://dev.to/hannune/building-an-investing-knowledge-graph-part-1-from-does-this-news-matter-to-a-graph-i-can-query-11bi",
      "label": "here",
      "type": "a"
    },
    {
      "href": "https://dev.to/hannune/building-an-investing-knowledge-graph-part-2-the-query-sql-cant-answer-l9f",
      "label": "here",
      "type": "a"
    }
  ],
  "repair_version": 2,
  "repaired_at": "2026-10-14T10:49:38Z",
  "source_url": "https://dev.to/hannune/building-an-investing-knowledge-graph-part-3-same-company-seven-names-b7d",
  "papers": [],
  "actual_video_files": [],
  "body_chars": 5436,
  "expected_body_images": 0,
  "discovery_status": "ok",
  "delivery_status": "ok",
  "missing_reason": "",
  "raw_html": "attachments/398406bb8442/pages/source.html",
  "local_html": "attachments/398406bb8442/pages/article.html",
  "body_base_path": "attachments/398406bb8442/pages/",
  "body_markdown_path": "attachments/398406bb8442/pages/article.md"
}