[WikiEN-l] Categories (was: Hello)

Steve Summit scs at eskimo.com
Tue Dec 12 20:26:57 UTC 2006


I wrote:
> My own take on the question is that Categories in their current
> form are an imprecise mechanism, and that people should not try
> to use them for precise tasks, or waste too much time arguing
> about particular attempted more-precise usages.

By which I mean, the argument usually boils down to trying to
decide precisely whether category membership is supposed to
denote an "is-a", "has-a" or "is-related-to" relationship.
But that can't be answered, so the arguments can never really be
resolved, and people have to fall back to using categories not
to implement rigid OO-like inheritable hierarchies, but rather,
looser collections where the only semantic attached to category
membership is "is-kinda-related-to".  Some categories and the
editors who maintain them will reach some kind of loose,
relatively informal consensus that they're categories which
embody a web of loose relationships (e.g. "Topics relating to
Paris"), and some will similarly reach some kind of loose,
relatively informal consensus that they're categories which
embody a tighter taxonomy (e.g. "Counties in California").

Now, despite what I said about the problem not being solveable
without additional and potentially more-complicated technical
mechanisms which aren't likely to happen soon, it seems to me
that one loose, relatively informal, "soft" solution to the part
of the problem would be to try to reflect a category's semantic
in its name, e.g. "Category:Counties in California" and
"Category:Arrondissements in Paris" and "Category:Topics relating
to Paris", rather than just "Category:California" and
"Category:Paris".  And we're probably doing a lot of that today.
But there are still (and will always be) lots of problems when
categories contain other categories, and we'll always be
wondering whether category membership is or isn't or should or
shouldn't be transitive, and it's these larger-scale questions
which we can't (under the current architecture) ever fully
satisfactorily resolve.




More information about the WikiEN-l mailing list