Review
Reading your post, the idea of Concept Dependency reminded me of the way that some people implement their Zettelkasten systems using Obsidian software. This software uses wiki-type links, and has the native ability that if you press control while hovering over one of these links, that you get a preview. These previews render (mostly) normally, except they are smaller than usual. They can still be scrolled like usual, links clicked internally, and so on.
I sometimes see people using these links in a way similar to how you are describing concept dependency posts. For example, if something contained a quote where a word is being used in an unusual way (like philosophers love to do), when you "peek" at the link you might see, for example, how the author previously defined the term.
I saw one implementation where the author would link to where they had previously justified the assumptions they were using in their research. Unfortunately I don't have any good resources specifically for this kind of implementation, though I think that my comments likely explained it well enough.|
For a similar idea regarding making scientific research (or any kind of academic paper, really) more modularly accessible in the context of storage or writing, you might be interested in some of the work that Joel Chan has done on Discourse Graphs. He has used a few other names as well, for example "iTunes for papers".
I think that "information architecture" is an interesting concept. These two ideas seemed the most closely related to what you're describing.
i like the idea. it looks useful and it fits my reading style well. i wish something like this were more common - i have seen it on personal blogs before like carado's.
i would use [Concept Dependency] or [Concept Reference] instead so the reader understands just from seeing the title on the front page. also avoids acronym collision
This is a Concept Dependency Post. It may not be worth reading on its own, out of context. See the backlinks at the bottom to see which posts use this concept.
See the backlinks at the bottom of the post. Every post starting with [Concept Dependency] is a concept dependency post, that describes a concept this post is using.
Problem: Often when writing I come up with general concepts that make sense in isolation. Often I want to reuse these concepts without having to reexplain them.
A Concept Dependency Post is explaining a single concept, usually with no or minimal context. It is expected that the relevant context is provided by another post that links to the concept dependency post.
Concept Dependency Posts can be very short. Much shorter than a regular post. They might not be worth reading on their own. Therefore the notice at the top of every concept post is added.
A piece of writing can make extensive use of references to declare requirements.
This is somewhat similar to creating a module in Python. You write up an explanation of a particular concept and "import" it into other documents.
Going one step further we can make dependencies more explicit by adding "import statements" to the top of the file. This import list can be automatically simply by listing all the links that were used.
As LessWrong already generates a backlink list at the bottom of the file however I will refer to that instead.
There is a very common failure mode for me when writing a post. I try to write down my entire motivation for thinking about the topic described in the post. Usually, I don't even get to the part where I start the technical explanation.
Potentially a concept post allows you to scope your post to only be about describing a technical problem or solution. A separate post can then be made to motivate the work.
I hope that this method will help prevent perpetual drafts by making it possible to complete individual posts in a shorter amount of time. Ideally within a single day, or even better, a single writing session.
When collaborating with multiple other people, I expect concept posts to provide most of the value of writing up your ideas.
Your collaborators will likely have a decent picture of what you are doing and why. Otherwise, they would not work on the project.
They mainly need to understand the technical progress that has been made, since they last worked on the project.
If you are working 3 days a week with Bob, and 4 days with Alice, i.e. you are working with multiple people in bursts, then this seems especially useful.
If there are multiple subprojects. This is also useful when somebody switches to working on a different subproject that they have not worked on before.