Type / Relation to represent missing Relation


Add a new type of relation to represent missing relation. This is to show things are missing or to be filled in.


A new type or relation can be added and showed on relation creation.

OR enabling absence as nature or property of relation (similar to sub-relation: two values of one relation), this allows users to do everything they want with all features of current design. (I prefer this one)

In graph view,

  1. Display as repelling force (allowing the observation of distance)
  2. As dotted line (to differentiate nature of relations) Or indicator on the connection line
    These two approaches might not be functionally co-existable.


Doing research or observing relations, we will have criticism and find limitations or missing consideration of certain factors. These are relations / relation object that don’t actual relate in the context but are indeed relations in our mind as missing relation that should be filled in.

This could serve secondary purposes to support task management, to display necessary completion of prerequisites. Like gantt chart(?).


With relation as object to be implemented later, we can make a criticism / limitation object containing an idea object, to show the nature of relation… but the hierarchy of objects will get more complicated / become messed up. Graph view will not be as intuitive as well.



I like this idea… sort-of a proto-anti-object … or an object-agonist… or a class of objects… I can see uses for the ability to express and illustrate relationships with things not-yet-defined, or known…

Perhaps this could be more flexibly facilitated through adding “state” or “charge” or “polarity” or “presence” as meta-descriptors/attributes to all existing&future objects…

I grok where you’re going with this ( I THINK ?! :slight_smile: ) and I can see the potential value and benefit of being able to represent the ‘anti-relationship’ of things… but I don’t know what the most elegant implementation of that would be, off the top of my head…

neat idea!

1 Like

You probably get what I envisioned. I was tempted to use the word ‘anti-relationship’ as well, only avoided because people wouldn’t understand it quickly.

Your wording is way clearer than mine, for what I previously termed as value (relation) of relation in my first impression, or nature or property of relation. State / polarity / power / intensity are always useful because of how rich relations can be. Presence of relation or attributes is like the sub-relation in other post (mentioned above in additional context) but a more structural form. By adding continuum or quantified layer to current relation format, represented by colours, force or length of connection, this could be visualise and implemented.

Anti-relationship is another layer though. Negative evidences or proof of wrong or not related or missing relation are non-typical relationships. In drawing, we might find a location as far as possible (as orphan node? which doesn’t make sense in global graph) or put a cross on the linking line? So some kind of indicator for the relation state is probably good.

Clean implementation is probably not easy, but if Anytype does this well, it will be way ahead of other note-taking app.

anti-relation is a weird concept… in that it’s so potentially applicable to so many things that it’s hard to conceptualize cohesively…

…IE agonist… or mirror… or counter-weight/balance

…the relationship between the forces of entropy and negentropy

perhaps a more flexible way of handling might be to be able to associate an object-type with a meta-object class, which has certain established properties which could be visually represented consistently…
ie primary/secondary properties of an attribute

a physical object has mass, composition, location

it consists of elements… which consist of protons/neutrons/electrons

which consist of ….

a conceptual object has distinct but enumerable properties

being able to hierarchically associate objects with their meta components could allow for a flexible but rich visual and virtual-physics-related representation of things and stuff™️

without needing to make the inter-connection/relational representation logic obscenely obtuse… (I think?)

this is why I was lobbying for a rich core taxonomy hierarchy that objects be composed of…

this stuff gets super meta and abstract super quickly :slight_smile:

1 Like

Object hierarchy and relation connection are two different things. (While to me, every relation is an object and every object can become relation). What I am requesting is richer relation display… but only with simple relation variation; not how object should relate to other object or multiple objects (that’s beyond the scope of this request)…

Hierarchy can expand to the end of the world. What I would suggest is to limit the extended context to 1/2, that way we could insert the immediate context to as a second level naming of object (as what I would name as sub-object). If it is direct relation, it would display as a near concept object, no further display is needed. But if it is an usage / application of concept in a different context that we still need to reference the upper hierarchy (Like 3-5+ hierarchy / depth away), then we don’t need to go down the rabbit hole, just a mention of relevant context object will do.

In high level thinking, every definition can be redefined to derive a different approach (like Anytype terminology). Therefore, there is a need to reference the context of the concept.

For example, in the context of psychology, needs in Maslow and needs in Freud are different… Looking at concepts, it is still simpler… but if we apply on people (and even only 2 people’s different reactions in 2 different incidents each), the graph already look pretty messy, especially if we link up the whole tree of concepts. I would probably isolate concept graph with people graph, by utilising local graph, filter and/or controlling depth of link level (like in Obsidian local graph), or even set graph.

Limiting the cognitive load / information is useful. This is what we do when we think too… we can’t go over the board. Our brain can’t attend to too much information at the same time. Butterfly effect is a thing but not necessary for all situations. Do some compartmentalisation - it helps.

This would bring a different issue, how can we distinguish context and concept? Upon object creation we could set different object type. This is where rich core taxonomy could take place, but the expected behaviour for different object type relating differently with another type can be ill-defined across different fields and within object type.

Fix hierarchy (as what taxonomy would mean?) make sense in a static form, but not dynamic… Concept’s hierarchy might be more fixated in physics but not necessary so in other fields. Relations are dynamic in many cases, depending on the viewing angle. E.g. Author is the owner object of a book… but book’s properties contains author; both can be sub-object to another. The hierarchy making process should depend on users’ creation. Local graph view feature will assist hierarchy making, if we add more relation display we. Parent-child-sibling relations (as outlinks and backlinks) should also demonstrate a lot.

Currently what I do is have a relation called “Core” to display it being the upper hierarchy / theme / category. Not so neat, but acceptable and observable.

Note-taking can be super meta and abstract, but it is really the basic for high level thinking… This shows how much we humans are capable of. We could simplify things and enrich the new simple and then continue to develop.

Hope Anytype team will invest in this type of thing… but we probably should not make it hard for them to make it happen too… is for the sake of both.

Sorry, but not sorry, we are nerds :rofl:


yep… you’re adept at navigating the metacognitive game of twister this represents…

This stuff is super fun to think about… AND you’re right that scoping the request concisely increases the likelihood of implementation.


From my perspective:

We have object A which is a specific instantiation of object-class-1
and object B which is a specific instantiation of object-class-2

The possible ways in which relationships between these two objects are scoped at three levels:

  • the amalgam of defined relationship constructs

  • the defined relationship points that are associated with object-class-1 and object-class-2

  • the specific relationships that object A and object B have.

I believe your request is to enhance the collection of defined relationship constructs to include a set of additional attributes/properties which may decorate specific relationships.

:slight_smile: I’ll stop there :wink:

1 Like