Objects as tags, with relation

Feature Requests
, ,
1

WHAT DO YOU RECOMMEND

Objects and relations are the basic elements of Anytype. A lot of functions are grounded from objects, including contents/blocks and relations. That’s why some users would want to convert relations values to types or objects.

Tags currently works under relations. Maybe object-supported relation can already delivery the functions of tags relation :thinking: (Just my speculation as a non tag user)

What if we enable object as tags? It might be easier to add another function to the robust object system instead of giving everything to the tag system.

Please add your ideas if you use tag frequently.

HOW COULD IT BE DONE

  • One key feature of tags is the coloured text and background, so perhaps we can reuse object’s cover colour as tag colour? Or allow colour selection for tag display next to cover or layout at the top of an object.

REAL WORLD USE CASES

Project and theme can be objects as well as tags. This way we don’t have two separated elements of the same thing.

Serving as alternative of visual cues like icons, objects can display with colour background and text as content of relation. For example, emotion objects can be represented by colour e.g. blue as sadness. This supports quicker observation in set/collection.

RECOMMENDED ALTERNATIVES

N.A. Continue to use the current tag system.

ADDITIONAL CONTEXT

  • This is a reversed solution or expansion to the ‘promote relation to type/object feature’: Instead of converting tag into objects, this method allows object to become tags.

  • Object with long title might cause display issues.

  • This might influence display of tags in graph.

  • This might also be another to solve nested tags. Users can create their own relation to determine the hierarchy of objects, or use hierarchy/semantic versioning of object feature. Then we don’t need two hierarchical structures in Anytype.

  • This should resolve reorder of tags, since users can already reorder objects in object-supported relation.

  • Not sure if this would interfere tag as object (as draft on roadmap 2024Q3).

2

Basically, what the “Links to” relationship does, right?
If a tag is an object and is linked to my main object, that’s it.

And you can do it (you can’t edit Links to directly, so you have to go and edit tag1, which isn’t playable in practice, it’s for the demo and to understand the proposal).

image
image977×519 16.7 KB

For the color : it’s a link, so being able to display the icon would be logical (Anytype should generalize icons, sometimes there are, sometimes there aren’t).

But I suppose “tag as object” will meet all these needs.

Oh, as a fan of tags, I ticked on yesterday’s Town Hall, when I saw a widget that seemed to contain tags. :heart_eyes:

3

It would show in ‘links to’ relation.

Object-supported relation is the following object type. You can already use and show icons, as well as clicking twice on the object’s name to get a pop-up/preview object .

image
image1202×778 72.5 KB

If custom object-supported relation is pinned as favourite, you can add, remove and reorder objects there.

image
image692×698 43.3 KB

To clarify, object as tag is practically different to tag as object. Functions might be put in different location. If it is tag as object, the colour selection will remain in relation pane at the three dot button next to each option; if it is object as tag, the colour selection will need to be managed in object/canvas. But both serve the goal to more functions to tag and object.

That’s also why I decided to prioritise this idea. :wink:

4

One function which tag supports but not object-supported relation is grouping criteria (e.g. on Kanban board).

If Anytype implements object as tag comprehensively, this will have to be considered.

5

Hey @C.c , it makes more sense to me to name the FR as “Tags as objects” instead. Do you mind if I change that?

6

If renaming FR helps the team, sure. But objects as tags and tags as objects are fundamentally different in concepts and implementation.

7

Yeah, I guess there’s a bit of a difference now that I’ve read it more thoroughly. This would be more about the tag relation type itself.

8

Is this functionality similar to Logseq tags?

In Logseq, tags are just objects, no difference between referencing them on the body or as tags. (in Anytype terms, doing @object or tagging object is also linked and referenced as backlink).

It would be awesome, because I am finding I am duplicating a lot of tags that are proper objects

9

