It seems that data which needs to answer expected and unexpected many-to-many questions by users might be best kept in nodes that consist of small, or singular, sets of properties linkable through UUIDs of some kind.
In relational databases it makes sense to group properties into sets using tables. This creates rigid data structures and relationships that model entities of all kinds. But if we wanted to ask all kinds of interesting questions of the data which might request unusual relationships, associations or correlations it seems that the schema-on-write structure makes this use case second class or non-intuitive, and the schema-on-read structure makes this easy.
If an application allowed users to compose sets of tags to request properties those tags might be associated with strict types of properties. In a graph database I guess this might be persisted in a separate graph and used as a lookup? Or would tags be added to the existing graph, either onto relationships or in nodes?
Interestingly, schemas seem like they can be modelled in the nodes (using property sets) and/or modelled in the edges - if I understand graphs correctly. But perhaps if the relationships and UUIDs of each property in each node are designed well there may not be any need for schema?
GraphQL (and DQL) seem to be ideal for schema-on-read applications (more so than REST?)?
I have no database management experience so looking for guidance from experienced admins and data modellers. Thank you.