neo4j: необязательные «шаги» в запросе Cypher

Question

Я пытаюсь найти отношения между узлами с необязательными, но определенными узлами/отношениями между ними (neo4j 2.0 M6).

В моей модели данных 'Gene' может быть 'PARTOF' a 'Group. У меня есть отношения «INTERACT» между «Gene» - «Gene», «Gene» - «Group» и «Group» - «Group» (красные линии в образце модели).

Я хочу сварить это до всех отношений «ИНТЕРАКТ» между «Джин»: оба прямые (Gene-INTERACT-Gene) и через одну или две «группы» (Gene-PARTOF-Group-INTERACT-Gene).

---

---

Конечно, это легко с несколькими Cypher запросов:

# direct INTERACT 
MATCH (g1:Gene)-[r:INTERACT]-(g2:Gene) RETURN g1, g2 
# INTERACT via one Group 
MATCH (g1:Gene)-[:PARTOF]-(gr:Group)-[r:INTERACT]-(g2:Gene) RETURN g1, g2 
# INTERACT via two Group 
MATCH (g1:Gene)-[:PARTOF]-(gr1:Group)-[r:INTERACT]-(gr2:Group)-[:PARTOF]-(g2:Gene) 
RETURN g1, g2 

Но было бы возможно построить один Cypher запрос, который принимает дополнительные 'шаги группы' на пути? До сих пор я использовал только необязательные отношения и shortestPaths, но я понятия не имею, могу ли я фильтровать один или два дополнительных узла между двумя генами.

Answer 1

Вы можете назначить глубину между нулем и одним для каждого из отношений, которые вы добавляете к пути. Попробуйте что-то вроде

MATCH (g1:Gene)-[:PARTOF*0..1]-(gr1)-[:INTERACT]-(gr2)-[:PARTOF*0..1]-(g2:Gene) 
RETURN g1,g2 

и посмотреть, что совпавшие пути на самом деле похожи, просто вернуть весь путь

MATCH p=(g1:Gene)-[:PARTOF*0..1]-(gr1)-[:INTERACT]-(gr2)-[:PARTOF*0..1]-(g2:Gene) 
RETURN p 

Существует немного беспокоить с объявляя узла этикетки для дополнительных частей этого однако этот запрос предполагает, что гены не являются частью ничего, кроме групп, и что они взаимодействуют только с группами и другими генами. Если у гена может быть [:PARTOF] что-то еще, то (gr1) свяжет это что-то, и запрос уже не является надежным. Простое добавление где положение как

WHERE gr1:Group AND gr2:Group 

исключает случай, когда дополнительные части не совпадают, так что не будет работать (это было бы, как ваш третий запрос). Я уверен, что это можно решить, но если ваша фактическая модель не намного сложнее, чем то, что вы описываете в своем вопросе, это должно быть.

Я позволил вам интерпретировать вашу модель на консоли here, проверьте, не делает ли она того, что вы хотите.