> 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.

Well, "valid" is in the eye of the beholder. :) It's valid in Wikipedia, but
on other wikis (like mine), it could be considered invalid: technically
possible, but incorrect.

-Yaron


On Tue, Mar 4, 2008 at 12:12 PM, Jon Lang <[EMAIL PROTECTED]> wrote:

> 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

Reply via email to