Add Smart Tags feature (tags implying other tags)

(Missing Feature, Investigate , Priority: Medium, Test Status: No automated tests yet , Reported By Bad Link: Thing 3y284oe not found, )
Summary: In most tagging systems, some tags will always accompany others - eg, if I'm tagging my URLs, and one tag is "Eclipse", that URL should always additionally be tagged with "IDE", "programming", "Java", "Java SDK", and about a dozen other things. It would be lovely to be able to specify an "Implied Tags" Property on a Tag Thing, and have it Just Work. (Ideally multi-level, so if X implies Y and Y implies Z then X implies Z, though that's obviously more work.)
I passionately wish every tagging system in the universe supported implied tags. Tagging taxonomies just about always have these "if X, then also Y" implications, but the technology ignores that, foisting the problem onto the user, who must either:
  • Make the rule implicit in queries - which means that if you're interested in everything "programming", you have to combine ten zillion different tags; or
  • Make the rule explicit in data-entry - which means you always have to enter a ten zillion tags, and remember all the details of what tags always-imply what other tags whenever you do data entry.
I have only minor need for this feature at the moment. This is me wishing and dreaming.
This could be implemented as a macro (ie, tags added via implication end up stored no differently from those added by a user) or as a system (so if you decide that "sunshine" shouldn't imply "astronomy" after all, when you remove that implication then "astronomy" stops showing up on "sunshine"-tagged items where it wasn't explicitly entered); while the latter is probably cleaner, like multi-level implications, it's probably more work.

Justin: I'm honestly unsure about how best to represent this, but the concept is certainly intriguing. I'll chew on what the semantics ought to be.
One complication, though: in Querki, a "Tag" is just a Name, nothing more, so it is difficult to say that it really has semantics. So whatever mechanism we use here is necessarily going to be loose. But I could imagine having a meta-Property which, if the named Thing actually exists and this meta-Property is on it, it specifies the implied Tags.
An additional complication is keeping this both consistent and efficient. If we're going to do this, it ought to remain consistent, as described in the second part of the description. That's best done by computing the implied tags at lookup time. But that's potentially extremely expensive, so we may need a better solution...