I am currently working with GraphDB to visualize some data that has a graph nature. I have imported the RDF data into graphDB and actually the graph is pretty nice. The only downside is that every single node is orange.
I was wondering then, if graphDB has some mechanism whereby the color of some nodes could be changed based upon a semantic relationship between them. For example:
<Berners_Lee> <created> <web> .
<Berners_Lee> <works_as_a> <teacher>
If I were to load this onto graphDB all nodes would appear by default in orange. Is there any way I can specify that nodes that are pointed by relationship created appear in blue?
I hope everything is clear. Any help would be much appreciated.
The colors are generated automatically and differentiate the types in one graph, which is their main purpose. Also we do not handle properly the case with multiple types for a node, but we have it in mind. The problem with your data is that all of the subject predicates and objects have no type (which makes them the same type). Here is a small example, based on your data which will produce the desired effect.
<Berners_Lee><created><www>;
<works_as_a><teacher>;
a <Person>.
<teacher> a <Occupation>.
Related
Is it possible somehow to also show the blank nodes in the visual graph?
I noticed that in the visualization config queries there is a filter using isIRI(...) which makes sure that by default only IRIs are visualized. However removing that filter does not help at all - blank nodes are still not visible, which is a major limitation on the ability to visually expand/navigate the graph.
Even if blank nodes are not useful identifiers, they are necessary to navigate the graph and it's not always feasible to convert them to IRIs.
Visual graph shows only IRIs with their local name or label. Bnodes by themselves are not meaningful.
But you can construct with SPARQL IRIs from your BNodes' data (using the IRI function to create IRI from whatever string you like). These are virtual nodes that do not exist actually, but exist for visualization.
Customizing visual graphs with your own queries is described here:
https://graphdb.ontotext.com/documentation/9.9/free/devhub/custom-graph-views.html
Is there a layout or an option to avoid grouping nodes to overlap eachother?
I'm getting a graph with standalone and grouped nodes, but the combinations are dependent on dynamic data. So i can not place them on my one, or would like to avoid it.
All layouts i have tried do not take care of the grouping nodes and place their sub nodes together.
For example 'circle' creates one circle of all nodes, not a circle per group.
The goal would be to create something like "http://js.cytoscape.org/demos/5b192c88616af2f75344/", but there the nodes are placed manualy..
I have seen the example "http://js.cytoscape.org/demos/59e38e9f20e25a293e44/" which seems to work as required but it is using an extension. First of all i would like to find a built in solution.
Your requirement for a non-extension solution is erroneous.
Only basic, small KB layouts are included in Cytoscape.js itself, and it makes no functional difference whether a layout is included by default or not: They are both extensions -- some are included by default, some are not.
CoSE Bilkent is the best compound node layout algorithm for graphs/networks -- bar none. You can alternatively use CoSE, which is included by default. CoSE is a more basic version of the algorithm, optimised for speed at the expense of visual results in some cases.
There is a note on the cytoscape.js website that says:
"Note that a collection is immutible by default, meaning that the set of elements within a collection can not be changed. The API returns a new collection with different elements when necessary, instead of mutating the existing collection. This allows the developer to safely use set theory operations on collections, use collections functionally, and so on."
Does this mean it is not really suitable to use in the creation of online 'network editor' ie. where the user can interact to add and delete nodes and edges to the existing graph?
If I understand the note above it would mean that adding a new node would mean reconstructing the whole graph from scratch (but with the new node) and then presumably performing a complete redraw. Is this correct?
A collection is a set of elements; the set merely points to all the individual elements. You can think of it like an array of elements: The array just holds the elements. Different arrays/sets can have different, similar, overlapping elements, etc.
Cytoscape.js is very suitable for the purpose you mention. There are already projects that have live, collaborative editors (similar to google docs, online office, etc but for graphs). For example, a simple one that I created is codenamed "Factoid" for biological processes. Though I really think it ought to have a better, more accurate name -- you can still look through the code for a live collaboration example with Cytoscape.js. Because you can listen to events easily, it's relatively straightforward to send diffs (or even just events) back and forth between the server and the client.
Adding an element is inexpensive: It just adds the single element and redraws if opportune. It's even cheaper with cy.batch() for modifying lots of elements in a row.
I am writing 3D geometry visualization software for schools. I am designing my engine as an Entity-Component system, because it has served me well in games. In this case I have some specific requirements:
There is a limited amount of different geometries I need to render. I would like to render these in batches. So I render all lines as one batch, all triangles as one batch, all planes as one batch, ... It works well even with transparent objects, since I am using depth peeling and don't need to sort them by distance.
One logical object will typically have more than one mesh associated: e.g. a plane entity has a border "child"-entity that has four lines as its body, these lines all share the same material.
I would like to have a clean design, so I am trying to stay true to the no-code-in-components principle and same-structure for one type of components.
What I have now is: A different component type for each type of geometry (point, line, plane, ...). The corresponding system stores a batch with a mesh + instance data and renders it in one draw call. The instance data for different types of geometry is different, hence I decided to go with one component type per geometry type. (A bad design?)
Question:
Now I'm wondering how to handle entities that seem to need multiple components of the same type, like the plane border, that has a body consisting of four lines.
I could think of several solutions, which all have draw-backs:
1. Make each line of the border entity an entity itself. Each would have a "line" component and a "child" component. That would model the border and the lines as five entities, with the four lines attached to the border entity via "child" component. This seems like quite a waste of entities. Some special entities would have several dozens of children then.
2. Allow the border entity to have multiple components of the "line" type. This seems like a hack, since all ECS article I've seen discourage using multiple components of the same type on one entity.
3. Make a unified "geometry" component that may contain an arbitrary number of elementary geometries. That would introduce quite some indirections, but seems like the best solution to me, at the moment.
Could someone help me to sort this chaotic thoughts into a good solution? I'm sure I'm missing a straight-forward approach, but I just couldn't find one yet.
I have a lot of experience in programming (10+ years), but unfortunately, just recently started with Entity-Component systems. So I'm still struggling with the concept, it seems.
Thank you very much.
Which is the best DB for a tree strucutre?
I have different kinds of objects which can have parent or child objects . The structure of this objects is dinamic, ej: some can have a 'name' field while others dont, some can have a 'menu' field and others an 'image' field.
One element can have 1000 fields(or attributes) while other can have just 1.
An SQL database is discarted, because it can not be schemaless
Currently, I am storing this in mongoDB, but I think it is not the most appropiate thing, because I can not have infinite childs or parents on one document(its limited to 16mb) so I have to make a separate document for every object and then one of the greatest advantaje of mongodb is lost.
Another solution migth be a graph db, im not familiar with them, but they seem the perfect solution, a tree is a graph after all.
So what do you think?
A graph database sounds like the right answer. Please consider looking at TinkerPop which is an open source graph technology stack. It enables connection to most any graph database (Neo4j, Titan, OrientDB, Bitsy, etc.) in an agnostic way. Obviously, that enables you to try out different graph implementations to find the right one for you.
While far from being performant, compared to true graph databases, there's even a MongoDB implementation of a graph. I'd recommend starting with a simple in-memory TinkerGraph and a Gremlin REPL to begin your learning process.
Take a look at the graph databases. Neo4j is leading here.