Filter nodes with connection

[armensanoyan]

Hi! I need help to find best structure for my graph. In my project I have users, each user can create multiple graphs and each graph have nodes. Since users can create labels for nodes I don't want to keep graph name as label. I was thinking to have nodes with label USER, GRAPH and NODE and connect nodes with its' owner and the graph, to which it belongs. The problem in this case is that I don't know how to make complex queries like (node1)-[LINK1]->(node2)-[LINK2]->(node3)-[LINK3]->(node4) and require each node to be connected to it's graph and user. So I have two questions

1. Is having Users and Graphs as nodes the best structure for graph in my case?
2. If it is, how can I require each of nodes to belong to specific graph and user.

[Bennu]

Hi @armensanoyan !

If it's up to me. I'll rather divide the USER - GRAPH behavior in one side, and the graph topology in one another. So you can focus on functionalities related to users and their graphs that are not related to the graph itself.

I suggest something like

Lemme know your thoughts about.

Bennu

[armensanoyan]

Hi Bennu! After reading this article I totally agree with you about keeping user_graph ids in label since it makes faster complex queries! Could you please help me to understand how to manage permissions for users if each label can have it's own permissions ? Thank you.
Armen

[Bennu]

Hi @armensanoyan !

What do you mean by 'label permissions'? You will have for sure some labels that part of the model of the user graphs itself i.e. NODE. Are you planning to have a set of labels that are limited by permissions for each user? Can you gimme an example?

Bennu

[armensanoyan]

Sure. There is a label Article, nodes with this label have information about articles and another label is Author where I will keep data about authors. Lets consider User1 who created Graph1 and wants to share only Authors of this Graph1 with User2. So I need to connect User2 with Authors. May be each Label (nodes with this label) should have properties for permissions like

(:Node :U1_G1 :Author {...edit:['User1'], view:['User2']})

or

MATCH (authors :Node :U1_G1 :Author),
MATCH (user: USER {name:'Armen'})
MERGE (user)-[:CAN_EDIT]->(authors)

But I don't think that any of this is good for complex filtering. So where should I keep the info about users who can view or edit nodes of specific label. Thank you. Armen

[Bennu]

Hi @armensanoyan !

I'm trying to follow your use case but I do struggle a little bit in some points.

Are Authors bound to just one graph, or can the be in different graph (eventually from different users?

I've been asuming this from the begening so wanna confirm it. All the :Graph made by an user are disjunt between each other, aren't they?

Can we create a small sample with the actual model in order to test some of the queries/functionalities you have on mind?

In general, in order to handle CRUD permissions, you may like to add some new relations between USER and AUTHOR like you suggested (CAN_EDIT, CAN_DELETE, CAN_CREATE). This share function is not to clear to me.

Bennu

[armensanoyan]

Hi Bennu! Sorry I will try again

1.Yes all nodes belong to only one graph (in this example they have 'node' label).

2.Each Graph have it's owner and can be shared with other users (sharing the graph means sharing all labels inside it)

3.Each label inside the graph can be shared with other users

Here is the cypher code to create small graph with structure I need

create (u1:user {name:'John',id:1}),
(u2: user {name:'Matteo',id:2}),
(u3: user {name:'anotherGuy',id:3}),
(g1: graph {name:'reseach',id:4}),
(g2: graph {name:'university', id: 5}),
(n1: node : Author {name:'Albert Einstein', id:6}),
(n2: node : Author {name:'Marie Curie', id:7}),
(n3: node : Article {name:'Graphene Nanotubes', id:8}),
(n4: node : Article {name:'FET Transistors', id:9}),
(n5: node : Person {name:'Richard Branson', id:10})
merge (u1)-[:OWN]->(g1)
merge(u2)-[ce:CAN_EDIT]->(g1)
merge(u3)-[cv:CAN_VIEW]->(g1)
merge(u3)-[:CAN_EDIT]->(n1)
merge(u3)-[:CAN_EDIT]->(n2)
merge(u3)-[o:OWNS]->(g2)
merge(g1)-[:CONTAINS]->(n1)
merge(g1)-[:CONTAINS]->(n2)
merge(g1)-[:CONTAINS]->(n3)
merge(g1)-[:CONTAINS]->(n4)
merge(g2)-[:CONTAINS]->(n5)
return u1, u2, u3, g1, g2, n1, n2, n3, n4, n5, ce, cv, o

Here is a picture how graph looks.

Thank you for your time.
Armen

[Bennu]

Hi @armensanoyan !

I get very confused every time you say sharing all labels. I guess you talk about sharing nodes that belong to a certain labeled graph.

Why do you have the relation Graph - Contains -> Author? What's the meaning of it? Do they belong to just one Graph?

What kind of questions are you planning to answer?

Bennu

[armensanoyan]

I get very confused every time you say sharing all labels . I guess you talk about sharing nodes that belong to a certain labeled graph. - Yes!

Why do you have the relation Graph - Contains -> Author? What's the meaning of it? Do they belong to just one Graph? - Yes!

What kind of questions are you planning to answer?
Do you mean use case ? first of all I need complex filters like author who wrote this article which was published in this magazine.