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
