I think it’s more complicate and it need two things :
a solution to filter and display tags by “folder” in the search menu
a solution to attach relation to something
Attach/label relation to a collection can be relatively “simple”.
But if you want to manage this link to make it more open (link to a collection but also to a project or personalized category), you need to plan all the management around it.
For the display and filter in the search menu, no matter if the “folder” is the name of a collection, of an object type or whatever.
It can display all relation unattached or attached to current collection/object type + folders for storing relations.
A simpler solution would be to display “classification name - relation name” each time.
We don’t need to invent new names for our “Tags” relationships, we just need to be able to label them, whatever the label.
I made a picture of my idea how the “list” for choosing a Tag could look like:
At first glance good. The list becomes much shorter because it’s two-dimensional if there are folders or groups or tabs.
But thinking further, we’ll find out, that some Tags belong into more than one category.
The Tag “Matrix” could not only belong to “films”, but also to “philosophie”.
“Education” fits not only in “finance” (because it causes costs), but also in “books”.
I wouldn’t go so far to suggest “Relations” for Tags to solve that little problem.
No, I think such a simple 2-D structure would help a lot if used with sense.
Maybe most Tags belong only in one single category.
The user could put the rest of them in a category “universal Tags”.
For the programmers noting would change, everything can stay as it it. Only the list for choosing Tags must be extended the way the picture shows.
Make each item in the list movable with the mouse.
And add a button “New Tag Category”. All done!
I also agree with @Shampra that collection-specific relation serves different levels of functions from tags.
Collection-specific and Object Context are identicators for situational use of relations. For example, with a collection for the shopping list of a date, I wouldn’t want to create buy apple task for each purchase to track spending/prices across the whole year (that would mean 52 objects per year for apple alone if buying once per week) Cause each ‘buying task’ could also be reused/repurposed for bookkeeping / expenditure tracking.
And I don’t imagine anyone would use tag with date #Christmas is fine though…
And as a non-tag users , I would prefer to create objects and MOC, and then use object type relation for themes, categories and concepts… There are lots of contents and descrptions within each topic and they could continue to grow, for example ethics and metaphysics with Kant, London eye and boroughs for London.
Btw.: you can have more than only one Taglist.
Wouldn’t it solve the problem to make some of such lists?
Go to Library/Relations and create some new lists!
Hobby-Tags
Profession-Tags
Philosophy-Tags
and so on.
If you are in the Philosophy-Collection, then use the list “Philosophy-Tags”.
This concept has a limit: if you use a global Set that catches all Objects from all over the place, then you’ll have a bit hassle with the filter. Because there is no longer one big list of all Tags, but some (shorter) lists.
But I think this little hassle shouldn’t be a big deal.
@Code-Jack To be on the same wavelength: this post is about better relation management, not tags .
Tag hierarchy has its own FR here :
@raph talks about the problem of having too many tags (tag relationships). I’ve got the same one, I’ve got different “tag” relationships depending on the subject / project… and I’ll soon have tons of relationships with the same name. The same goes for dates, etc.
This makes the search list very cumbersome. And the titles of my tag relationships can’t just be tags, but something ugly…
Ah, yes in deed … the discussion drifted a bit away from the topic after I answered to @raph who complained about the overloaded and growing Tag-list.
Thanks for bringing me back from my dreamland to reality!
OK, back to the main topic:
I would suggest folders in the Library where we can move the Relations in, for grouping them, simply by moving them with the mouse.
Same way like files in the windows desktop
If we later want to add a relation to an Object, there should a list appear in which we first see the folders. Then we open one of them to pick the desired Relation.
I think this way it would be very easy to implement for the team.
This was just my personal opinion on the topic. It seems like the devs have not acknowledge this one yet.
Although, sets and collections will be merged in the future, so I’m not sure how relevant this FR will be then.
The spirit of this feature is probably Contexts of Relation, similar to Object Contexts. Even when sets and collections are merged into list or whatever that would be named after. This need still exists.
If collection is no longer a good place to implement this idea, maybe the following options will be feasible:
This remains a very high priority item, and it seems the Anytype team still hasn’t acknowledged it.
I also want to say that having type-specific relations wouldn’t work. One concrete examples:
I have many ‘projects’:
research project on Israel/Palestine
research project on White Supremacy
day-job
fitness
Most of my types (atomic note, research note, task, human, organization) get tagged with a ‘project’ that they are related to.
Many of my tags are related to projects (like ‘Israel/Palestine tags’, ‘Israel/Palestine time period’, etc) and get applied to many different types: I’ll add the relation ‘research project A tags’ to the atomic notes, research notes, tasks, humans that relate to research project A.
=> type-specific relation wouldn’t work
What would work, however, is a tag hierarchy where I could have a parent tag ‘Israel/Palestine’ and subtags ‘tags’, ‘time-period’, etc.
Please realize that everyone thinks their FR is a high priority so they can get their work done. The team needs to accommodate ALL FR and triage them.
You spoke of tag hierarchy. @Code-Jack also spoke of it. I too am adding my backing to this topic. I like how obsidian does it…they have hierarchy tags; you can display them in a widget on the side and can click on any tag in the tree and it will list all the objects…a live search of sorts. You can also use and create hierarchy tag on the fly INLINE suing ‘/’ to delineate the hierarchy. Ex: geopolitics/europe/countryXYZ.
Hierarchy tags are used absolutely everywhere and have proven their worth. It would completely eliminate the need for what you, me and others do…to divide our tags presently into various ‘groups’ of type…such as TaskTypeTag, ProjectTaskTag, BookmarkTag, etc…
From what I understand, Anytype will implement the same thing with Tag as Object update, BUT I don’t understand if they will bring a hierarchical/taxonomy with it. Or at least, allowing users to create their own.
Given that tags as object have been relegated it seems to future date now, I highly doubt hierarchical tags will make appearance anytime soon unfortunately. You can always follow their roadmap on github to see what they are working on.
Since it is going to be new year soon, YouTube has been showing me videos on ways to plan for new year and Gamification of life seems to be a thing which people do in Notions/Spreadsheets.
I think Collection-specific relations, and Derived Relations (Formulas) would support this type of use case a lot. For example, during work focus, Tasks should only show work related materials; but then during time off, those same tasks could be XP earning challenges for gamification. This way collection-specific properties could be constrained to gamification context only.
On a broader application, because community once again discussed about Prospective naming of Collections & Sets in community space and the term smart collection surfaced, I am thinking contexts of property/relation will empower smart collection. We can query objects but collect properties in the “collection/list”.
P.S. I still want to mention Relation Data Model and calling foreign keys/objects because this might be a more structural but flexible way to link different combinations/sets of properties/relations with Objects for different contexts.
Cause each ‘buying task’ could also be reused/repurposed for bookkeeping / expenditure tracking.
, I would prefer to create objects and MOC, and then use object type relation for themes, categories and concepts… There are lots of contents and descrptions within each topic and they could continue to grow, for example ethics and metaphysics with Kant, London eye and boroughs for London.
.