I think that’s a good text key name.
Related to your screenshot, I “blogged” a few ideas at the bottom of this thread about discoverability and profiles (calldata templates), that can be retrofit into ENS relatively easily.
Let me quickly recap:
- red → Resolver (I like the term Record)
- orange → Profile!
I think we should make the orange thing a standard that we can encode/decode in contracts. Some of these can be immutable, some can be append-only, some can be fully customized. We should give some of them ENS names, like profile.ens.eth.
I suggested using an exotic coinType since that can store arbitrary data but a new resolver profile would work too (but not backwards compatible.)
The usage is simple: let’s say you want to read the profile of cory.eth:
(1) There exists a global profile, maybe profile.ens.eth, which should be unruggable (on-chain, append-only) that effectively is:
{ texts: ['url', 'avatar', 'description', 'notice', 'keywords', 'com.discord', 'com.github', 'com.reddit', 'com.twitter', 'org.telegram', 'eth.ens.delegate'],
coins: ['eth', 'btc', 'bnb', 'doge', 'ltc', 'dot', 'sol'],
contenthash: true,
pubkey: true }
Except it should be encoded efficiently, where each additional record should only consume 1 slot.
(2) There may be a name profile, which is referenced in addr(cory.eth, C) where C is the exotic coinType that stores the profile, like keccak256("ens.profile") or something.
If cory.eth’s resolver was ENSIP-10, then this field could be off-chain. This means that synthetic, offchain wildcard domains can “advertise” all of the stuff they support.
The client merges (1) and (2) together and reads those records to display “the profile” and filters out anything they don’t know how to decode. 
I suggested other ideas for making the name profile a pointer to another user’s profile or another contract.
Say we agree "education" is the correct key, how many apps need to make a change? Literally all of them. If we use profiles? Append to the standard ENS profile and hit refresh.