Conversation

In short: - Use block hierarchies as much as possible - Stick as close to natural language as possible - Any link can be used as a relationship - Add a minimal syntax to indicate that a block describes a relationship (I suggest the arrow: "->") Here's an example:
1
6
- [[Alice told me penguins can't fly]] - [[opposes]] -> - [[All birds can fly]] - [[type is]] -> - [[evidence]] - <- [[informs]] - [[Alice is a big jokester]]
3
4
[[Alice told me penguins can't fly]] has the relationship [[opposes]] with [[All birds can fly]], and the relationship [[type is]] with [[evidence]]. [[Alice is a big jokester]] has the relationship [[informs]] with [[Alice told me penguins can't fly]].
2
3
This could be like Discourse Graph's default ontology (types: questions, claims, evidence. relationships: supports, opposes, informs). More general ontologies could be provided as well (e.g. using existing work with RDF).
1
6
Side note: I'm considering knowledge graphs to be category theoretical categories and translations between them to be functors... I think this makes sense, but I don't have much rigor behind this connection just yet. Inspired by arxiv.org/abs/1909.04881 and
1
11
3. Make it possible to publish a subset of your knowledge graph and integrate other knowledge graphs into your own notes.
1
6
Once your knowledge graph is translated into a general ontology, anyone else who also has a translation into that ontology should be able to integrate your knowledge graph into their own notes. This would be a whole new way to share research and knowledge.
2
6