Hi Rasik Assuming that you indeed need to represent the application itself (not just the possible transitions from one stage of education to the next) then remember that relations in a graph are cheap. It might very well be that having A->E (representing that someone applies), E->M (representing that someone is accepted) as well as A->M (representing that students of course A are allowed to apply to course M) might be totally fine. Then to find paths you can do something like MATCH (m:GradCourse) <-- (a:UndergradCourse) --> (x:Application) --> (m) This would make sure that you get your x Application node and path (if you indeed need some special properties of the application process) but it would filter out anything where such transition isn't correct.
If your concern is more around "90% of cases don't have restrictions" and the fact that you don't want to link every undergrad course to every grad course then maybe rather than thinking of "application" node being in the middle, you should represent the "any (grad/undergrad) course" as a node, and then link on both sides as appropriate (i.e. link to all undergrad courses which have no restrictions where you can go afterwards, and to all grad courses that have no restrictions on who can apply). On top of that, the 10% you'd link directly for any allowed transitions. If you use the same relationship between that special node and the restricted cases then you should be able to fairly easily find all paths with [*1..2] cardinality for the relationship. If the restriction is one-sided e.g. undegrad A can generally go anywhere they want, but grad M requires someone to finish A, then there'd be a relation from A -> "any" node (which then links onto all unrestricted courses, i.e. it would NOT link to M), as well as a relation from A -> M directly to represent that special case. If the application process itself is indeed important, then you could apply a similar concept there - rather have a single "application" node between stages, have "unrestricted application" node and restricted ones, which are specific to whatever limitations you have, and then only appropriate nodes are linked to them. Hope this helps a little bit with your thinking. :) On Sun, Nov 8, 2015 at 1:52 AM Rasik Fulzele <[email protected]> wrote: > Application process (node E) represent a stage between courses (courses > also being stages). The problem is in my app, I can't build a generic query > to show series of stages because 90% of times, the transition stages like > Application Process (node E) are without any specifics but in 10% of times, > selective cases like certain undergrad transition to grad pop up. > > Thanks, > R > > > On Sunday, November 8, 2015 at 2:51:20 AM UTC+5:30, Liliana Ziolek wrote: >> >> It's hard to say what kind of queries do you want to ask of such graph - >> from what you said so far I don't see the need for the node "application >> process". If you want to know from which under-graduate course to which >> graduate course a student can apply to, then the simplest representation >> would be: >> nodes are A,B,C, M, N as you said, the relationship is pointing directly >> from A-> N (e.g. A -[:FOLLOWED_BY]->N, B->N, B->M and C->M (then you can >> ask "which courses allow me to apply for grad course N). >> >> Can you explain a bit more on the place of the application process in >> your queries? It might also turn out to be a node, but you'll probably >> still want to keep the direct relationship from under-grad courses into >> grad courses, simply to indicate which transitions are allowed and which >> aren't. >> >> On Saturday, November 7, 2015 at 6:18:52 AM UTC, Rasik Fulzele wrote: >>> >>> Thanks for your reply. >>> Sorry, if I was not clear. >>> I'll try to elaborate again with other example. >>> >>> There are 3 under-graduate courses (A,B,C) and 2 graduate courses (M and >>> N). The courses are nodes. also, the transition from undergrad to grad >>> happens through an application process E which is also a node. >>> >>> So here are relationships >>> >>> A precedes E >>> B precedes E >>> C precedes E >>> E precedes N >>> E precedes M >>> >>> Now the problem is graduate course N is allowed only for those who did >>> under-grad courses A and B. similarly graduate course M is allowed for >>> under-grad courses B and C. so following paths are invalid and would return >>> wrong results. >>> A precedes E precedes M >>> C precedes E precedes N >>> >>> I think, rather taking care in query, the data modeling should be >>> correct. How to arrange above data in graph so that I get valid paths? >>> >>> Thanks, >>> R >>> >>> >>> On Saturday, November 7, 2015 at 5:47:57 AM UTC+5:30, Michael Hunger >>> wrote: >>>> >>>> perhaps you can be a bit more concrete? >>>> >>>> which data has which dependencies >>>> >>>> You can also specify predicates on node and relationship-properties for >>>> your path >>>> >>>> e.g. where a.time < b.time < c.time >>>> >>>> Michael >>>> >>>> Am 06.11.2015 um 17:17 schrieb Rasik Fulzele <[email protected]>: >>>> >>>> Hi, >>>> >>>> I'm new to neo4j and don't know what this problem is called as. So >>>> posting here without much exploration of previous posts. >>>> >>>> I'm modeling data in graph but the combination of edges in paths become >>>> significant. How to model in such scenario? >>>> >>>> for example, >>>> create >>>> (node1) >>>> ,(node2) >>>> ,(node3) >>>> ,(node4) >>>> ,(node5) >>>> ,(node6) >>>> ,(node7) >>>> ,(node1)-[:precedes]->(node5) >>>> ,(node2)-[:precedes]->(node5) >>>> ,(node3)-[:precedes]->(node5) >>>> ,(node4)-[:precedes]->(node5) >>>> ,(node5)-[:precedes]->(node6) >>>> ,(node5)-[:precedes]->(node7) >>>> >>>> when I try to find out list of all paths I'll get total 8 paths. But >>>> for my data, only few paths are significant and that should be my output. >>>> ie. only 4 paths should be in output because data (of nodes) has >>>> dependencies. >>>> (node1)-[:precedes]->(node5)-[:precedes]->(node6) >>>> (node3)-[:precedes]->(node5)-[:precedes]->(node6) >>>> (node3)-[:precedes]->(node5)-[:precedes]->(node7) >>>> (node4)-[:precedes]->(node5)-[:precedes]->(node7) >>>> >>>> whereas path like (node1)-[:precedes]->(node5)-[:precedes]->(node7) is >>>> invalid combination. >>>> >>>> Question is how to model such cases so that I always get proper >>>> combination of edges. >>>> >>>> Thanks, >>>> Rasik >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Neo4j" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>>> >>>> -- > You received this message because you are subscribed to a topic in the > Google Groups "Neo4j" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/neo4j/ZjS2Eu1LRns/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Neo4j" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
