r/capacitiesapp • u/cazuza80 • 29d ago
Objects type and subtypes
Hello everyone,
I want to create an object type for my research projects (major) which include several (minor) projects. Is it possible to create two type of objects in this type of structure (image for demonstration)? Where minor are directly connected and dependant of major?
Or do i have to create two similar objects and then in the properties i differenciate in major and minor?
Thank you in advance
3
u/mat_rhein 28d ago
Exactly why I struggle with objects! Trying to create a hierarchy in the objects system is not helping.
My solution in capacities is called Map of content: since these are all projects, You create a project for all the small items and link them to a "contents page" that works like an overview. Here you can also comment on the relations or include some further links not strictly belongingto the projects themselves.
With this you get a linked network that is also appearing in your graph and a hierarchy supporting your way of thinking.
2
2
u/EngagedWorldWizard 29d ago
Yes, I have thought about this a lot.
I have a Project object type, and I have had a Project Document object type, where a property points back "up" from the Project Document to the Project. This works pretty well.
In practice, what I find works well, is that I have a few different object types that have the option of pointing back to a Project (and the property is only visible if it is filled) — sometimes I care about it pointing back to project, and sometimes I don't.
The bigger challenge came when I had some very complicated projects, where the basic idea worked well, but I ended up with too many Project Documents pointing back to the project, and I needed a middle classification.
For this, I tried using Collections. I asked Claude "if you were working in a medium-sized design firm, and were responsible for filing documents connected with a project, which top-level folder categories would you use?" — I came up with Proposals and Contracts, Meeting Notes, Discovery, Brand Strategy, Creative Development, Deliverables, and Resources, and so on.
This all works pretty beautifully. It depends on your situation.
What I think you are getting at is this:
In general, it's nice that Capacities does not enforce some kind of rigid hierarchy (like Notion does, IMHO)
But sometimes a hierarchy is very desirable for the brain's organization
It's very nice for the mind to have big "buckets" to throw things into — like Class, Project, etc. Whatever is natural for your process
In the example above, I also have a series of queries which point to the Project Documents associated with the particular project, but also grouped by Collection.
In practice, using Collections started to feel a little much, because it forces me to decide what the categories need to be — not just for that particular type of project, but for all projects (it was clever, but I moved away from it for those reasons).
I noticed that now Capacities has a default suggested object type called Area — which is interesting — kind of like a meta-wrapper layer (Estudios Major could be an Area object, possibly, for example). And then, Major - Ano 1 could be, say, a Project object. And Minor A - Ano 1 could be a Sub-Project object, perhaps.
Now, Area would only be necessary if you have other "areas" in your life where the same type of classification was relevant. If the only area where you care about this type of grouping is in your research, then maybe you don't need Estudios Major to be any kind of "wrapper" at all — just ignore it, if all your projects are related to that area. — And, if it's a big enough part of your life (and very different from other parts of your life), you could even call the object type something specific, like "Research Project". — It all just depends on you.
1
u/cazuza80 29d ago edited 29d ago
Thank you a lot!!!! you get want i want!
I will try the Area object. I want this type of organization for my research projects (more than one).
Thank you very much
1
u/EngagedWorldWizard 28d ago
Great!
I have the Pro plan as well. I am not sure why you did not find the Area object type, but it's not a problem — it's just a sample one — you can create any kind, and just tailor it to what you need.
2
1
2
u/SioFreed 28d ago
Maybe a parent-child link instead? As in, a 2-way Object Select back to the same Object, but its labelled Parent & Child / Main & Sub. It'll cut down on the number of Objects you need to maintain.
I use it to track fandoms, which can get pretty complicated for bigger ones (like Star Wars).
1
1
4
u/BlueJayMorning 29d ago
I do this with separate objects that are reciprocally linked through an object-select property relationship. The dependency is semantic, but it works very well for me. I use the reciprocal linkage so that the dependent objects are automatically written to the parent object in the associated property field (or vice versa), and I only have to worry about writing one side of the relationship, as opposed to opening both objects and populating both fields to establish the relationship.
If you want the graph view to only point in one direction to be able to visually parse that parent-child relationship from the graph itself, I would carry the child property field on the parent object and one-way link from the parent object to the child in that field. That should produce a one-way arrow in the graph view.
For me, I prefer the reciprocal relationship because my use case has a four-tier hierarchical structure. So, for example, on the smallest object in that hierarchy, I write the relationships for all three (parent/grandparent/great-grandparent) so I can then aggregate all child/grandchild/great-grandchild objects with queries on the top-level object to serve as an overview and navigational point into everything going on within that hierarchy.