# Type / Relation to represent missing Relation

**URL:** <https://community.anytype.io/t/type-relation-to-represent-missing-relation/8643>\
**Category:** Feature Requests\
**Tags:** Meta, Graph-View, Types, Properties, Hierarchy\
**Created:** [March 30, 2023, 2:19pm UTC](https://community.anytype.io/t/type-relation-to-represent-missing-relation/8643 "2023-03-30T14:19:09Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![C.c](https://community.anytype.io/user_avatar/community.anytype.io/c.c/32/10820_2.png) [@C.c](https://community.anytype.io/u/C.c)\
**Post date:** [March 30, 2023, 2:19pm UTC](https://community.anytype.io/t/type-relation-to-represent-missing-relation/8643/1 "2023-03-30T14:19:09Z")

</div>

### WHAT DO YOU RECOMMEND

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

### HOW COULD IT BE DONE

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.

### REAL WORLD USE CASES

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(?).

### RECOMMENDED ALTERNATIVES

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.

### ADDITIONAL CONTEXT

> [@Object/attribute collection - use hierarchies and semantic versioning](https://community.anytype.io/t/object-attribute-collection-use-hierarchies-and-semantic-versioning/5523):
>
> I think, moving forward, that there will be value in having the object collection distributed in distinct hierarchies with versioning and owners. there should (imho) be CORE generic attribute types, (bool/str/int/float/enum/address/lat-lng/street/city/state/country etc) there should (imho) be CORE object types/templates These should be curated/owned by anytype. These should be distributed versioned. There could be add-on collections (scientific | architectural | fashion | creatures | plane…

> [@Nested Relation / Treat Relations as any other objects / Sub-Relations](https://community.anytype.io/t/nested-relation-treat-relations-as-any-other-objects-sub-relations/2973):
>
> Is your feature request related to a problem? Please describe. There are certain things that are not cleanly achievable with the current relations implementation. i.e, One cannot have a qualifier for numbers. Say there is a relation called as distance traveled, one has to remember the unit for the data or to use the unit name in the relations name. Another example is the lack of [currency qualifier](https://community.anytype.io/t/number-relation-units/2912). There are ways to achieve it, one could create a new type called currency that takes two values, …

> [@Add attraction and repulsion forces control in Graph View, and make relation names optional](https://community.anytype.io/t/add-attraction-and-repulsion-forces-control-in-graph-view-and-make-relation-names-optional/5779):
>
> Is your feature request related to a problem? Please describe. I’ve switched to Anytype after trying out Obsidian and Notion, hoping that it would include the advantages from both of them. However, the graph view in Anytype seems harder to navigate and interpret. The most obvious reason for that is the cluttering of nodes, and, sometimes, the strange behavior of the node positions. Describe the solution you’d like I think that it would be a good idea to refactor the forces applied to nodes mo…

---

<div class="post-metadata">

**Author:** ![Wolfspyre](https://community.anytype.io/user_avatar/community.anytype.io/wolfspyre/32/3004_2.png) [@Wolfspyre](https://community.anytype.io/u/Wolfspyre)\
**Post date:** [March 30, 2023, 4:38pm UTC](https://community.anytype.io/t/type-relation-to-represent-missing-relation/8643/2 "2023-03-30T16:38:01Z")

</div>

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 ?! 🙂 ) 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!

---

<div class="post-metadata">

**Author:** ![C.c](https://community.anytype.io/user_avatar/community.anytype.io/c.c/32/10820_2.png) [@C.c](https://community.anytype.io/u/C.c)\
**Post date:** [March 30, 2023, 8:40pm UTC](https://community.anytype.io/t/type-relation-to-represent-missing-relation/8643/3 "2023-03-30T20:40:10Z")

</div>

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.

> [@Wolfspyre](#):
>
> 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…

Your wording is way clearer than mine, for what I previously termed as value (relation) of relation in [my first impression,](https://community.anytype.io/t/first-impression-of-the-many-things/8468)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.

---

<div class="post-metadata">

**Author:** ![Wolfspyre](https://community.anytype.io/user_avatar/community.anytype.io/wolfspyre/32/3004_2.png) [@Wolfspyre](https://community.anytype.io/u/Wolfspyre)\
**Post date:** [March 31, 2023, 1:54am UTC](https://community.anytype.io/t/type-relation-to-represent-missing-relation/8643/4 "2023-03-31T01:54:22Z")

</div>

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 🙂

---

<div class="post-metadata">

**Author:** ![C.c](https://community.anytype.io/user_avatar/community.anytype.io/c.c/32/10820_2.png) [@C.c](https://community.anytype.io/u/C.c)\
**Post date:** [March 31, 2023, 3:37pm UTC](https://community.anytype.io/t/type-relation-to-represent-missing-relation/8643/5 "2023-03-31T15:37:21Z")

</div>

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 🤣

---

<div class="post-metadata">

**Author:** ![Wolfspyre](https://community.anytype.io/user_avatar/community.anytype.io/wolfspyre/32/3004_2.png) [@Wolfspyre](https://community.anytype.io/u/Wolfspyre)\
**Post date:** [April 19, 2023, 1:35am UTC](https://community.anytype.io/t/type-relation-to-represent-missing-relation/8643/6 "2023-04-19T01:35:53Z")

</div>

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.

🙂 I’ll stop there 😉
