⚡️ Ideas
Aura Aura Jun 7, 2023

Includes - the inverse of "part of" semantic fields

Explain the problem as you see it

I really love the "part of" semantic fields. I think they really help me with the structure of my workspace and use them liberally. However, I've now run into a situation where I would like the opposite.

I sometimes have a standard version of something and a deluxe version. The deluxe version has everything in the standard version, plus some extra stuff. Currently, to represent this structure, I have to use a "part of" semantic field on the standard version. This means that if I'm adding a new deluxe version after the standard one (as is often the case, there's a reason they're separate), then I have to start creating the new one, then go find the old one and add it there. It also means that adding the same data means I have to edit two separate parts of my workspace, which could potentially make things messier. (bi-directional fields would also help with this specific point, they could even work nicely with my solution)

Why is this a problem for you?

Structuring my data in a way that is intuitive and makes sense to me is important, because it helps me understand it better (and I'm not writing it down for nothing!). The harder I have to work to translate the stuff in my brain (or other sources of information) to paper, the harder it will be to do the reverse down the road.

Suggest a solution

Consider "includes", which does the same thing as "part of", but the roles are reversed! The node with the field becomes the "parent" component, rather than the "child".

⁨1⁩ ⁨Comment⁩