573
edits
No edit summary |
|||
| Line 37: | Line 37: | ||
==== Isn't one category per article a too strict limitation? ==== | ==== Isn't one category per article a too strict limitation? ==== | ||
Yes and no. In fact, some articles might be useful in a couple of far related categories. An example is given by [[Modeling - Getting Started]] and [[Howto:Lightmap]] (as most of the effect/animation related articles). These articles clearly belong to a couple macro-categories: Category:Aircraft enhancement and Category:Scenery enhancement. But there's also Category:Modeling and Category:Effects (well... pretend it exists). | ''Note: this part might be too thoughtful for what it needs to explain.'' | ||
Yes and no. In fact, some articles might be useful in a couple of far related categories. An example is given by [[Modeling - Getting Started]] and [[Howto:Lightmap]] (as most of the effect/animation related articles). These articles clearly belong to a couple macro-categories: Category:Aircraft enhancement and Category:Scenery enhancement. But there's also [[:Category:Modeling]] and [[:Category:Effects]] (well... pretend it exists). | |||
This is the problem of orthogonal (i.e. independent) categories. On one axis, there seem to be the area of application (scenery, planes) and on the other particular technologies and techniques (Nasal, effects, modeling, ...). If the wiki allowed a "cartesian product" between chosen categories <u>''when searching''</u>, we could actually "tag" the articles, one tag per axis, and there would be means, when browsing categories, to see directly articles that have these tags combined. | This is the problem of orthogonal (i.e. independent) categories. On one axis, there seem to be the area of application (scenery, planes) and on the other particular technologies and techniques (Nasal, effects, modeling, ...). If the wiki allowed a "cartesian product" between chosen categories <u>''when searching''</u>, we could actually "tag" the articles, one tag per axis, and there would be means, when browsing categories, to see directly articles that have these tags combined. | ||
| Line 52: | Line 54: | ||
Even if this was possible, it would need a ''very carefully'' selected set of axes and categories. | Even if this was possible, it would need a ''very carefully'' selected set of axes and categories. | ||
The alternative, though, doesn't look so bad in this wiki, because the number of "axes" of categorization is very limited. One should simply replicate in the category tree what the cartesian product would do.<ref>I had to make those categories better, because scenery modeling might refer to both objects and terrain, while for aircraft it could be 3d model or physics model</ref> | The alternative, though, doesn't look so bad in this wiki, because the number of "axes" of categorization is very limited. One should simply replicate in the category tree what the cartesian product would do.<ref>I had to make those categories better, because scenery modeling might refer to both objects and terrain, while for aircraft it could be 3d model or physics model</ref> An example could be the following: | ||
<pre> | <pre> | ||
* Scenery development * ... | * Scenery development * ... | ||
| Line 59: | Line 61: | ||
* Aircraft development * 3D modeling | * Aircraft development * 3D modeling | ||
* 3D model effects | |||
</pre> | </pre> | ||
Long story short, what I propose is to replicate this kind of divisions in every macro-category that needs them. Which one of the "axes" should become the macro-categories is technically a detail, but given the current organization and the fact that a user will probably be focused in modeling planes ''or'' scenery, pretty much answers the question. | |||
In conclusion, ''yes, for some articles that have use in different fields it is appropriate to use more categories''. But at two conditions: | |||
* ''those categories must be strictly comparable in their own macro-category''; | |||
* ''that article really needs to be valid for both areas''. | |||
A note on the second point. I've seen articles that seem written just for aircraft/scenery modeling, but that actually are fine for the other too. In general one should aim not to split such articles, so that the same kind of knowledge stays at the same place, so that when some new technique is available you don't have to update two articles (and be sure they'll go out of sync). | |||
=== Remarks on development articles === | === Remarks on development articles === | ||
edits