I have read this question several times, and fundamentally, it seems to me that there appears some uncertainty about the function of
Tags in the domain. In one place you show:
Tag1: Personal -> develop -> Neo4j
Here this looks as if the
Tag1 contains an ordered list of categories.
Yet in the diagram that immediately follows this description, it looks more like
Tags hold a bag of potentially independent
Since it is fairly straightforward to arrange
Categorys in various ways relative to each other, such as traditional hierarchy (like an org chart), or other kinds of hierarchy, we don't necessarily need
Tags to help with that.
Further, we can assign a
Note to multiple
Categorys, also without using a notion of
So, what is it that you want
Tags to offer? This is a question to ask of the domain; it is not a question of whether using SQL vs. Neo4j graph database vs. RFD triples.
Asking this question of the domain means understanding what users will see; what behaviors/manipulations they expect available. For example, for one, are
Tags really needed/expected? For another, if we add a
Category to a
Tag (or otherwise update a
Tag, do we expect all
Notes sharing that
Tag to be updated? (In other words, do
Tags have some identity, or are they just values?)
Depending on the answers to the question of what
Tags mean in the domain of interest, we can model them in either SQL using table or a graph database using nodes and relationships. It is not at all contrary to graph databases to introduce as many entities and relationships as needed to appropriately model the domain.
An advantage of graph databases is that we can store new relationship types without needing to create new relational tables, and we can search all the relationships without naming relational tables. This means that an existing query may find results in relationships that are newly added, something that wouldn't happen in a relational database, because the query would have to be updated to incorporate the new table. Still, we need to represent different kinds of information using different nodes and relationships; graph databases don't remove the need to have different entity types and different relationship types as required by the domain.
Sometimes, however, a graph database (and like RDF triples) can be limited, and this means introducing somewhat artificial solutions.
One example is representing (different) ordered collections of (the same), e.g. Categories. Keeping the various ordered collections separate from each other basically is a great use for ternary relationships, which are not supported in modeling systems that provide only binary relationships.
With Neo4j we might turn to the value attributes putting in an order number into the relationships that collect Categories (e.g. into a
Tag). (If the extra operand of the ternary relationship is a node instead of a value, this won't work in Neo4j.) This (also) won't work in RDF since we can't attribute relationships with values, and instead will have to introduce a whole new triple (binary relationship).
In these situations, somehow we have to shoehorn all relationships into binary relations and this means creating an arguably somewhat unnatural entity to represent extra operands as a single element that can be referred to by a binary relationship. In these cases, there are somewhat arbitrary choices in how to do that, much like how compilers have multiple choices in how to compile high-level source code constructs to assembly language. For example, we can create an entity that represents two of the operands, then target that in a binary relationship. Alternatively, we can use a Davidsonian approach, which is that we create a "statement" entity, and grammatical verbs (relations), such as "Subject of" (not necessarily to be confused with yours), "Object of", the "Patient of". Then we can make multiple individual binary relationships describing the statement as a whole and representing its more complex relationship. An article on Davidsonian representation of complex staterments
This is why I consider modeling systems that don't have higher arity or higher order as more analogous to assembly language, requiring some method of translating more complex naturally occurring relationships. Good for machines to manipulate but not necessarily appropriate for direct human consumption.
Still, most relationships are binary, so a lot of things can be modeled in binary-only relationship systems without these complexities.