My name is Marco

Hello fellow Graph Database folks,

My name is Marco, I am from Germany.

I am a communication design student with a degree in computer science. I am planning to use neo4j for a typography experiment, where I collect materials to build typographic sculptures. Those will be displayed on a graphic web application that connects materials, sculptures, tools, visibility, size etc.

Neo4j was my second choice after I planned everything for SQL. Since neo4j already has the capabilities to display graphs, I chose to work with a graph database finally. I hope this supports me in finding rules for displaying this information in the visual style I chose.

Have a good day :slight_smile:

Hi Marco,

I think is a very original application of GraphDB.
Consider this:

Please, show some example of your graph.


1 Like

Hi Marco
Welcome to the community in case of any need; kindly let me know

1 Like

Thanks for your contribution,

I am still in the early phase of the project and my aim is a working prototype for now. After that I will go into algorithmic graphic generation.

graph schema

So far it's a pretty small schema, since I want to create content on a broader scale that doesn't go too much into detail. I wasn't really sure how to scheme the SUBPROJECT_OF relation in the database. Typically, from an SQL perspective - I would have it as a hierarchical structure in the Projects table. Since I wasn't that sure about that in a graph perspective, I added a second label (Project2). The green dots are data sets quantifying the projects.

The graph representation on the website looks like follows:

Here it will serve as a tool to visualize pathways between Material and Projects (the distinct sculpture). My web programming is primitive but extendable, just like the graph.

If you have a project with two materials (nodes) you will always see the relationships with the other materials even if you make a query for only one.
The reason is that the relationships are one layer above the nodes.
I think that if each project uses only one material your schema can work. In this case, however, it would be enough to insert the material property in the nodes, even as a list of materials, and it would be easier to query nodes with more materials.


In my first queries I was wondering why I was retrieving lists with multiple subprojects, sounds like that was based on the project-built_with->material connections, since for example all 4 relations are visited and thus returned to the table.
I've seen this right now because I forgot one collect function call. Right now I have full control with collect(DISTINCT ...).

I've read into Force-directed graph drawing, but since I plan to avoid intersecting edges, I will try to see if I can keep my graph planar. I think finding an algorithm for that raster display might be pretty challenging.