Like, what can it be used for that can‘t be done with simply having a property ‚type‘ that tells what type it should be?
That question is more like a general pondering and maybe I am not aware of certain things. But I am just wondering what‘s the „purpose“, besides the semantics. Because sometimes I would like types to have more distinct functionality.
Some example of functionality that’s already here now (newly) is that now there‘s properties attached to types and automatic sets per type are created.
you could also do this with a property
advantages of types here are that the app gives a type a unique role. it has it’s own set of properties, it’s own templates and it’s automatically categorized with the properties that apply to this type.
a book type automatically has authors as properties while in my project type I don’t want to have the clutter of all the other properties that don’t apply here (when I do / / add property I only get the list at first with the properties that apply).
I can easily say “new / task” and everything is set, type task, correct template and so on.
The more I have to do manually the more cluttter and friction it could produce in my head.
In theory one could do such things also in Obsidian for example where everything is just a markdown file and you distinguish by type yourself, you have a MOK, templates, eventually use templatar to do some automation, have bases for your queries. But everything there is done manually and one has to come up with a structure themselves and it’s also needed to keep it adjusted over time so everything still works together.
With apps like this the user becomes a frame that helps them to structure their data. A basic types structure that is pre-defined helps users to get started pretty much right away.
Graph enjoys the benefits of type a bit. We can Cluster by Type, Filter by Types. display/hide Type edge. At the moment, these can’t be done through relation/property.
Ideally with Better filters for the Graph View , we could have more control over what’s shown on graph, including relation/property.
Inheritance is another benefit of type, although currently icon is the only obvious inheritance from type.
See Sub-Types for more functions which can be implemented with type
Despite these advantages, as of v.0.50.4, I still use a custom property/relation to distinguish my types/sub-types. My properties/relations are generally used across all types e.g. “Core” relation to indicate hierarchies across all object types, “Presenter” (with aliases of author, speaker, cast etc in my mind) relation for books/movies/podcasts and my notes where I took the role of presenting.
Let’s say you use a completely manual/paper system and you have a human assistant. The assistant handles all of your contacts and shopping requests. You write down your new contact information and new shopping order request information in separate pieces of paper or card. So you would take a card or paper slip, write ‘contact’ on the top and then write down the name, address, phone number, etc. You would do something similar to order something: take a card or slip of paper, title it ‘new order’ or something like that, and type below what the item to be ordered is, the quantity, etc. Your assistant would look at the title and immediately know what it is and what needs to be done with it. You typically would not combine a new shopping item request and a new contact in the same card.
It is like that with AnyType (or object-oriented systems in general), with AnyType being the assistant. It can take these cards and not only manage them efficiently but extract more value out of the combined lists like counts, total shopping costs, linking to other ‘types’, etc.
So ‘types’ are the mechanism of telling AnyType and yourself or anybody or anything (think software) else what is the piece of data you are talking about.
Right, grouping the properties with a type, it’s so ‘basic’ that I overlooked this somewhat. That alone justifies their existence. Well, I guess with that my concern is obsolete now and I made a fuzz for somewhat nothing
But since I started this already, as an example what I would love: that when i create an object inside another object, that they automatically link each other, but more specific than just the backlinks. (in my object „home pc“ of type „device“ i create an object „admin“ of type „account. my home-pc then automatically has a property „accounts“ linking to „admin“, and vice versa.)
I was having the exact same thoughts about that there should be automatic default set per type. Then a while later this was implemented. Which I liked, but it took long and generally the focus seems to lie on a lot of other things then the types themselves (I guess?). But utilising the types strongly is why I would love a type-based concept and for me those things seem somewhat basic.
So I’m not sure if I’m expecting too much in that regards. Also I’m surely not the most crazy power user here, so my experience with such systems is rather limited.
this is interesting but the implementation should not get rushed.
I think just because I link to something doesn’t mean for me that the parent object should have this type as a property or as an attribute. I could just link to something for informational purposes.
Sometimes there can be a reason why some things are not that automatic.
What might be a solution that could interest you is bi-directional linking, like connecting two properties together that automatically link to each other. like when you have your “pc”-object with the property “accounts”, you link the accounts object there and the accounts objects automatically gets the property “pcs” with the pc object linked automatically or something similar. this thread then might be of interest to you: Automatic Bi-directional linking + Rollups - #88 by tomtschke (you already posted there I just have seen)
everyone has their focus and subjective priorities. for every implementation there is a reason and thinking behind it. also you have your background and expect things that you consider as basic (and potentially experienced in other apps) but are not so present in the headspace of others.
that’s why this forum exists and if a lot of users unite to express their wish for a specific feature, chances are high that they will recognize it.
Thanks for elaborating so thoroughly on this, I appreciate it (all of you). I have never contributed to such projects by participating, so it feels not that natural for me to navigate between „voicing your thoughts about things“ and „a lot of (clever) people have already thought about this“.
But yeah, it definitely makes sense what you are saying, also regarding too much automation and such. Definitely puts my mind a little at peace now with that.
I guess my mental challenge is somewhat that there will always be some tedious manual work required, that there will never exist a perfect system that handles this for me completely. I‘m at that stage now.
This is and will always be true I think Even if you would code your personal assistant yourself that does everything you need at this moment in your life it might not be suitable anymore in 10 years and needs adjustments as you also evolve, project requirements change, life happens.
Therefore having a solution that is very flexible helps in this regard, an app that you can change yourself depending on your needs.
But for sure I’m not saying that things can’t get improved, this app is still in beta overall and things change quite often.
Even if you would code your personal assistant yourself that does everything you need at this moment in your life it might not be suitable anymore in 10 years and needs adjustments as you also evolve, project requirements change, life happens.