Yaron Koren wrote: > Hi, > > Correct me if I'm wrong, but: your argument against using categories only as > indicators of "class" (which is still my preferred approach) seems to be > two-fold: first, that their ease-of-use makes them preferable to using > semantic properties - in other words, it's a waste of the nice functionality > of categories to only use them for limited purposes; and second, that > categories and classes are two different things that don't really make sense > being conjoined anyway. Is that right?
More or less. Let me add, though, that the first point is a direct result of the second. The reason why Category pages have built-in article indices is is _because_ their purpose is different from that of classes. A class exists to define the nature of its members; from a class perspective, you could ditch the index and the page would still do its job. A category exists to provide a common access point to a set of conceptually related articles; removing the index would destroy its ability to perform in that capacity. The fact that catalog pages have built-in indices is evidence of their true purpose. And I'm not saying that it doesn't make sense to conjoin[1] classes and categories, so much as that it doesn't make sense to equate them. As you point out below, they do have enough features in common that it can make sense for classes to be implemented as categories. What doesn't make sense is to turn this around and insist that all categories must always be classes. More on this below. > If so, I would actually disagree with both of those: for the first, it's > true that categories automatically create a nicely-formatted page listing > all of their members; but it's not that hard to create a page that could > create a similar list using an inline query or, yes, an inline query > template; and inline queries are in some ways better, in that they allow you > to display additional information on each page. It may not be very hard to create an inline query, especially with templates; but it's still an additional step that you would have to take that you don't have to take at all with a Category page. This is because Category pages were invented with this purpose in mind. Telling me to use a regular article with an inline query instead strikes me as being akin to telling me to reinvent the wheel. That said, you're right about the extra power available to inline queries. I have no problem with the idea of having, say, a "__NOINDEX__" magic word that shuts off a category's automatic indexing so that you can substitute an inline query in its place - much like the "__NOTOC__" magic word that can be found in MW already. > Maybe what would help would > be a format for inline queries that mimics the nicely-alphabetized structure > of category pages? Oh, definitely. But as a supplement to traditional category pages; not as a replacement. > For the second, I would argue that categories are in fact a good match for > classes. They both generally allow only one kind of relationship to them > ("is-a"), and they both have automatic inheritance, meaning that if you > belong to a class or category, you're automatically a member of any of its > parent classes or categories. I'll agree on the second point: page-vs-category relationships are inherently transitive. But the core of my point is that the relationship is _not_ always an "is-a"[2]. The concept of the wiki category doesn't care what kind of relationship an article or subcategory has to the category, as long as it's transitive. It _can_ be an "is-a" relationship; and to the extent that it is, the category should act like a class. But _only_ to the extent that the relationships are "is-a". The relationship between an article on Los Angeles and the City category is an "is-a" relationship, with the category playing the role of the class and the article playing the role of the individual. Conversely, the relationship between an article on Urban Planning and a City category is _not_ an "is-a" relationship: Urban Planning is not a city. But while it's not a valid class/instance relationship, it _is_ a valid category/article relationship. You've voiced distaste for this sort of relationship, and have suggested alternatives that conform to your preference of only using "is-a" relationships; but that doesn't change the fact that it's still a valid relationship. -- Jonathan "Dataweaver" Lang [1] conjoin: to join together (as separate entities) for a common purpose. [2] by "is-a", I mean a class/instance relationship: the class (in principle) makes general semantic statements about a set of things, and the members of that set (the instances, or individuals) conform to those semantic statements. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel