doridori / Lore

Graph Database knowledge-base with front-end display
0 stars 0 forks source link

RFC-2: Approach to modelling data in knowledge graph #2

Open doridori opened 6 years ago

doridori commented 6 years ago

The below fundamental types of node are potentials:

  1. Nodes that represent some information
  2. Nodes that point at some external resource (book / site / film etc)
  3. Nodes relating to primarily educational resources
  4. Nodes that allow for categorising data

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

doridori commented 6 years ago

https://github.com/jbmusso/awesome-graph

doridori commented 6 years ago

https://www.yworks.com/products/yfiles

doridori commented 6 years ago

Reading list :) https://www.google.co.uk/search?q=knowledge+representation+transfer+and+learning&oq=knowledge+representation+transfer+and+learning&aqs=chrome..69i57.8543j1j7&sourceid=chrome&ie=UTF-8

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"

doridori commented 6 years ago

I guess this will inevitably touch on:

  1. How should we approach the logical separation of concepts and datatypes
  2. How should we allow editing/new input of said data
  3. How should we allow display of said data
doridori commented 4 years ago

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.

doridori commented 4 years ago

https://discourse.cayley.io/t/beginners-guide-to-schema-design-working-thread/436

doridori commented 4 years ago

Really I think we want to be able to create and edge from an edge...

doridori commented 4 years ago

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/

doridori commented 4 years ago

https://conference.knowledgegraph.tech/

doridori commented 4 years ago

https://stackoverflow.com/questions/64214453/what-is-the-idiomatic-way-to-add-connected-meta-data-to-an-edge-using-a-graph-da

doridori commented 4 years ago

MORE READING!