I am quite curious on how you would model a graph representing a graph.
What I mean:
assume one has real nodes like "Person" and "Places" also relations like "ISBORNAT", "KNOWS"
now I have one or more drawings where I have squares representing nodes and lines representing edges.
Imagine I'd like to save my drawing to neo4j.
I could say my drawing is a node "Drawing" that has realtions ["CONTAINS"] to Shapes that relate via [REPRESENTS] to ("Person") or ("Town")
(Drawing)-[CONTAINS]->(SHAPE)-[REPRESENTS]->(Person or Town),
no the question is how to represent Edges
This is quite simple but now the crux is the edge.
how to make a represent a line?
a) I could say that my line would be a [l:LINE] and a property (or a set of properties) identifying the "real" edge (l.realedgeId="uniqueId of real edge"). There would be just a property(ies) expressing the link between edges.
b) Other approach could be to represent an edge in the datamodel as (sourcenode)-[:ISBORNAT]->(edgeNode:ISBORNAT)-[:ISBORNAT]->(targetnode)
and alike for the represetation (sourceShape)-[:LINE]->(lineNode:LINE)-[:LINE]-(targetShape) and then create a relation (linkNode)-[:REPRESENTS]->(edgeNode). This has the "Problem" that lines/relations are represented as nodes (and two edges).
Here I can see the advantage is that the node representing a logical edge can have multiple sources and multiple targets hence acting somewhat like a bus in electronics. Or in other words a road can be represented as a node and connected to crossings. In that sense a road is not just the segment between to crossings.
how shoud I mode the Drawing of two nodes and relation in the picture below. Green or blue. The box around represents neo4j db.
What would you opt for? Are there other things to keep in mind?
I'm not sure your diagram is correct ... do you mean Person:SHAPE and Town:SHAPE?
Neo4J is schemaless (for now), you are trying to represent a metamodel (top nodes?) that is optional, if your end goal is to implement inference, you need n10s and your statements will get incredibly verbose (as in triple stores/rdf graphs, the properties are 'sort of' qualifiers, rather than actual edges).
You can have complex metamodels that interact with the data programmatically, my diagram below shows shapes (red) and properties (yellow) and allows for inheritance.
Hi joshcornejo
thank you for the hint on the picture...
I am aware that neo4j is very flexible, and you model attributes as nodes... fine and appropriate in your case. I will also have a "business server" that deals with them.
But I'd like to have POV pro green pro blue version of the representation. E.g. what makes code simple, riskier, performance, human readability of datamodel etc...
Reasoning is not my goal, and rdf is already complicated with attributes on relations, please have a look rdf* or rdfstar. I just want to store a page of shapes and lines representing nodes and edges in neo4j... easy right? Nodes easy... Lines... thats where I'd like some opinions.
my goal is to save a drawing of a graph.
The drawing contains shapes or sometimes called stencils. Actually the circles that you see in neo4j browser. You also have lines or connectors between them. They represent something "real" object or relation.
So the shape represents a node.
The line represents a relation/edge.
If you want to save the place and dimensions of a shape and relate it to the real node you can do that relativly simply.
the graph model would be
(shape:Shape)-[:REPRESENTS]-(node:Person or Town or ...) // I don't care about static or dynamic labels right now.
it is a bit more complicated with edges.
when you want to model a line in neo4j the natural way of modelling would be in my opion an edge.
remember the line is a representation of the edge.
if you model the line as an edge e.g. (shape1:SHAPE)-[line:LINE]-(shape2:SHAPE)
you cannot relate it via a neo4j relation to an other edge
(peter:PERSON)-(born:ISBORNAT)->(london:TOWN) except by a property on line and on born.
you could do it setting born.uid="123" and line.edgeRef="123" line.edgeRefType="ISBORNAT"
this is the blue solution
no if you model the line drawn on the diagramm as a node then you can easyly reate a relation
(edgeshape:EDGESHAPE)-[:REPRESENTS]->(edge:EDGENODE)
both edgeshape and edge would then to be related with neo4j relations each an incoming and an outgoing relation. this is the green solution.
Yes, I did
but it is not suited to Enterprise Applications
i created a prototype see screenshot
you can create shapes and relations, you can save them to the database. The objects can be queried in neo4j. I have also a "expand through relation" function. As you can see each relation has a Type for each Type you have a different HTML dialogue. My html for the dialogue is very flexible and can adopt to the datamodel of the relevant node type. But it can be customized easily. The metadata to be entered is validated with a rule engine (Kogito/ Camunda). Status Information is also a node and added through bpmn workflow (Kogito/ Camunda) under Review). The whole Application is secured through Keycloak and capable of multiple tentants. In addition to Keycloak DMN is used to create fine grained rules for access on the objects. I opted against neo4j built in security. I want to be open for rdf type databases as persistant storage too.
Layouting options such as in cytoscape will come. In the same sheet or a different sheet I'd be also able to add the same "real" node twice to depict other aspects of the Business Process and its related Objects.
So you can see, this is way different than Arrow. (I like Arrow for it's prurpose and I use it).
My topic is to get an outer view from this community on how to store the "uses" line and metadata (Order,PartId, BO_Revision) between the yellow shapes.
I will very probably publish a version of the source code. But I am not sure about the license under which I will publish.
blue nodes represent the sheet1
red nodes represent the yellow shapes in the screenshot of the precedent screenshot
grey and green nodes represent the actual data.
(Please ignore the FirstRev relation)
but as you can see there is right now no "LINE" between the red nodes that represent the relations of type "uses" between the grey and green nodes.
You're sort of asking design-specific questions about a potentially complex solution. Hard to guide you in the right direction as your requirements could change.
Who is your end user? or what is the use case you are trying to address?
once you get to more than 50 nodes on the screen, cognitive overload will happen anyway - so your solution is not for "dashboard" level if there is too much information already on the output.
enterprise master data with its relations, such as parts, bill of materials, instruction steps, shop flor routings. Value Stream diagrams.
diagrams like archimate or sysml
requirements, functions, logical decomposition, physical structures and their linkages.
modelling IT landscape.
think about modelling the IT landscape
a sheet with shapes representing servers, vms, cables, racks,... etc. Modelling via D&D and editing Metadata at a mouse click away.
E.g. you model the networking layer in on diagramm/sheet, an other one will model the software layer. A third one is modelling the virtualisation layer. Using the flexibility of diagrams combined with dialogues grabbing the metadata enables you to reuse models effectivly. (Visio/DrawIO/Diagram.net) etc... are just concentrating on the visual aspect of diagramming.
Everything changes if you combine these capabilities with a graph database or a semantic database.
The whole meta data beeing brought to neo4j with capabilities to store extremely large amounts of data and iterconnecting it with the master data. As a real example I modelled my IT at home including SmartHome Devices such as temperature sensors. In a second step I added the aggregated sensor data to the database, which was a peace of cake with mqtt & node-red. I related it to the home-it graph and I was able to learn about the dependencies between my solar panel, AC,Battery, E-Car. (I am just learning here, but you can imagine GraphRag Applications...). I would not or much less been able to get anywhere near to such results without a diagramm making me understand and easily search for the ip adresses/networkports/v-lan of my network.
I do not neglect classic UI (Trees, Lists, Forms) these are also important tools to enter data. (Actualy you have forms and Lists in my tool as you can see.) But they lack of network modelling capabilities. I also do understand that graph editing is not graph reporting or BI in general, this is not the use case.
Indeed. But both lack decent configuration capabilities, I implemented Node Versionning and Variant manamgement. I did not show but I implemented logical graph configuration/filtering based on DMN. In no way I would say that I have the Business Readiness compared to these tools. I am working on it . It is a hobby project for a few years now.
Configuration
it is about the rules that make a objectrelation valid
this means
have nodes each representing a version of an object
4711/V1 (hasStatus: Released/Release on 1.1.2025 Valid from 10.1.2024 to 20.1.2025
4711/V2 (hasStatus: Released/Release on 1.1.2025 Valid from 20.1.2025 to 20.1.2999
4711/V3 ... no Status
so if you want to query nodes you can enter Status data
so you get 4711/V2 if you query for nodes that with a valid date of 21.1.2025
so you get 4711/V1 if you query for nodes that with a valid date of 11.1.2025
you get 4711/V3 if you query for nodes without status.
the other thing is evaluating logical expressions on nodes and relations
e.g. related color/power attributes to a node...
relate an expression that returns true/false for each node
return calculated values (on runtime) for each node
a DMN configurator can establish a logic between color/power etc.
so you can configure with a vue 3/quasar app the input variables and retrieve the nodes based on the values. (cypher query is followed by the configuration filter evaluating the nodes expressions on the server).
i am not knowledgable enough for both of the systems. I worked with leanIX for IT landscape.
Service Now contact was mostly from an end user side.
SAPs take on versionning versioning: In most cases, versioning for applications doesn’t add significant value and should only be used if it’s relevant to your use case.
From my perspective I think this is perhaps fine in the area of IT-Management. Still I am realy questionning this statement. What about the number of interfaces between applications in a company.
Set aside, this tool is not dedicated on IT Landscape, like DrawIO, my intend is be more generic. But then offer enhanced configuration capabilities.
Think more like excel for graphs. Just slightly more structured. Low level entry but highly adaptable. Lowering the entry effort for graph adoption.
. It is a hobby project for a few years now.