Just for what it’s worth, there is a program I previously used for doing the stuff I’m now doing in fibery, and it used the concept of subtypes to achieve the result that @Oshyan is talking about
That is to say, enabling/disabling field visibility. You could choose for each subtype which type fields were to be visible/accessible. When an entity was created, you had to choose a subtype.
It was actually possible to change subtype subsequently, and a minor issue I discovered by experimenting was that, the contents of the fields/relationships that became hidden when you changed subtype were not actually affected, because it was only the visibility/editability that was enabled/disabled. This had some interesting consequences.
So in @Oshyan 's example, if I changed an entity from subtype ‘Company’ to subtype ‘Person’, the ‘employees’ field would still contain data, but just hidden, so a person would in effect take on employees(!)
I know that example is kinda weird, because why would you change from company to person?!
In my case, I would use the subtypes to distinguish between manufactured parts that were sellable products (with a ‘Product code’ field, an ‘SKU’ field and a relationship to a ‘Label’ type) and parts that were only sub-assemblies for internal referencing. In this case, an item could move from one subtype to another. It could confuse people if, for example, a product became a sub-assembly and yet appeared to still have an ‘SKU’ and be linked to a ‘Label’.
Anyway, long story short, I think true polymorphism is a more elegant solution 