How would write a traversal in use Gremlin TinkerPop 3 to find all vertices that have no incoming edges?
As a follow up I also need to find a vertices that have no outgoing edges as well.
This is simpler than the below version
g.V().not(inE())
g.V().not(outE())
Keeping my original answer for reference
g.V().where(inE().count().is(eq(0)))
For 0 outgoing edges
g.V().where(outE().count().is(eq(0)))
Related
I'm new using Graph Databases and I'm a little confused about the concept of From / To or In/Out in OrientDB.
Which is the best approach to define which Vertex is From and which is To? Or Both for example when is a relation of contact in social network.
In my opinion, the most part of this confusion comes from Apache TinkerPop notation for edges. OrientDB historically adopted TinkerPop as its graph API (some things are changing here, so in v 3.0 there will be a native document/graph API that does not depend on Apache TinkerPop API, but we will still maintain the support with TinkerPop 3.x) so the notation is the same.
Apache TinkerPop uses OUT/IN to define both edges connected to vertices and vertices connected to edges:
given a vertex, you have outgoing edges referenced by OUT and incoming edges referenced by IN (so far so good)
given an edge, it has the starting point (the vertex it comes from) identified by OUT (ouch!) and the end point (the vertex it goes to) identified by IN
And here come the problems: for a beginner, it's very natural to consider an edge traversal as an out + out:
vertex -out-> edge -out-> anotherVertex
but unfortunately it's WRONG!
The right way to do a straight edge traversal is out + in:
vertex -out-> edge -in-> anotherVertex
You can also traverse the edge backwards with an in + out.
As I wrote before, IMHO it's extremely unintuitive, at the beginning I also had problems with this. IMHO the best notation for edge connection would have been FROM/TO, instead of OUT/IN, but it's a standard now, so we cannot do much.
The only thing I can tell you is that it becomes natural with a little practice.
A separate consideration is for social networks and in general for edges that are not intended to have a direction (in a social network the direction of edges is not important, the fact that I'm your friend also implied that you are my friend). Apache TinkerPop does not have a concept of undirected edges, so you just have to use directed edges and ignore the direction when traversing them (eg. using the both() operator or BOTH direction)
I am a newbie in OrientDB. Currently I want to create the undirect Edge between 2 Vertexes, it looks like: Product A relates to Product B.
I am using Java API, blueprint.
Thank you.
aVertex.addEdge(endVertex, "label")
graph.addEdge(id, outVertex, inVertex, "label")
Either way, there are always an out and an in vertex
There is no way to create an undirected edges. In OrientDB, as in most graph databases in the market, edges always have a direction.
It is not a limitation, because you can traverse edges regardless their direction, using both() query operator or, in Java:
vertex.getEdges(Direction.BOTH, label)
I am working with orientDB v2.2.10 and I am trying to create edges of class "E" between vertices using the graph editor, my question is can create undirected edges between vertices and if yes how to do it via Java API
You can find documentation about graph Java API here:
http://orientdb.com/docs/last/Graph-Database-Tinkerpop.html
I'm using Tinkerpop 3.0.1 (Titan 1.0.0), and I try to list all edges for a vertex, sorted by degree of the node on the other end of the edge.
I tried:
g.V(1482896).bothE().order().by(otherV().bothE().count(), decr)
I get the following error from Titan:
The path history of the traverser does not contain a previous vertex: [e[1d2m8u-1d70ts-b2t-vs7k][82628848-DIRECTED->1482896]]
The strange thing is, there is a previous vertex in the path (namely vertex #1482896. I'm confused on how to solve this one.
Answering my own question, after playing around with this, I found a workaround:
g.V(123).bothE().as('edges')
.otherV().order().by(bothE().count(), decr)
.select('edges')
This will effectively sort edges adjacent to vertex #123 by highest degree of the node on the other end of the edge.
I would like to add additional forces to networkx spring_layout.
I have a directected graph and I would like nodes to move to different sides according to the edges that they have. Nodes that have more outgoing edges should drift to nodes that have more ingoing edges should drift right. Another alternative would be. That these groups of nodes would drift towards each other, nodes with outgoing edges would get closer while nodes with ingoing edges would also get closer to each other.
I managed to look into to the source code of spring_layout of networkx http://networkx.lanl.gov/archive/networkx-0.37/networkx.drawing.layout-pysrc.html#spring_layout
but everything there is just beyond my comprehension
G.DiGraph()
G.add_edges_from([(1,5),(2,5),(3,5),(5,6),(5,7)])
The layout should show edges 1,2,3 closer to each other, the same regarding 6 and 7.
I imagine, that I could solve this by adding invisible edges via using MultiDiGraph. I could count ingoing and outgoing edges of each node and add invisible edges that connect the two groups. However, I am very sure that there are better ways of solving the problem.
Adding weights into the mix would be a good way to group things (with those invisible nodes). But the layouts have no way of knowing left from right. To get the exact layout you want you could specify each point's x,y coordinates.
import networkx as nx
G=nx.Graph()
G.add_node(1,pos=(1,1))
G.add_node(2,pos=(2,3))
G.add_node(3,pos=(3,4))
G.add_node(4,pos=(4,5))
G.add_node(5,pos=(5,6))
G.add_node(6,pos=(6,7))
G.add_node(7,pos=(7,9))
G.add_edges_from([(1,5),(2,5),(3,5),(5,6),(5,7)])
pos=nx.get_node_attributes(G,'pos')
nx.draw(G,pos)