We learn about "rules and recommendations for the naming of node labels, relationship types, property names, variables, indexes, and constraints". page 
> Names should not begin with a number. To illustrate, `1first` is not allowed, whereas `first1` is allowed.
Within the Paragraph Recommendation Viewer searchGraph context, we understand that paragraph IDs should not be used as types because paragraph IDs could begin with a number, which is not allowed in Cypher, and ask: Where do we create such nodes? See Speed Bot (speed-bot.html , addNode function)
function addNode(node, nodeProperties){ console.log("addNode reached"); // Add the node to the graph const newNodeId = graph.addNode(node, 0, 0, nodeProperties); console.log(`Node "${node}" (${newNodeId}) added`); serializeGraphAsJSONL(graph); return newNodeId; }
We call
addNode(type, props={}){ const obj = {type, in:[], out:[], props}; this.nodes.push(obj); return this.nodes.length-1; }
defined in Ward's graph.js. See Property Graphs as Javascript Module
But,
> Nodes have "labels", not "types" (the latter term only applies to relationships).
See "How do I check the type of a node in cypher?" stackoverflow
Ich muss die Behauptungen über Benennungsregeln in Neo4j und Cypher überprüfen, wie z. B. dass Namen nicht mit Zahlen beginnen dürfen und ob es spezielle Regeln für Labels, Beziehungstypen oder Variablen gibt. Auch, ob Node-IDs mit Zahlen beginnen können. Ich werde nach den genauen Regeln suchen und erklären, welche nicht falsifizierbar sind. Die Regel "Namen dürfen nicht mit einer Zahl beginnen" scheint zu streng zu sein – Backticks ermöglichen es, dies zu umgehen. Aber kann man das auch bei Labelnamen und Beziehungstypen tun? Ich erinnere mich an das Beispiel :123Label und -[:123]->. Ich muss das genauer prüfen und die Dokumentation dazu ansehen. Backticks können verwendet werden, um Einschränkungen zu umgehen. Die Behauptung, dass Absatz-IDs nicht als Typen verwendet werden sollten, ist korrekt – sie dürfen ohne Backticks nicht als Label oder Beziehungstyp verwendet werden. Doch in Neo4j können Knoten mehrere Labels haben, während Beziehungen einen einzigen Typ haben, was die Verwendung von "Typ" als Knotenbezeichner problematisch macht. Es stimmt, dass man Paragraph-IDs nicht direkt als Typen verwenden sollte, wenn sie mit Zahlen beginnen, es sei denn, man setzt sie in Backticks. In Neo4j haben Knoten mehrere Labels, aber Beziehungen nur einen Typ. Die Verwendung von "Typ" für einen Knotenbezeichner ist daher nicht konform mit der Neo4j-Semantik. Es scheint sinnvoll, Paragraphen-IDs nicht als Typen zu verwenden, da Cypher keine einfache Parametrisierung von Labels oder Beziehungstypen ohne dynamische Beschriftung unterstützt. Backticks ermöglichen zwar das Starten von Labels mit Zahlen, aber es ist besser, dies zu vermeiden, um Index- und Einschränkungsaufwand zu minimieren. Ich werde die offiziellen Dokumente überprüfen, um die genauen Namensregeln zu bestätigen. Verifizieren von Cypher Namensregeln und Quoting Suchen der offiziellen Namensregeln für Identifier Die Seite zeigt genau die Benennungsregeln, mit dem Hinweis, dass Namen zwar nicht mit einer Zahl beginnen sollten, aber durch Backticks non-alphabetische Zeichen erlaubt sind. Der Hinweis zu "sollte nicht Überprüfen von Namensregeln und Bezeichnern in Graphen Ich habe festgestellt, dass in Cypher Knoten Labels haben und Beziehungen einen Typ besitzen, der immer gerichtet ist. Es gibt auch dynamische Labels ab Version 5.26, aber das ist für unsere Anfrage nicht unbedingt erforderlich. Ich werde nun die "Cypher Cheat Sheet" prüfen, um Details zu den Labels zu bestätigen. Erstellen einer Cypher-Kurzreferenz für Knotenbezeichner Die Cheat Sheet zeigt also dynamische Labels und übereinstimmende Labels. Es gibt auch Hinweise zur Verwendung von Backticks für Labels und Beziehungstypen, was wichtig ist. Jetzt werde ich die Frage auf StackOverflow prüfen, ob Knoten Labels haben und keine Typen, um diese Information zu bestätigen. Durchsuchen des Webs nach Cypher-Node-Typen und Labels Ich habe jetzt genügend Quellen zu den wichtigsten Aussagen: Namensregeln und Backticks werden unterstützt (Quellen). Knoten haben Labels, Beziehungen haben einen Typ (Quellen). Beziehungen sind immer gerichtet. Ich werde erklären, dass bei Speed Bot Knoten im Browser bleiben und wie sie nach Neo4j übertragen werden. Ich werde die einzelnen Behauptungen überprüfen und klären, welche wahr oder falsch sind. Zur Erklärung: Ein Label wie "1first" ist nicht erlaubt, aber "first1" ist erlaubt (laut Neo4j-Namensregeln). Wir können das als falsifizierbar darstellen. Wenn Paragraphen-IDs als Typen verwendet werden, könnte die Aussage, dass sie nicht erlaubt sind, widersprochen werden, da sie mit Backticks erlaubt sind. Wir empfehlen, stattdessen die Eigenschaft "itemId" zu nutzen. Die Aussage über "Knotenmuster" im Cypher Cheat Sheet und die "Grundlegenden Eigenschaften des Property Graph Models" bezieht sich auf Konzepte, die einfach zitiert werden sollten. Zur Erstellung von Knoten in Speed Bot: In Ward's JS-Modul ist "type" ein beliebiges Feld, das beim Export nach Neo4j als Label oder 'type' Property zugewiesen wird. In Cypher, property keys can’t start with a number unless backticked. Property names are usually unquoted but can be enclosed in backticks if needed. Also, property keys in maps can't be parameterized, but dynamic properties can be set using bracket notation (n[$key] = value). I'll cite the naming page.
Great question. Let’s go claim-by-claim and try to break them—then say what actually holds. --- ## 1) “Names should not begin with a number. `1first` is not allowed; `first1` is allowed.” **Verdict:** **Too strong / falsifiable.** Cypher **does** allow names that start with a number **if you quote them with backticks**. The manual says: “Non-alphabetic characters, including numbers … can be used in names, but must be quoted using backticks,” e.g. `` `1first` ``. Unquoted identifiers should begin with a letter; quoted ones can start with digits, contain spaces, etc. ([Graph Database & Analytics][1]) Practical guidance: even though you *can* write ``MATCH (:`123`)``, avoid it unless you have a strong reason—quoted identifiers are harder to maintain and can open you up to Cypher-injection risks if you pass unsanitized user strings into backticks. ([Graph Database & Analytics][1]) --- ## 2) “Paragraph IDs should not be used as ‘types’ because they might begin with a number, which is not allowed in Cypher.” **Verdict:** **Partly false (as stated); mostly a modeling issue.** * **Not allowed?** False *as a blanket statement*—you could write labels/rel-types like ``:`12345` `` or ``-[:`3MENTIONS`]->`` using backticks. ([Graph Database & Analytics][1]) * **But:** this conflates terms. In Neo4j, **nodes don’t have ‘types’—they have labels** (0..n). Only **relationships have exactly one type**. So using a *paragraph ID* as a *node label* (or worse, as a *relationship type*) is conceptually wrong: an ID is identity, not classification. Store the paragraph ID as a **property** (e.g., `:Paragraph {itemId: "9e7…", …}`) and keep labels for the class like `:Paragraph`, `:Page`. ([Graph Database & Analytics][2]) **Good mapping from your Speed Bot / Ward Graph JS to Neo4j** * Ward’s `Graph.addNode(type, …props)` uses the field name `type` for *whatever you pass*. Treat that **as a “kind”** in memory (e.g., `"Page"` or `"Paragraph"`), **not** as a Neo4j relationship type. * Persist like this: ```cypher // Page and Paragraph as labels; IDs as properties (strings are fine) MERGE (p:Page {slug:$slug}) ON CREATE SET p.title = $title MERGE (q:Paragraph {itemId:$id}) SET q.text = $text MERGE (p)-[:HAS_PARAGRAPH]->(q); ``` Relationship types in ALL_CAPS (e.g., `:HAS_PARAGRAPH`) follow style guides and avoid quoting. ([Graph Database & Analytics][2]) --- ## 3) “Nodes have ‘labels’, not ‘types’ (the latter term only applies to relationships).” **Verdict:** **Correct / not falsifiable (within Neo4j’s model).** Neo4j’s property graph model explicitly specifies: nodes have **labels (0..n)**; relationships have **exactly one type** and **always have direction**. That’s the formal model Neo4j implements. ([Graph Database & Analytics][2]) (Colloquially some people say “node type” to mean “primary label,” but that’s just shorthand; in Cypher the term is *label*.) ([Graph Database & Analytics][3]) --- ## 4) “Where do we create such nodes? See Speed Bot `addNode()`…” **Verdict:** **You’re creating them in an in-memory JS graph, not Neo4j.** Ward’s `graph.js` builds a browser-side structure `{ type, in, out, props }`. That’s fine for UI, but **it is not Neo4j**. When you later export to Neo4j, do a clean mapping: * **Labels:** from your in-memory `type` → Neo4j labels like `:Page`, `:Paragraph`. * **Identity:** paragraph `id` (even if it starts with a digit) → a **property**, e.g., `itemId: "123…"`. No problem—property values are strings; property **keys** (like `itemId`) follow the same naming rules as identifiers (and you can always avoid odd keys). ([Graph Database & Analytics][2]) * **Relationship types:** human-readable, static, ALL_CAPS: `:HAS_PARAGRAPH`, `:MENTIONS_PAGE`, `:NEXT`, etc. ([Graph Database & Analytics][2]) If you ever truly needed a label/rel-type **derived from data** (e.g., per-day label), Neo4j 5.26+ can now use **dynamic labels/relationship types** safely via parameters (no string concatenation), but that’s still for *classification*, not identity. ([Graph Database & Analytics][3]) --- ## 5) “Basic properties of the property graph model” / “Node patterns” references **Verdict:** **Accurate.** The cheat sheet and core-concept docs align with the above: patterns use labels on nodes and a single type on relationships; you can query by label, by relationship type, and (as of recent versions) even **dynamically** via parameters. ([Graph Database & Analytics][3]) --- # Bottom line for your Paragraph Recommendation Viewer * **Don’t** make each paragraph ID a label or a relationship type. You *could* (with backticks), but you **shouldn’t**—it’s the wrong abstraction and harms maintainability. ([Graph Database & Analytics][1]) * **Do** model with stable labels and property IDs: ```cypher MERGE (page:Page {slug:$slug}) ON CREATE SET page.title = $title MERGE (para:Paragraph {itemId:$pid}) SET para.text = $text MERGE (page)-[:HAS_PARAGRAPH]->(para) ``` * **Do** keep relationship types conventional and directed. If you need “undirected” semantics, match either direction in Cypher; the stored edge remains directed. ([Graph Database & Analytics][2]) If you want, I can give you a tiny exporter that walks your in-browser `graph` and persists it to Neo4j with exactly this mapping. [1]: https://neo4j.com/docs/cypher-manual/current/syntax/naming/ "Naming rules and recommendations - Cypher Manual" [2]: https://neo4j.com/docs/getting-started/appendix/graphdb-concepts/ "Graph database concepts - Getting Started" [3]: https://neo4j.com/docs/cypher-cheat-sheet/current/ "Cypher Cheat Sheet - Neo4j Documentation Cheat Sheet"
–– ChatGPT 5