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)
Related
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 having conceptual difficulties with edges and links in OrientDB.
I have a graph that represents link layer and internet layer in a network. link_layer EXTENDS V nodes correspond to MAC addresses, net_layer EXTENDS V nodes correspond to IP addresses.
A communication relationship between two addresses is represented by an edge class conx EXTENDS E. There will be two separate conx edges that represent the same connection: conx 1 connecting MAC A to MAC B, and conx 2 connecting IP a to IP b that represent the same connection. This will create a graph that is partitioned into two separate subgraphs which do not interact (no MAC to IP edges)
Now I need some way to associate the two graphs together. I would like to connect the edges with a link relationship. Each edge could have a LINKLIST property that identifies all the other edges that this edge is identical to in different layers (say I add the TCP/Application layers later, this would be an n-to-n relationship)
So far so good. How do those links affect the graph? OrientDB documentation says that "With the Graph API, Edges are represented with two links stored on both vertices to handle the bidirectional relationship." If then try to interact with this database from the graph API, can LINK or LINKLIST properties be interpreted as edges? Can you even make a link between an edge and an edge? Ideally, it would not affect graph traversal...I'd like to be able to run graph analysis the link layer usage of my network separately from the internet layer.
Sorry for the broad questions, but I am in general just confused about how and why to use referenced relationships and if using them to connect edges in two otherwise unconnected graphs is valid.
In general, a graph should be designed to best represent your scenario being described.
It is therefore essential to identify the entities that will be represented by the various classes.
Each class will have a relationship with another class, by edge or link.
Usually:
An edge Defines a relationship between two vertices. For example, you define two vertices, Person and Car. You then define an Edge Drives. This edge ties the two vertices together. "Jane" Drives "Ford".
While:
A Linklist is a list of classes associated with another class. A Car class might have a Linklist of parts from the Part class. A car Consists of multiple parts.
The edge / link should never be used to have a relationship with each other eg: edge to edge, and if you have this situation means that the graph has problems
conceptual design.
I've read the document but still confused of them, could any guy can give me a clearly explaining, e.g.any image comparison? Thanks.
The Wikipedia article on Pathfinding might help, as might the related topics on graphs and graph search algorithms linked from there. Beyond that, here's an attempt at a quick explainer.
Nodes are places that someone can be, and their connections to other nodes define someone can travel between places. Together, a collection of (connected) nodes form a graph.
GKGraphNode is the most general form of node — these nodes don't know anything about where they are in space, just about their connections to other nodes. (That's enough for basic pathfinding, though... if you have a graph where A is connected to B and B is connected to C, the path from A to C goes through B regardless of where those nodes are located, like below.)
GKGraph is a collection of nodes, and provides functions that work the graph as a whole, like the important one for finding paths.
GKGridGraphNode and GKGraphNode2D are specialized versions of GKGraphNode that add knowledge of the node's position in space — either integer grid space (like a chessboard) or open 2D space. Once you've added that kind of information, a GKGraph containing these kinds of nodes can take distance into account when pathfinding.
For example, look at this image:
If we're just using GKGraphNode, all we're talking about is which nodes are connected to which. So if we ask for the shortest path from A to D, we can get either ACD or ABD, because it's an qual number of connections either way. But if we use GKGridGraphNode or GKGraphNode2D, we're looking at the lengths of the lines between nodes, in which case ACD is the shortest path.
Once you start locating your nodes in (some sort of coordinate) space, it helps to be able to operate on the graph as a whole in that space. That's where GKGridGraph and GKObstacleGraph come in.
GKGridGraph works with GKGridGraphNodes and lets you do things like create a graph to fill a set of dimensions (say, a 10x10 grid, with diagonal movement allowed) instead of making you create and connect a bunch of nodes yourself.
GKObstacleGraph adds more to free-2D-space graphs by letting you mark areas as impassable obstacles and automatically managing the nodes and connections to route around obstacles.
Hopefully this helps a bit. For more, besides the reference docs and guide, Apple also has a WWDC video that shows how this stuff works.
I want to ask about jelly physics ( http://www.youtube.com/watch?v=I74rJFB_W1k ), where I can find some good place to start making things like that ? I want to make simulation of cars crash and I want use this jelly physics, but I can't find a lot about them. I don't want use existing physics engine, I want write my own :)
Something like what you see in the video you linked to could be accomplished with a mass-spring system. However, as you vary the number of masses and springs, keeping your spring constants the same, you will get wildly varying results. In short, mass-spring systems are not good approximations of a continuum of matter.
Typically, these sorts of animations are created using what is called the Finite Element Method (FEM). The FEM does converge to a continuum, which is nice. And although it does require a bit more know-how than a mass-spring system, it really isn't too bad. The basic idea, derived from the study of continuum mechanics, can be put this way:
Break the volume of your object up into many small pieces (elements), usually tetrahedra. Let's call the entire collection of these elements the mesh. You'll actually want to make two copies of this mesh. Label one the "rest" mesh, and the other the "world" mesh. I'll tell you why next.
For each tetrahedron in your world mesh, measure how deformed it is relative to its corresponding rest tetrahedron. The measure of how deformed it is is called "strain". This is typically accomplished by first measuring what is known as the deformation gradient (often denoted F). There are several good papers that describe how to do this. Once you have F, one very typical way to define the strain (e) is:
e = 1/2(F^T * F) - I. This is known as Green's strain. It is invariant to rotations, which makes it very convenient.
Using the properties of the material you are trying to simulate (gelatin, rubber, steel, etc.), and using the strain you measured in the step above, derive the "stress" of each tetrahdron.
For each tetrahedron, visit each node (vertex, corner, point (these all mean the same thing)) and average the area-weighted normal vectors (in the rest shape) of the three triangular faces that share that node. Multiply the tetrahedron's stress by that averaged vector, and there's the elastic force acting on that node due to the stress of that tetrahedron. Of course, each node could potentially belong to multiple tetrahedra, so you'll want to be able to sum up these forces.
Integrate! There are easy ways to do this, and hard ways. Either way, you'll want to loop over every node in your world mesh and divide its forces by its mass to determine its acceleration. The easy way to proceed from here is to:
Multiply its acceleration by some small time value dt. This gives you a change in velocity, dv.
Add dv to the node's current velocity to get a new total velocity.
Multiply that velocity by dt to get a change in position, dx.
Add dx to the node's current position to get a new position.
This approach is known as explicit forward Euler integration. You will have to use very small values of dt to get it to work without blowing up, but it is so easy to implement that it works well as a starting point.
Repeat steps 2 through 5 for as long as you want.
I've left out a lot of details and fancy extras, but hopefully you can infer a lot of what I've left out. Here is a link to some instructions I used the first time I did this. The webpage contains some useful pseudocode, as well as links to some relevant material.
http://sealab.cs.utah.edu/Courses/CS6967-F08/Project-2/
The following link is also very useful:
http://sealab.cs.utah.edu/Courses/CS6967-F08/FE-notes.pdf
This is a really fun topic, and I wish you the best of luck! If you get stuck, just drop me a comment.
That rolling jelly cube video was made with Blender, which uses the Bullet physics engine for soft body simulation. The bullet documentation in general is very sparse and for soft body dynamics almost nonexistent. You're best bet would be to read the source code.
Then write your own version ;)
Here is a page with some pretty good tutorials on it. The one you are looking for is probably in the (inverse) Kinematics and Mass & Spring Models sections.
Hint: A jelly can be seen as a 3 dimensional cloth ;-)
Also, try having a look at the search results for spring pressure soft body model - they might get you going in the right direction :-)
See this guy's page Maciej Matyka, topic of soft body
Unfortunately 2d only but might be something to start with is JellyPhysics and JellyCar
I have an application in which users interact with each-other. I want to visualize these interactions so that I can determine whether clusters of users exist (within which interactions are more frequent).
I've assigned a 2D point to each user (where each coordinate is between 0 and 1). My idea is that two users' points move closer together when they interact, an "attractive force", and I just repeatedly go through my interaction logs over and over again.
Of course, I need a "repulsive force" that will push users apart too, otherwise they will all just collapse into a single point.
First I tried monitoring the lowest and highest of each of the XY coordinates, and normalizing their positions, but this didn't work, a few users with a small number of interactions stayed at the edges, and the rest all collapsed into the middle.
Does anyone know what equations I should use to move the points, both for the "attractive" force between users when they interact, and a "repulsive" force to stop them all collapsing into a single point?
Edit: In response to a question, I should point out that I'm dealing with about 1 million users, and about 10 million interactions between users. If anyone can recommend a tool that could do this for me, I'm all ears :-)
In the past, when I've tried this kind of thing, I've used a spring model to pull linked nodes together, something like: dx = -k*(x-l). dx is the change in the position, x is the current position, l is the desired separation, and k is the spring coefficient that you tweak until you get a nice balance between spring strength and stability, it'll be less than 0.1. Having l > 0 ensures that everything doesn't end up in the middle.
In addition to that, a general "repulsive" force between all nodes will spread them out, something like: dx = k / x^2. This will be larger the closer two nodes are, tweak k to get a reasonable effect.
I can recommend some possibilities: first, try log-scaling the interactions or running them through a sigmoidal function to squash the range. This will give you a smoother visual distribution of spacing.
Independent of this scaling issue: look at some of the rendering strategies in graphviz, particularly the programs "neato" and "fdp". From the man page:
neato draws undirected graphs using ``spring'' models (see Kamada and
Kawai, Information Processing Letters 31:1, April 1989). Input files
must be formatted in the dot attributed graph language. By default,
the output of neato is the input graph with layout coordinates
appended.
fdp draws undirected graphs using a ``spring'' model. It relies on a
force-directed approach in the spirit of Fruchterman and Reingold (cf.
Software-Practice & Experience 21(11), 1991, pp. 1129-1164).
Finally, consider one of the scaling strategies, an attractive force, and some sort of drag coefficient instead of a repulsive force. Actually moving things closer and then possibly farther later on may just get you cyclic behavior.
Consider a model in which everything will collapse eventually, but slowly. Then just run until some condition is met (a node crosses the center of the layout region or some such).
Drag or momentum can just be encoded as a basic resistance to motion and amount to throttling the movements; it can be applied differentially (things can move slower based on how far they've gone, where they are in space, how many other nodes are close, etc.).
Hope this helps.
The spring model is the traditional way to do this: make an attractive force between each node based on the interaction, and a repulsive force between all nodes based on the inverse square of their distance. Then solve, minimizing the energy. You may need some fairly high powered programming to get an efficient solution to this if you have more than a few nodes. Make sure the start positions are random, and run the program several times: a case like this almost always has several local energy minima in it, and you want to make sure you've got a good one.
Also, unless you have only a few nodes, I would do this in 3D. An extra dimension of freedom allows for better solutions, and you should be able to visualize clusters in 3D as well if not better than 2D.