Open doridori opened 6 years ago
Is interesting. It talks about using triple store propositions to encode relationsships. It not cover the "because" relationship tho i.e. "dori MET rosie AT blah"
I guess this will inevitably touch on:
Questions on mind at present:
1) When should something be a node vs a vertex? i.e. we may have a subject e.g. Agriculture and off that a node for Charities for the field; actually just writing that the vertex would mark the charity relationship. Maybe just asking the question "how are these things related" is enough. 2) when should something have a tag / property as opposed to an "is a" relationship to something, for example "WWF is a charity". Should this be a relationship to a Charity node, or should this be a property on the WWF node? (maybe properties are not common in graph DBs? 3) What do we do when the relationship has some data i.e. tomatoes likes being planted with sweetcorn because one fixes nitrogen and the other needs it.
Really I think we want to be able to create and edge from an edge...
Thinking about the nature of the data we want to store, and how we want to navigate it and the types of querys we want to perform on it, maybe we dont actually care much about it being a graph db. Do we want to be able to run queries looking at many levels deep? Not sure we really care about that. Thinking of how we will use it we want to store text with forward and back links / relationships, and probably information about those relationships.
We should sketch out some knowledge here. Maybe even an SQL or document / JSON store would be fine.
Not sure we even care about timely visualisation of the graph
https://codingsight.com/how-to-make-use-of-sql-server-graph-database-features/
The below fundamental types of node are potentials:
OR alternatively, the above should all be tags or otherwise on a node...
Partly depends on the power of the query language, and what logic we want to use to grab display sets