Hacker News new | past | comments | ask | show | jobs | submit login

The issue at the heart of both the Zettelkasten and the PARA methods seem to be that a person wants their notes to be connected in useful ways. To an extent, "ordinary" knowledge graphs permit this -- where by "ordinary" I mean that the edges are unlabeled. Things are related to other things, but you have to infer the relationship yourself after looking at both of its members.

Graphs with labeled edges seem clearly better. But then what if you want a relationship with more than two members? (Or less! "Not" and "maybe" are two important unary relationships.)

And what if you want a relationship's members to themselves be relationships? This is the nature, after all, of most information. Any but the simplest sentence is a relationship between relationships. "Children ask for cookies because cookies have sugar", for instance, is a "because" relationship bewteen an "ask for" relationship and a "have" relationship.

Once you've reified your relationships that way, you'd like to be able to search intelligently through them. "Ordinary" knowledge graphs let you see all of a thing's children, or parents, or maybe in some cases all it's descendents and ancestors up to some level of recursion. Better would be something that lets you ask targeted questions, like "Show me everything Sally has asked me to do that does not require a computer."

To my knowledge there's only one program that lets you reify your data and query it in the ways I've described. It's called Hode, for Higher Order Data Editor. I wrote it.

https://github.com/JeffreyBenjaminBrown/hode




That's pretty cool Jeff! Those insights are probably used a lot by researchers working on general AI.

How much work does it take you to add your notes to it? I'm curious about it on two dimensions:

* The time it takes to add a note

* What decisions you need to make to add a note (what to link it to, what not to)


Thanks!

You've zeroed in on the weakest point of the program. Adding notes is mechanically easy but conceptually hard. That's because there are many ways you could choose to represent the same concept.

For instance, suppose "harry gave sally a book" is in your graph. One way you could represent that is "Harry #gave Sally #object a book". Another is "Harry #did (give #object a book) #to Sally". Another is "Harry #did (give #object a book #to Sally)". And actually maybe you'd prefer to represent "a book" as "#a book", so that you can just search for "book".

They're all plausible representations, and all have different implications for how you would run searches. You've got to be consistent in how you represent those relationships, and the program can't help you because I mean it's a database, not a general artificial intelligence.

The strength of the program is that the structure of your index is entirely up to you. But soon that freedom gives way to being bound by the decisions of your former self. And your future self will inevitably understand the space you're representing better than your former self did when it bound you.


Got it. Yeah, this is one of those instances where the paradox of choice can kill you.

Just a thought: if I were interested in adopting a tool like that, my chances of successfully sticking with it would go up 100x if there was a set of "default recommended practices" to follow when saving a new note, to cut down on the decision I would need to make.

Then over time, as I got more familiar with the tool, I could always tweak those default recommendations to fit into my own style

And who better to offer those default practices than the tool's creator? :)


(Mechanically, adding a relationship is as simple as typing "/add I #like turtles" and pressing enter.)


sounds very much like a mind map. i don't know if any mind map programs allow that kind of search though.




Applications are open for YC Winter 2022

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: