Run the pattern and Neo4j hands back path objects rather than tuples [1][2]. The load-bearing part is not the variable-length arrow, it is the two list comprehensions in the RETURN clause: `[r IN relationships(path) | r.article_id]` walks every edge of a matched path and pulls the article that established it, and its sibling does the same for `event_date` [1]. A four-hop result therefore arrives carrying four article IDs and four dates, one per link, instead of a single provenance stamp on the endpoint [2]. With the `LIMIT 30` in place, one run can return up to 120 article references for a human to check [5].
The two attempts that failed did so for unrelated reasons, which is easy to lose in the retelling. Elasticsearch was asked a question about text and answered it: fourteen documents matched the phrasing, and the NVIDIA articles were not among them because NVIDIA is not named in any of them [6][7]. The author is explicit that relevance tuning would not have closed that gap [7]. SQL failed on two counts. The visible one is hop count, two CTEs for two hops, three for three, depth fixed before the query runs [10]. The quieter one is arity: an article describing an event involving three or four companies does not reduce to one subject-object row without discarding something [13]. Worth noting that the Cypher pattern also runs company to company [1], so a four-participant event still has to be decomposed into pairwise edges or into an event node the post does not show. The graph relaxes the row shape, but modeling an event with four participants takes more structure than that alone provides [13].
The ratios are worth doing. 275,293 relationships over 9,414 articles is 29.2 edges per article [1]; 84,962 nodes over the same corpus is 9.0 nodes per article [2]; the graph averages 3.2 relationships per node [3]. That density is a claim about an extraction pipeline, not about Neo4j. For it to transfer, your articles would have to name companies at a similar rate and your extractor would have to be as willing to emit an edge. No precision figure is reported for any of the 275,293 [14], and a bad edge does not look bad in the output; it looks like a path with an article ID attached [2].
Latency is the figure missing here. Response time on the Cypher query is described as acceptable, but the post gives no number, no hardware detail, and no comparison against a deeper bound [15]. A benchmark table would at least be something to argue with. What the post does name as the unfinished dependency is entity resolution: the traversal only works if the same company maps to the same node however an article refers to it, and that did not happen automatically [17]. Filings say ASML Holding NV, a wire shortens it to ASML, and a blog post never names the company and calls it the Dutch lithography equipment maker [18]. Left unresolved those are three nodes, and the source text breaks off mid-sentence on exactly that failure [19].
The semantics of an empty result are stated carefully, and that carries more weight than it sounds: no path returned means the graph holds no evidence for the connection, not that the connection is absent in the world [16]. Combined with a depth bound tuned at query time [3], that supports an honest workflow. Ask at four hops, ask at six, and read both answers as statements about corpus coverage rather than about semiconductors. It also means the graph inherits every gap in the 9,414 articles [5], which is a fair trade for a research tool and a poor one for anything that has to be right before someone opens the cited articles.
