On Fri, Mar 28, 2014 at 4:39 PM, Kent Fredric <[email protected]> wrote: > > This example for me suggests we'll need to have some kind of process of > defining what tags should be used for what things, similar to how we have a > process for global USE, mostly, because inconsistency is a bad thing here. > Yes, you want a controlled, well-defined vocabulary. That's important. On the other hand, don't get too bent out of shape about it. These things fall over when you start adding dumb arbitrary restrictions like "there needs to be consensus" or "there need to be at least n packages beforehand".
> Because looking at this example and the results of `eix -cS terminal`, I see > lots of things that may also be ambiguously tagged "terminal" due to being a > terminal based application. > > Thus, either "terminal-emulator" or "terminal-app" or similar tags seem > necessary. > terminal: terminal emulators. Make it an alias to terminal_emulator. cli: things that have a normal, line-based terminal interface. See also: curses. It's not hard to choose good, unambiguous tags when you can use aliasing to shorthand and unify. That's why it's more important than implication, because controlling your vocabulary is seriously important. > And now that we're starting to flesh out mock tags that may make sense, it > quickly seems we'll eventually want some kind of tag hierarchy. > No. You really, really, reaaaaaally don't. At least not in the sense that you seem to be thinking. It makes tags annoying to add and annoying to use, so no one does either and the whole thing falls over. > But as long as the tag is restricted to [A-Za-z-]+ or similar, we should > have enough syntactical space to add a hierarchy in later if we find out we > need it. > Don't worry, we won't. With only the facilities I've outlined in my first post, the system will scale well beyond a million packages and tens of thousands of unique tags, so don't worry too much about exhausting our semantic description space. Cheers, Wyatt