Although I haven’t used Logseq before, I recognise there are two features of tags in Logseq which is missing in Anytype’s tag: inline tag (something like inline relation) and tag as object (already on roadmap, even though we don’t have any information on team’s plan yet).

This feature request focused on relation component to tag relation and suggested a conceptually different approach to implement object as tag, enriching the function of both object and tag. So both object and tag can have:

  • Icon
  • Background colour in relation
  • Categorisation (like in kanban) or search

Now come to think of the implementation, if we reduce the boundaries between tag and object, would it be useful to have different functions for the different linking symbols, # and @?
(to be further brainstormed because these options are/might not inter-compatible and compatible with some other feature requests on forum)

  • calling for display options e.g. # for colour and icon and text, @ for only text
  • distinguish a different relation/connection type e.g. # for mention, @ for relation, or two part input (@relation#object for object-supported relation or alias)
  • as /link requires a few more steps to have card display, perhaps we can use @ for card display and # for mentions
10

I think you should try Logseq tags, because, if I am reading it correctly, its exactly that.

To be clear, since you say that you haven’t used Logseq, it does not have tags!!!. (as in, a special item, not related to objects/pages)

For example, in Obsidian, mentions (@ in Anytype) are different from tags (#). But in Logseq, they are the same! The only different is in the “display” of each one, where the tags look more like usual tags.
But non the less, in Logseq, doing a mention or a tag is exactly the same thing. So, comparing to Logseq, if Anytype allows to tag existing objects, it already does “inline tag”, just through mentions only.

See for example this explanation on Logseq tags: Page Links vs Tags in Logseq | Aryan Sawhney

Quoting the important part:

If you’re anything like most people who first come to [[Logseq]], you may be wondering what’s the difference between a [[page link]] and a #tag

Truth be told, the difference is primarily visual. For the most part, they are both the exact same in functionality. They both link to another page. If you click one it will take you to another page and both will appear on the linked references of that page as well.

So, if I am understanding everything correctly, I thank you very much for opening this Feature Request, and for Anytype team to implement it.

(as a curiosity, when using logseq at first I thought the tag system in logseq was bad, and wished it was like obsidian, where tags are different, separate things. in time I discovered that I was wrong, and really appreciated the way logseq’s tags work)

As for the differences in visual, It would really be great to have a difference visually from @ to #. It greatly helps in Logseq.
As for the different types of linking, there is still the very common way of linking [[ ]] , which could be used for inline text display. @ could be used for card display and # could be used for tags.

11

Reading this a bit closer, I do believe Logseq’s concept of tag is indeed close to what I envisioned, at least from a non-tag but heavy-relation user’s perspective.

However, considering the existing difference between link/mention and relation and the strong support over tag-relation in the community, I would say this feature request doesn’t attempt to combine object and tag into one thing or compressing the tag function into display options alone. This should allow tags to be used outside block-and-editor/canvas as well.

Through the use of different relations, users should be able to create their own tag relation (or use the existing tag relation in enhanced form) to:

  • retain a tag structure (if desired, e.g. tag hierarchy through collection specific relation)
  • distinguish the connection status - link/mention or relate
  • limit queried objects for searching for easier reach for the required object e.g. search syntax, or through advanced filter for object type in object-supported relation
  • hide or show in graph, through graph filter to show only certain related objects; or even decide the location of the tag/relation display e.g. mimicking the profile and online status, this is how we can show an due task on graph, using a border line or a red dot on the object’s icon (If the icon is larger) ← a possible idea for a different feature request
  • etc.

Some of these functions are based on utilising or enriching existing features in Anytype, thus I omitted some explanations for easier reading. But these should distinguish between Object as tag with relation and Logseq’s tag/link system.

12

Thanks for the reply, but I must say that these are outside of my capabilities.

All I know is I am happy with the Logseq system, and it could work very well on Anytype too :slight_smile:

13

Perfect synthesis of different needs. I hope they will be heard and addressed as soon as possible.