User talk:Cmuelle8/Archives/2017

Category:Created_with_Android_Camera

Created with Android Camera has been listed at Commons:Categories for discussion so that the community can discuss ways in which it should be changed. We would appreciate it if you could go to voice your opinion about this at its entry. If you created this category, please note that the fact that it has been proposed for discussion does not necessarily mean that we do not value your kind contribution. It simply means that one person believes that there is some specific problem with it. If the category is up for deletion because it has been superseded, consider the notion that although the category may be deleted, your hard work (which we all greatly appreciate) lives on in the new category. In all cases, please do not take the category discussion personally. It is never intended as such. Thank you!

grendel|khan 23:27, 25 March 2017 (UTC)

Metacat template parameters

Hello, Cmuelle8. When you create a metacategory, please include the required positional parameter on the metacat template. For example, on Category:Stone arch footbridges in Saxony by district, the template should look like this:

{{metacat|district}}

Thanks. --Auntof6 (talk) 23:27, 17 September 2017 (UTC)

Category:Bridges_in_Australia_by_state

Bridges in Australia by state has been listed at Commons:Categories for discussion so that the community can discuss ways in which it should be changed. We would appreciate it if you could go to voice your opinion about this at its entry. If you created this category, please note that the fact that it has been proposed for discussion does not necessarily mean that we do not value your kind contribution. It simply means that one person believes that there is some specific problem with it. If the category is up for deletion because it has been superseded, consider the notion that although the category may be deleted, your hard work (which we all greatly appreciate) lives on in the new category. In all cases, please do not take the category discussion personally. It is never intended as such. Thank you!

Mattinbgn (talk) 00:18, 3 October 2017 (UTC)

Categories by name

Hello, Cmuelle8. I noticed that you put metacat templates on "by name" categories. I changed some of them to {{Catcat}} and will explain.

Not all "by name" categories are metacats. To be a metacat, a "by name" category needs to contain only subcats that are for multiple things with the same name. A good example of this is Category:Hotels by name. You can see that none of the subcats there are for individual hotels: they are each for any hotels with the specified name. An example of a "by name" category that is not a metacat is Category:Volcanoes of Japan by name: each subcat there is for one specific volcano.

I know this can be confusing. I'm happy to answer any questions you have about it. In case you're wondering, I saw these because I watch what new metacats get created and I saw the ones you created or tagged. You're not the only person I've explained this to! --Auntof6 (talk) 20:11, 8 October 2017 (UTC)

Have you read my message on your discussion page to the word overcategorization? Again, instance naming is one dimension of a thing, just as its length, height or weight may be, consider it as an parameter that may or may not be unique. You (wrongly) assume that a given name is fixed (and unique) to a thing, but it is not. Think about the following situations:

• An object x has been built (and named) in the 13th century, renamed in the 18th, 19th and twice in the 20th century. (welcome by name by decade, formerly named .. metacats)
• (Nowadays) x is referred to by a nickname locally, the official name is not in common use (but the object referred is the same for both). (welcome by official name, by nickname, ..)
• x has a fixed location, but it may be named differently in different languages. (by name in language)
• The name of x may be disputed. In about the same time span you may have multiple sources telling you different names to the same object.

We cannot be sure to have checked all sources, which also means that we will never be able to tell (let alone prove) that the names to x we know about are the only ones in use (or the only ones that were). We should always remember that commons is merely a subset of human knowledge and a small insight in the languages used to convey, develop or preserve it.

In fact, the labels to your subcats in Volcanoes of Japan may very well have changed over time. They may not even reflect valid local names at all, and so on. The media in the subcat is assumed to reflect a specific volcano, yes, but its not necessarily its label that does so (!). Its label is one claim, one statement assumed to be associated with that object represented within these specific subcats. This claim may be revised, falsified or hardened, its not definite.

You're trying to aim for uniqueness, but commons does not provide this with the concept of names as are used in natural language. It's the structure (and the process of structuring) itself that may achieve this to some extent, although its never perfect. As the bulletins above show, names may be in flux - this is not true only for instance names, but also for names identifying concepts and ideas, classes. It all may change over time, because natural language changes over time. It may do so slowly.

This is one reason concepts like en:UUID were invented, you may finally argue. Let x from the example above be given a unique number (one from the en:UUID pool maybe). Then you can resolve all issues with a multiply named object, you may think. Let a specific volcanoe in Japan be assigned an UUID and you will be able to gather all name identifiers used over time, and those currently, by associating them with this UUID. The set in Volcanoes by name may be larger or smaller than Volcanoes by uuid, depending on the ratio of multiple names per volcanoe to multiple volcanoes per name.

→ But a name as understood in natural language is more powerful than that.

Add to the bulletins given above the following.

• An object x is demolished and replaced by a completely different object y. The name that identified x lives on to identify the new object, because there is a single, but important aspect that x and y have in common. Also, the name does not necessarily cease to refer to x as well.

This essentially means that (any) name may not only have siblings that identify the same object (in time or over time), it may also serve as a "bridge" to identify different objects (either together with all or just some of aforementioned sibling names).

All of these aspects have shown that a name (instance name or not) is not necessarily suited to identify a category (in the sense that commons uses categories). This is why we have category redirects and things named .. style cats after all. E.g. devil's bridge is a "unique" category label only until either another name for the same object is sourced or another object with the same name is found.

However, a name is suited to build categories and relations between them. When a unique instance name proved to have been an error of previous perception, commons is editable/revisable. Often its healed by adding braced qualifiers (but this necessity and its process alone proves my point: names are one dimension to a thing and not married or fixed to it). Commons Categories are not definite and may fail to reflect the nature of its equivalents in natural language. After all, Commons is not to dictate natural language or nature, but to comprehend it..

To sum it up, a metacat is anything indexing instances that may also be indexed by another of their properties. x by length, x by weight, x by height, x by number, x by name - all meta categories to x. There is nothing special about names to instances of x. --Cmuelle8 (talk) 00:42, 9 October 2017 (UTC)

Frankly, I have no idea what you're talking about, either here or on my talk page. I don't understand why you left an essay on my talk page, or replied with one here. I was trying to explain why some of your changes are contrary to the established use of metacats, and I can't tell whether you understood what I was saying. Maybe you could try more directly addressing what I said. Otherwise, I'll just keep making changes needed to correctly manage the "by name" categories. --Auntof6 (talk) 01:44, 9 October 2017 (UTC)

Which means you will continue to possibly falsify work of others. Please take your time and read the essay above. Here is a simpler way to say this, but the essay above is more complete.

• Most images (photos) on Commons are a secondary source of objects in reality (as are or as they have been).

• Commons categorizes images of objects, not the objects depicted. Most category titles on commons silently imply this.

Not recognizing that the cat title is merely borrowed leads to errors.
In the context it is borrowed from (e.g. natural language), the category may summon

• the object itself (primary source)
• images of the object
• images of the object on commons
• images of the object in the national library
• texts describing the object
• all kinds of other sources referring to the object

• Categories on Commons in general employs a traditional concept, see en:Categories. But it's not a singleton in doing so and it neither is this traditional concept (in fact it rather takes part).

A picture.

• The image to the right depicts a bridge. Categories (in the traditional sense) are, among others,

• Image
• Image showing an object
• Image showing a bridge
• Image showing an object named Мост через Сухону в Тотьме
• Image showing an object named Brücke über den Fluss Suchona bei Totma
• Image showing an object named Suchona bridge near Totma
• Image showing an object numbered 23432345_xyz in a semi-official catalogue
• Image showing a green object
• Image taken in 2008
• Image taken in Totma
• Image 2816 pixels in width
• Image showing a river
• Image on commons

• Commons cats reflect a subset of the above when categorizing photos (in particular the ones starting with Image showing ..).

• If you're looking for images of a bridge in Totma, you do need to know its name to correctly build categories

• Image showing a bridge
• Image showing a bridge in Totma
• Image showing objects in Totma

• If you're looking for the same bride knowing only it is one over the Suchona (and neither know its name or the settlement nearby), you might find it by building

• Image showing a bridge
• Image showing a bridge over the Suchona

• Finally, if you're looking for an image showing a bridge you just know its name of, you expect it to be found in

• Image showing a bridge
• Image showing a bridge named <bridge name you have heard>
• Image showing a bridge named <dutch name you have heard>

Notice how the name is in no regard special to other property claims on a depicted object. A property claim name need not exist at all to categorize images of the depicted objects.

→ If a name exists to an object depicted by an image that we seek to categorize on commons, then it is metadata with respect to the object depicted and wrt to its image.

→ If objects or images are categorized using metadata the results are metacategories. --Cmuelle8 (talk) 15:48, 9 October 2017 (UTC)

---

Of course, it may be true that the term metacategories, within the realm of commons, is defined slightly differently (but upward-compatible to the above).

Quoting from the documentation of Template:MetaCat:

Use this tag for meta categories only, that should only contain other categories [and] that are grouped by a specified criterion.

Sticking simply to this, all cats ending on by name are commons metacategories if and only if they group by name (i.e. name is the only criterion objects of the maincat are grouped by).

The main difference between Template:MetaCat and Template:CatCat is solely that CatCats do not imply that their members group by the same, single criterion. So every MetaCat is a CatCat, but not vice versa (in the way commons defines these). --Cmuelle8 (talk) 01:44, 10 October 2017 (UTC)

I think this is the point I was trying to make. Do you see a discrepancy between this and what I said? --Auntof6 (talk) 03:52, 10 October 2017 (UTC)

Not specifically in this respect, but I see a discrepancy wrt what you did; namely s. The difference you make between some by name categories and other by name categories is a difference not made by (the documentation to) Template:MetaCat. This template simply does not care about whether the cat names are instance names or class names; both are metadata with respect to the image objects categorized. So to stick with your original examples, both, Category:Volcanoes of Japan by name and Category:Hotels by name are metacats. Greetings --Cmuelle8 (talk) 17:14, 22 October 2017 (UTC)

I didn't apply Template:CatCat to anything that's a metacat. The documentation for {{Metacat}} says "Use this tag for meta categories only, that should only contain other categories that are grouped by a specified criterion". There is no implied "and" as you indicated above: each subcat in a metacat is a grouping of different things that share the characteristic named in the subcat name. In the case of metacats by name, that means multiple different things that have the same name. I understand the confusion, though: it comes from the fact that our category names use the phrase "by name" in two different ways. The first way is with metacats, as a shorthand way of saying "grouped by (shared) name". The second way is the English phrase "by name", meaning that you're going to refer to something by name, as opposed to by some other characteristic such as color or location (for example, "the hotel named 'Adams Hotel'" instead of "the hotel by the airport"). It might be that the documentation needs to be clarified: I'd certainly be in favor of that, because this distinction can be hard to understand. --Auntof6 (talk) 18:19, 22 October 2017 (UTC)

Ok, seems we're at the core of the misunderstanding. I very strongly suggest that the and is indeed implied while you read it without. With only natural language, both of our interpretations are correct (the term the word that relates to is fuzzy), but we have other data fragments to consider:

Deducting from all other by x categories, we learn that the documentation is to be interpreted with an implied and, no second level of indirection needed to qualify as a metacat. There is no indication whatsoever to assume that this is different for by name categories, regardless of whether the name is shared between different objects or not. The distinction you make can be made, absolutely, but it is one that neither Template:MetaCat nor Template:CatCat care about. (And to stick with your example, how in the world will you prove that 'Adams Hotel' isn't a shared name?)

Try to transport your distinction to another by x category. It will mean that you carry on to make a distinction e.g. between by (shared) height and by height. Just as with the name property, you will not be able to prove that objects in the latter category indeed have a unique/unshared height. That claim seems artificial, just as a claim about name uniqueness above, but for what Template:MetaCat is to denote it does not even matter: Both are MetaCats.

→ A MetaCat may group

• groups of one by a criterion x
• groups of n (with n>1) by a criterion x
• groups of groups of n (with n=1 or n>1) by a criterion x

.. and so on. Template:MetaCat is to be applied to any cat that groups y by a criterion x (and directly contains cats only). It is indifferent to the intrinsic properties of x; x may be

• shared name, single name, substitute name, (whatever) name (latter may imply a mixture of aforementioned)
• height range, specific height, max height, .., height (again, latter may in principle circumference a mixture of the former)

Greetings. --Cmuelle8 (talk) 12:26, 24 October 2017 (UTC)

---

This talk has not been about the mammal.

In fact, if you omit the implied "and", like this

Use this tag for meta categories only, that should only contain other categories [and] that are grouped by a specified criterion.

and relate the second that to other categories you get the definition for Template:CatCat. (Because each cat groups by a specified criterion, that's what all cats are for.)

It seems important enough to repeat: The difference between metacats and catcats is solely that all children of a metacat must group by the same criterion x, while children of a catcat are allowed to mix arbitrary criteria (from child to child). Or the other way around: A CatCat grouping all children by a single (same) criterion is a MetaCat.

I do not know if it's sufficient to simply add the implied and to the documentation to prevent misinterpretation. Maybe it's best to point out the difference (and hence the relation) between both categorization templates right away on their individual documentation pages.

I'd also suggest to create a dedicated template, if you feel the distinction of by (shared) name and by name cats is important. Just because the metacat template does not care about this does not mean another template can't. --Cmuelle8 (talk) 17:30, 24 October 2017 (UTC)

I still don't quite understand everything you're saying, but let me try to respond to some of your points:

• The documentation about what makes a metacat may not explain things well enough to cover the special case of "by name" categories. Nevertheless, what I have described is the way they are managed. I'd be very happy to work on updating the documentation to make it clearer. I would of course get consensus for any changes made.
• I'm not sure what your point is about "Adams Hotel". A category named "Adams Hotel" would be for an individual hotel and would not belong in a metacat. A category named "Adams Hotels" (plural) would be for multiple hotels with the shared name "Adams" and could go in a metacat. Look at Category:Cabins by country, a metacat that is not by name. Each subcat there has a plural in the name and is for any and all cabins in the indicated country. Likewise each subcat in a "by name" metacat, such as hotels by name, would have a plural in the name and would be for any and all things that have the indicated name. A "by name" category whose subcats are not plural, such as Category:Ice caps by name, is not a metacat. The purpose of a metacat is to contain subcats that group multiple things by a shared characteristic, something they have in common. A category whose subcats don't do that is not a metacat.
• Both "Volcanoes of Japan by name" and "Hotels by name" are names that could be used for metacats. It is the content in these that determines whether they are metacats.I

Your idea of a different template is interesting, but I think a different naming convention would be more helpful. I don't think I can explain it any more than I've already done. I understand your confusion, because others have had the same misunderstanding. We used to have many more "by name" categories defined as metacats, but they were changed to Template:Tlk because their subcats were for individual things, not for groups of things. When I get time, I'll look at improving the documentation to clarify the special case of "by name". --Auntof6 (talk) 17:41, 24 October 2017 (UTC)

You are missing the point that commons does not primarily group names, but image objects (or more correctly media objects). Let's stick to the Adams Hotel and a hypothetical Flower Hotel. E.g. both ought to be categories here on commons that host images of one specific hotel object on earth each, both located at a single, distinct location on earth each. One group of images show a hotel named Adams Hotel, the second group of images show a hotel named Flower Hotel; the category labels reuse the name of the object the images depict.

Now, if you group both groups of images into one category (read: add both of the categories discussed above into a new one), then what exactly have you done? (Think about this for a moment, please.) ... You have built a metacategory because you group a group of image files by the name property of the object these images depict.

This is in no regard different to grouping the image files by the roof color of the object depicted: One group of images will show a (single) hotel because it's the only one with a limegreen roof in the world, a second group of images will show hotels with a red roof. Again, if you group the two of them into a new category, you have built a metacategory, because you have added two categories that group image file objects by the same criterion (roof color) into a super category on top.

Note that you can group the image files directly into Hotels with limegreen roof and Hotels with red roof, either

• without another category level which groups by name of the hotels shown in these images, or
• with that added level of indirection.

In both cases Hotels by roof colour will be a metacat, no matter what.

If that second level of indirection is used, then if done correctly, there will be two second level metacats: Hotels with limegreen roof by name and Hotels with red roof by name (because you absolutely can group image files by roof color of a depicted object without using the object's name in addition and you can also use another criterion than the name as a second level criterion to group by; say height or length..).

Category:Ice caps by name is a metacat, because it groups y by criterion x (groups group of image files depicting the same object by name). The distinction you make between plural and singular cat names only tells you that there may very well be hierarchies of metacats grouping by name. I.e. you could simply build Ice caps by name by language on top, which may be a metacategory for Ice caps with Norwegian names, Ice caps with Islandic names and so on.

Again, to qualify as a metacat, a cat must only meet two things:

1. Its children must group by the same criterion (by that criterion given in the metacat title) only (counterexample: a cat with children categories Adams Hotel and Hotels with green roofs, because it mixes criteria name and roof color)
2. Its children may be categories only (not file or page objects).

As said, it is indifferent to the intrinsic properties of the grouping criterion used. --Cmuelle8 (talk) 18:54, 24 October 2017 (UTC)

Category:Bridges by length is an example where the children mix plural and singular instance of the criterion, nevertheless it is a metacat because lengths are a length each and hence the condition same criterion is not hurt (the first child Category:Bridges less than 1 kilometer deviates from the rest, because it groups lengths (plural) and not a single length / length range like the other children). It would still be a metacat without this first child and it would be so with all single length members replaced in such a way that they group more than one length or length range (like the first child). The metacat status is indifferent to the intrinsic properties of the grouping criterion used (it does not care if that grouping criterion is a plural or singular form wrt the image files grouped). --Cmuelle8 (talk) 19:38, 24 October 2017 (UTC)

Anticipating your issue, I'd say it is best to either create a new marker template or add a dedicated parameter to Template:MetaCat to accomodate the difference between metacats that strictly group images (media) of the same object per child and metacats that do not do this or defer it to children of children. Underlined is an additional condition imposed upon the more general definition of metacats (and it is a phenomenon presumably not limited to name criteria).

To stick with the examples above, Category:Ice caps by name, Category:Volcanoes of Japan by name may be special cases (if you will) of metacats and as such also catcats, but they are not exclusively catcats (more specific definitions available given in marker template docs do apply). --Cmuelle8 (talk) 19:47, 25 October 2017 (UTC)

Formalization sketch

We could also try to formalize definitions of CatCat, MetaCat, and special MetaCats if that helps. See e.g. set builder notation and specifying sets. Say all media objects (some 42 million currently) are in a universal set $U$, then

${\begin{alignedat}{1}\{\,\}\ &{\text{.. the empty set}}\\\downarrow \ &{\text{.. left hand side is defined}}\\C\ &{\text{.. set of arbitrary, distinctable criteria}}\\&n,n_{cc},n_{mc}\in \mathbb {N} ,\quad N,N_{cc},N_{mc}\Subset \mathbb {N} ,\quad c,c_{i},c_{j}\in C,\ c_{i}\neq c_{j}\\\end{alignedat}}$

${\begin{alignedat}{3}cat&\colon N\mapsto Y,&cat(n)\ &=\{x\in U:pred(n,x)\}\cup \overbrace {\{x\in cats:pred(n,x)\wedge x\neq cat(n)\}} ^{{\text{may generate }}\{\,\}}\neq \{\,\},&cats\ &\supset \overbrace {\{cat(n):cat(n)\downarrow \}} ^{\text{cats without page members}}\\&&cat(n)\ &\in cats,\\catcat&\colon N_{cc}\mapsto Y,&catcat(n_{cc})\ &=\{x\in cats:pred_{cc}(n_{cc},x)\wedge x\neq catcat(n_{cc})\}\neq \{\,\},&catcats\ &=\{catcat(n_{cc}):catcat(n_{cc})\downarrow \}\\&&catcat(n_{cc})\ &\in cats,&catcats\ &\subset cats\\metacat&\colon N_{mc}\mapsto Y,\ \ &metacat(n_{mc})\ &=\{x\in cats:pred_{mc}(n_{mc},x)\wedge x\neq metacat(n_{mc})\}\neq \{\,\},&metacats\ &=\{metacat(n_{mc}):metacat(n_{mc})\downarrow \}\\&&metacat(n_{mc})\ &\in catcats,&metacats\ &\subset catcats\\\end{alignedat}}$

${\begin{alignedat}{3}P\ &=\{pred(n,x):n\in N\},&&{\text{analogue for }}P_{cc},P_{mc},&&P_{mc}\subset P_{cc},\\P(c)\ &=\{x\in P:x{\text{ filters by }}c\},\quad &&{\text{analogue for }}P_{cc}(c),P_{mc}(c),\quad &&P_{mc}(c)\subset P_{cc}(c),\\&&&{\text{but }}P\not \subset P_{cc},\ {\text{in particular }}&&\exists P_{0}(\ P_{0}\subset P,\ \ P_{0}=P(c_{i0})\cup P(c_{j0})\cup {\text{.. }}P_{cc}(c_{i1})\cup P_{cc}(c_{j1})\cup {\text{.. }}\ )\\\end{alignedat}}$

$pred_{cc}(n_{cc},x)\sim \ {\begin{cases}&p\in \{get\_pred(z):z\in \{y\in cats:y\in x\}\}\wedge \forall p(\ p\in P\ )\wedge \exists p(\ p\in P(c_{i})\ )\wedge \exists p(\ p\in P(c_{j})\ )\\pred_{mc}(n_{mc},x)\sim \ \{&p\in \{get\_pred(z):z\in \{y\in cats:y\in x\}\}\wedge \forall p(\ p\in P(c)\ )\\\end{cases}}$

This is just a rough sketch (!), it pretty surely contains flaws, in particular the $pred_{y}(n_{y},x)$ predicate functions are not well defined (they lack a complete defintion and just vaguely hint relations between them). Please do by no means depend on this for anything else than further work, I'm not a studied mathematician. The example given for $P_{0}$ seems complex and may be hard to understand. It really only serves to recognize cases where catcats and metacats are children of regular cats (and hence the predicate generating the regular cat needs to wrap around those used to generate children). Every cat in mediawiki has a uniq page id, this is resembled by $n$. The concept of special metacats is yet missing, but i propose that it can easily be added. You might find similar, more complete and more correct formalization somewhere else, I haven't searched. --Cmuelle8 (talk) 19:47, 25 October 2017 (UTC)

Prior documentation (on commons)

@Auntof6: You may also have a look at Commons:Naming_categories#Categories_by_CRITERION, a help site I've not been involved with, but which basically supports what I've talked about above. Among others it refers to Category:Ships by name and Category:People by name as examples for by name metacategories. In particular the former belongs to the cases you were trying to carve out of the metacat set (it has categories for specific ships each, so each children category groups images of the same, individual ship using a unique label (some suffixed using curly braced qualifiers to obtain uniqueness)).

It rephrases the documentation of the metacat marker template,

These are special categories which are useful to group other related pages (not media files) according to a given criterion. They hold only other categories and should be marked with {{MetaCat}} template.

— Commons:Naming_categories

This means, there is a potential inconsistency between the various places in the help system that give definitions to the term metacat. (potential if the sentence in the metacat docs is interpreted your way; if read with an implied [and] both definitions are consistent afaict). --Cmuelle8 (talk) 14:18, 27 October 2017 (UTC)

That was written before we realized that "by name" was being used in two different ways. If you look at the text in the box there, you'll see an example of how a metacat is created and named. You look at a group of categories about things where 1) the things in each category have something in common that's identified in the name of those categories (they are spheres), 2) the thing they have in common is plural in the category name ("spheres", not "sphere"), 3) they each have a different value for some attribute (color), and 4) that value is also identified in each category me. The category name is then "Spheres by color". That works for categories like Category:Hotels by name because the subcats show the thing the have in common (they are hotels), the plural "hotels" is used in the subcats, each subcat is for hotels with the same value for an attribute (name), and the value of the name is indicated in each subcat name. If you have categories where the things I list above aren't present, then it doesn't work as a metacat.

As I've said before, I know the documentation needs updating/clarifying. I also know how it looks when I stick to a viewpoint and say that I'm right and the documentation is wrong. However, I assure you that what I describe is the way metacats are actually used on Commons. We used to have many more "by name" categories defined as metacats, but they were changed. By the way, there are some other criteria that are also not always metacats. A couple I can think of are "by registration" and "by serial number". --Auntof6 (talk) 16:04, 27 October 2017 (UTC)

It's nonsense and you know it, there is nothing wrong with the "old" documentation. It's people that are stubborn to realize that they've made a mistake and are reluctant to correct it. I don't blame you, this is indeed modern. Go on and keep telling people that they are wrong, when they are actually right (you've pointed out above that you've already sent a lot of other people into error). See, this is the point why people do not trust technology and stick to paper and "print out" everything they can get their hands on.

If you had seriously thought about this you would have realized that this is not about changing the way cats are managed (like you assume above), but simply how they are marked. What's so problematic about not changing an established definition and sticking to it? Why do you want to complex out a very simple thing?

Again, "by registration" and "by serial number" are crystal clear metacats, because they group their children by a (the same) criterion. Please find a new marker if you want to differentiate among metacats. It will aid you to not get confused yourself in the long run. It will aid to keep things simple. Find a new definition for what you want to define and create or edit templates to accomodate this, instead of brute forcing change to established definitions. --Cmuelle8 (talk) 21:42, 27 October 2017 (UTC)

In 1) above

things in each [children] category have something in common that's identified in the name of those categories

you're adding to the definition, this is not what the help system writes, it's not what was intended, it is a new definition. This new definition breaks with something that was intuitively understood: A metacat groups y by criterion x with y being cats (no frills whatsoever). Ok, you've realized this yourself. You say you go on by killing the documentation to support your viewpoint (you call it update). Why can't you keep your point of view using a new doc (building upon the foundation)? The more complex a documentation, the more easily it is misunderstood, chances are high that the next person (or group) in your tracks will simply "update" what you've changed. This is what may happen when travelling in the direction you announced. Another chance is that people will recreate a new marker template with the old definition you're about to trash. You've probably thought about all of this, so go ahead. I've made my point and consent: What you're about to do is indeed confusing. --Cmuelle8 (talk) 00:28, 28 October 2017 (UTC)

Here's the example from the help page, adopted to ship names (changed things highlighted). For this example all your points 1) to 4) above apply.

Example

Assume [..] you want to group pictures, which are Category:Ships, showing ships of a given name. The associated set is an indefinite list of names, like King George, St. Mary, Brandenburg, Wall:E, Nabucco and so on. The matching categories would be: Category:King George (ship name) media Category:St. Mary (ship name) media Category:Brandenburg (ship name) media Category:Wall:E (ship name) media Category:Nabucco (ship name) media and they'd be categorized in Category:Ships by name. Notice that you must not put a category like Category:Wooden ships in this group, because wood [usually refers to] a material, not a name (however, if you have a ship named [the] Wooden, you may use Category:Wooden (ship name) media). Also note that usage of colons in cat titles is limited.

1. the things in each category have something in common that's identified in the name of those categories (they are ships)
2. the thing they have in common is plural in the category name ("media", not "medium")
3. they each have a different value for some attribute (name)
4. that value is also identified in each category name

Tomato types by shape, lets redefine 5-8 to not be tomatoes and hence redefine the term tomato. After all 5-8 look and taste quite different. If they had been tomatoes in the past, then trust me, I know that I'm right in that they are not tomatoes. I'm pretty sure 5-8 are not special cases of tomatoes even though some prior documentation says differently.

You may argue that the appendix media is implied for all categories containing files. And you're right. But, (applying to the original def for metacats), this shows that:

• the intrinsic properties of the criterion used are indifferent, i.e.
• how the criterion is to group media is not of interest, it only matters that it does so uniformly for each group
• if a criterion is to group media into groups, such that each group contains media of the same object (wrt to the metacat topic), then this might be (among the negation) a subset of metacats (nothing more, and nothing less)

I don't want to delve into speculation about whether you feel it's too late (or too workload intensive) to adjust (some) cases where cat markers are not used the way they are documented. Better late than never. The other way around, readjusting the definition of these markers every time their use has changed, is like changing the definition of a tomato each time someone finds one that looks unusually and hence does not term it (mark it) correctly, see the pic to the right. --Cmuelle8 (talk) 14:32, 28 October 2017 (UTC)

Prior documentation (on english wikipedia)

Analyzing the way english wikipedia organizes their cat tree, we can find the following parallels. I will refer to

• current snapshot of en:Wikipedia:Categorization#Category_tree_organization and
• current snapshot of en:Template:Category_header/doc

The former differentiates between topic and set categories,

Topic categories are named after a topic [..]
Set categories are named after a class (usually in the plural). [..]

It goes on to explain the process of subcategorization and diffusing large categories in the following subsections for both types joined. The latter subsection mentions metacategories,

Metacategories may be created as ways of organizing schemes of subcategories.

with a single example that happens to target set categories. Since both subsections talk about both types in a joined manner, it must be assumed that topic categories are organizable in just the same manner, using the same terminology (i.e. the example does not justify loss of generality).

---

However, english wikipedia does not heavily use the term metacategory to mark its categories (MetaCat is a redirect to Container category),

Tag categories with {{Container category}} to inform editors that they should not contain anything other than subcategories.

— en:Template:Container category

So at first glance it seems like metacats are not particularly discriminated against catcats in the sister project (which is a major difference to how commons treats these markers, regardless of the disputed fragments above). But there is to consider the documentation for the {{category header}} template. It has two parameters of interest for our issue,

container: Enter yes for categories containing only subcategories.
type: Enter the name of the category type (only 1):

• intermediate: For categories named "X by Y" that only contain subcategories. These categories are always container categories (see contents).
• set: For categories containing a set of group members.
• double: For set categories that also contain the members' corresponding categories.
• tracking: For set categories populated by a template.
• topic: For categories containing pages related to a particular topic.
• set-and-topic: For categories containing both a set and a topic.
• universal: For categories containing all pages in the subcategories of the related category tree.

The similarities are striking and this might be a good source to mindfully mine new name marker template names from or sort out the existing issues we've discussed for commons. The equivalence it suggests is:

commons terms	marker template on commons		english wikipedia terms
catcat			container cat
metacat		dispute: doc <> usage, marker is ambiguos to both cases, depending on which is seen authoritative	intermediate container cat
metacat grouping a set w/ media of objects sharing the same attribute (criterion is producing groups identifying multiple objects with a shared property)			intermediate container cat for set type cats
metacat grouping a topic w/ media of a individual object within each child cat (criterion is intended to produce groups identifying a single object each)			intermediate container cat for topic type cats

It must be highlighted that not all topics on english wikipedia deal with a specific object. So the relation suggested is in this regard similarity, not identity. So the relation between a topic and its article in english wikipedia might not translate 1:1 to the relation between a depicted object and its image (or media) file on commons in any case.

Also of interest is set-and-topic case which may mean that (if an equivalent on commons is found) the two subsets listed in the last two rows of the table are not strictly disjunct. You could either mark such cases to be in both subsets (marker templates would need to allow that), or add another row and end up with three disjunct subsets fully discriminating the metacat superset. Greetings. --Cmuelle8 (talk) 21:42, 28 October 2017 (UTC)

(Brücken)Kategorien

Hallo Cmuelle8,

du hast in letzter Zeit etliche Brücken-Bilder und Kategorien umkategorisiert und teilweise auch nur kopiert z.B. hier. Das finde ich prinzipiell auch gut, weil etliche Bilder hier nicht besonders gut einsortiert sind. Das Ergebnis Deiner Änderungen ist aber, dass viele Bilder redundant in der Unterkategorie und der (bzw. den) Oberkategorie(en) enthalten sind. Entsprechend dieser Seite sollten die Bilder aber nur in der Unterkategorie einsortiert sein.

Beim oben genannten Beispiel müsste das Bild also nur in der Kategorie:Syratalviadukt und nicht in der Kategorie:Stone arch bridges in Vogtlandkreis by name auftauchen, weil die Kategorie Syratalviadukt ihrerseits schon Bestandteil der anderen Kategorie ist. Kannst Du diese Änderungen bitte wieder korrigieren?

Das krasseste Beispiel in "meinem Bereich" ist allerdings die Category:Alte Elsterbrücke (Plauen), die nach Deiner Verschiebung so viele (teilweise doppelte, mehrere nicht vorhandene und etliche redundante) Kategorien enthält, dass ich da nicht mehr durchsehe und das leider auch nicht korrigieren kann. Vielleicht kannst Du das auch wieder glatt ziehen?

Viele Grüße N8eule78 (talk) 06:36, 10 October 2017 (UTC)

Hallo N8eule78, die Umsetzung des Kategoriebegriffs auf Commons dient dem Auffinden von Medien (und sekundär dem Beschreiben). Insofern ist es wichtig, dass Medien in mehreren Kategorien zu finden sind. Jede Mehrfacheinordnung im Kategorienamensraum (ob von Kategorien selbst, oder Dateiobjekten) ist redundant, denn der Kategoriebaum auf Commons hat nur eine einzige Wurzel.

Die Hilfeseite spricht sich nicht gegen Redundanz aus, sondern eher dafür, Zitat

Alle Kategorien [..] sollten in mindestens einer Oberkategorie enthalten sein.

Die Anstriche dort beziehen sich auch nicht auf die Einordnung von Dateiobjekten, sondern lediglich auf die Organisation der Kategoriestruktur, d.h. wie Kategorien in Kategorien einzuordnen sind. Die Hilfeseite schreibt zudem einleitend, Zitat

Die Kategoriestruktur ist (idealerweise) eine Multi-Hierarchie [..].

Das Begleitbild der Hilfeseite trägt nicht unbedingt zum Verständnis dieses Satzes bei, siehe deshalb de:Polyhierarchie; neben der zu empfehlenden Lektüre ist dort ein weniger suggestives Begleitbild angegeben.

---

Die von dir wahrgenommene Redundanz bezüglich des Kriteriums Ort ist subjektiv. Genau genommen meinst du, dass es ableitbar ist, dass ein Objekt in Plauen auch eines im Vogtlandkreis und wiederum eines in Sachsen ist. Diese Ableitung benötigt Zusatzinformation über die Lagebeziehungen der unter diesen Bezeichnungen verschlagworteten geographischen Regionen. Das steckt zunächst nicht in der Kategoriestruktur sondern implizit in (sächsischen) Köpfen, sofern es im Kategoriebaum mittels Metakategorien (by district, by city - nach Landkreis, nach Stadt) nicht auch wiedergegeben ist/wurde.

Eine Ortsangabe ist auch der Längen- und Breitengrad des Objekts. Ist die Zuordnung des Objekts zu Plauen redundant, wenn wir es einem Längen- und Breitengrad zugeordnet haben? Schließlich lässt sich doch dann ableiten, ob es in Plauen liegt (..)?

Aus der anderen Richtung gedacht suchen Nutzer von Commons mit dem Kategoriebaum nach bestimmten Bildobjekten. Ein Beispiel: Nimm an du bist Schwede und ein aus Sachsen zurückgekehrter Urlauber hat dir ein Bild einer Brücke in die Tasche gesteckt, aber nicht verraten, wo genau er war. Gesucht wird also ein ähnliches Bild, um Namen, Ort und ggf. weitere Infos des Bauwerks zu finden. Anlaufstelle ist dann Category:Bridges in Saxony und der Suchende wird es schätzen, wenn das Bild einer Brücke nicht ausschließlich in einer (womöglich einzigen und tiefen) Unterkategorie begraben liegt.

Du kannst auch ein Telefonbuch für Deutschland beispielhaft hernehmen - gleiches Prinzip. Gäbe es nur Telefonbücher pro Gemeinde und du suchst einen Max Mustermann, von dem du nur weißt, dass er in D lebt, dann hast du sehr viel zu tun.. Das Telefonbuch für D ist eben nicht strikt redundant (nicht in dem Sinne, dass es die anderen ersetzen könnte und umgekehrt), aber es ist ableitbar. Manchmal findest du auf Commons Kategorien mit dem Appendix (flat list) - das sind Ableitungen sonst tieferer Bäume, die in etwa diesem Telefonbuchbeispiel entsprechen. Auch der Schwede aus dem Beispiel profitiert von einer flat list (der Dateiobjekte).

Ein flat list-Index gemeinsam mit den ggf. vorhandenen, untergeordneten Kategorien bildet imho den klassischen Kategoriebegriff ganz gut ab. Ob die Datenstruktur das explizit wiederspiegelt oder durch ad-hoc-Rechnung bei Betrachtung "ergänzt" ist eher unwichtig, wichtig ist aber imho das nicht vergessen wird, dass sie Repräsentant des Kategoriebegriffs bleibt. Ein Versuch sich den oder die Kategoriebegriffe mit dem Abbild zu erschließen kann gut gehen, muss aber nicht.

---

Das Limit auf Commons ist eigentlich nur die Wartbarkeit von Einträgen. Die ist m.M.n. durch die Kategorie-Helferlein gegeben. Sollte eine Zuordnung eines Objekts zu einer bestimmten Kategorie tatsächlich falsch sein, dann rechtfertigt dies Korrekturen. Mehrfacheinordnungen sind aber selten "Überkategorisierungen", sondern einfach nur verschiedene Wege, ein Objekt einer Menge zuzuordnen, die nach bestimmten Kriterien gebildet wird und Teil einer Polyhierarchie ist.

Eigentlich machte es Sinn, wenn die Software tiefe Hierarchien selbst flach klopfte und die gefunden Blätter (Dateiobjekte) als flat list in der Oberkategorie anbietet. Dann müsste das am Dateiobjekt nicht manuell gepflegt werden (siehe Telefonbuchbeispiel). Dagegen spricht allerdings, dass solch ein Automatismus fehleranfällig gegen unabsichtlich oder mutwillig falsch eingehangene Unterkategorien wäre. Deshalb verlässt man sich auf eine explizite, manuelle Einordnung.

Die der natürlichen Sprache entlehnten Kategoriebegriffe werden aber leider ohne diesen Automatismus eher schlecht angenähert. Man ist dann versucht anzunehmen, dass ein Bild einer Brücke in Plauen ohne diesen Ortsbezug kein Bild einer Brücke ist. --Cmuelle8 (talk) 18:53, 10 October 2017 (UTC)

Hallo nochmal,

offensichtlich ist die Annahme, dass es gewünscht sei, die Dateien in alle Oberkategorien zusätzlich mit einzusortieren nicht richtig. Denn auf der Hilfeseite zu Kategorien steht im Abschnitt Kategorisieren deiner Beiträge: "Allgemein sollte eine Datei nur in der spezifischsten Kategorie eingeordnet sein, die zu einem bestimmten Thema existiert. Zum Beispiel sollten Dateien in Category:Paris nicht zusätzlich in Category:France eingeordnet sein." Übersetzt hieße das Besispiel ja: Es sollten Dateien aus der Kategorie Brücke in Plauen nicht zusätzlich in der Kategorie Brücke in Deutschland eingetragen werden. Da hier von der "spezifischsten" Kategorie die Rede ist, schließt das neben der Kategorie "...in Deutschland" auch "...in Sachsen" und "...im Vogtlandkreis" mit eine, solange "...in Plauen" Teil dieser Kategorien ist. Im rechts stehenden (von Dir angesprochenen) Bild ist ja z.B. "a" auch nicht nochmal in "d" einsortiert.

Die von Dir angeführte Polyhierarchie ist davon nicht betroffen. Dass eine "Brücke in Plauen" z.B. auch eine "Steinbogenbrücke" sein kann ist ja klar.

Deshalb möchte ich Dich nochmals bitten, die entsprechenden Korrekturen selbst vorzunehmen.

Viele Grüße N8eule78 (talk) 08:28, 11 October 2017 (UTC)

Das soll kein afront sein, aber du hast deine Argumentation nicht zu Ende gedacht und meine nicht verstanden. Das eine "Brücke in Plauen" auch eine "Steinbogenbrücke" sein kann, das ist dir klar. Aber das eine "Brücke in Plauen" auch eine "Brücke im Vogtlandkreis", "Brücke in Sachsen", "Brücke in Deutschland", "Brücke an der Weißen Elster", "Brücke südlich von Leipzig", "Brücke bei Breitengrad 50.49302 und Längengrad 12.14127", "Brücke nahe der Reichenbacher Straße" bzw. "Brücke mit Abbildung auf Messtischblatt 5538" usw. sein kann, das ist dir nicht klar?

Was spezifischste Kategorie ist, hängt von der Wahl des Themas ab:

Polyhierarchie bedeutet, dass (z.B.) der Knoten "Brücke in Plauen" nicht ausschließlich (nicht zwangsläufig) in einem einzigen Unterbaum enthalten ist. Vgl. den Knoten g bzw. g' im Bild rechts oben und Zitat

Ein Multibaum [..] ist ein [..] Graph, in dem sich als Substrukturen mehrere Bäume identifizieren lassen.

Bestimmtes Thema heißt, dass du in der Polyhierarchie eine Baumsubstruktur (BSS ff.) ausgewählt hast. In dieser könntest du dann auch eine spezifischste Kategorie bestimmen, die aber strikt nicht die spezifischste Kategorie sein muss, wenn eine andere Baumsubstruktur gewählt wurde.

Schon beim Thema Verwaltungsstrukturen gibt es mehrere wählbare BSS, u.a. administrative ~, forstwirtschaftliche ~, kirchliche ~. Der Knoten Plauen kann bsp.-weise an all diesen teilnehmen, nicht lediglich an ersterer und nicht unbedingt in gleicher Tiefe.

Plauen kann auch in BSS zu den Themen Städte nach Einwohnerzahl, Städte nach Gründungsdatum oder Städte nach Anzahl der Brücken teilnehmen; alles BSS, die gänzlich ohne die vorgenannten BSS auskommen, aber in der Multihierachrchie neben diesen koexistieren.

BSS welche Objektlänge, -breite, -gewicht, oder -farbe usw. thematisieren, können mit dem Thema Verwaltungsstrukturen kombiniert werden oder eben nicht. Ein Beispiel dafür findest du in Category:Bridges by length. Hier sind bestimmte Längen, oder Längenbereiche spezifischste Kategorie.

→ Wenn sich dort im Laufe der Zeit eine Kombination mit z.B. administrativen Verwaltungsstrukturen hinzugesellt, dann ist das i.A. keine Aufforderung, BSS abzubauen, die ausschließlich die Objektlänge thematisieren.

Falls das Thema Brücken in den Bundesländern ist, dann ist bsp.-weise Brücken in Sachsen auch die spezifischste Kategorie. Man kann eben die Begriffe Deutschland, Sachsen, Vogtlandkreis und Plauen nicht ausschließlich auf ihre Verwaltungszugehörigkeit reduzieren. Das ist ein Aspekt, der eine hierarchische Zuordnung erlaubt, aber nicht der Einzige.

Ein Stadtbezirk, ein Ortsteil, ein Straßenname und eine geographische Position (lon/lat) z.B. sind weitere ortsbezogene Angaben, die nach ihrer Verwaltungszugehörigkeit in eine (unter vielen) Hierarchie gebracht werden können. Nach deinem Verfahren wird der Kategoriebaum zum Auffinden von Objekten nutzlos, wenn im Endausbau alle Objekte einzig und zu-unterst an ihrer geographischen Position < dem Straßennamen < dem Ortsteil < dem Stadtbezirk < der Stadt < dem Landkreis < dem Regierungsbezirk < dem Land < dem Staat < dem Kontinent verortet sind. Das hat mit einer Polyhierarchie dann auch nichts mehr zu tun. Es ist dann eine Mono-Hierarchie, die administrativ verwaltungsaffine Nutzer bevorzugt und alle anderen außen vor lässt.

Die Forderung, Objekte in Paris nicht Objekten in Frankreich zuzuordnen ist im Übrigen auch völlig undifferenziert. Natürlich gehören z.B. Symbole (Bauten, Plaketen, Werke..) von gesamtfranzösischer Bedeutung in die "Ober"kategorie (die wie gesagt nur nach Maßgabe der Verwaltungszugehörikeit überhaupt eine solche ist).

Eine Polyhierarchie legt sich nicht auf ein Thema fest, sondern verhält sich in der Frage des Bezugs (im Idealfall!) weitgehend neutral. --Cmuelle8 (talk) 19:50, 11 October 2017 (UTC)

Hallo nochmal,

ich befürchte wir reden aneinander vorbei aber ich versuche es nochmal: Entsprechend der oben verlinkten Hilfeseite und den mir bisher hier als Konsens erschienenen Regeln, ist (um bei dem Beispiel zu bleiben) das Bild der Friedensbrücke (nach Brückengesichtspunkten) ausschließlich in die Category:Syratalviadukt einzuordnen. Da die Category:Syratalviadukt schon Bestandteil der Category:Bridges in Plauen ist (bzw. bis zu Deiner Bearbeitung war). Die Category:Bridges in Plauen ist wiederum Bestandteil der Category:Bridges in Vogtlandkreis (gewesen), diese wiederum ist Bestandteil der Category:Bridges in Saxony, die dann wieder Bestandteil der Category:Bridges in Germany usw.

Das heißt, durch die Einordnung in die Kategorie "Syratalviadukt" ist dis Bild automatisch auch Bestandteil der Kategorien "...im Vogtlandkreis", "...in Sachsen", "...in Deutschland" usw. Eine zusätzliche Einordnung in diese Oberkategorien ist nicht erforderlich und nicht gewünscht.

Dass die Kategorie "Syratalviadukt" außerdem Teil der Kategorien "...nach Länge", "...nach Bautyp", "...nach Alter" etc. sein kann (und sollte) ist davon völlig unabhängig. Ich gehe auch noch mit, dass die Bilder/Kategorien (sofern anwendbar) "...nach administrativer Verwaltungsstruktur", "...nach forstwirtschaftlicher Verwaltungsstruktur" und nach "...nach kirchlicher Verwaltungsstruktur" eingeordnet werden. Aber auch in jedem dieser Äste soll die Kategorie (und damit das Bild) in die jeweils spezifischste Kategorie eingeordnet werden. Sonst sind sämtliche Oberkategorien irgendwann heillos überfüllt und dann findet auch niemand mehr was.

Ebenso nicht davon betroffen ist die Tatsache, dass das Bild selbst noch z.B. in Kategorien "...nach Aufnahmedatum", "...nach Farbe" oder nach sonstigen Gesichtspunkten einsortiert werden könnte.

Deshalb nochmal meine Bitte: Bitte entferne die redundanten (Ober)Kategorien wieder.

Viele Grüße N8eule78 (talk) 08:19, 12 October 2017 (UTC)

Mache dir bitte die Mühe meine Argumentation oben ordentlich zu lesen und zu durchdenken. Niemand hat deinen Anwendungsfall beschädigt oder entfernt. Wer das Bild in Category:Syratalviadukt sucht, wird es weiterhin dort finden; unterhalb des Astes (und der Baumsubstruktur), die du als richtig und wichtig ansiehst. Falls dir die restliche Einordnung nicht einleuchtet, dann ist das hauptsächlich dein Problem - falsch ist sie jedenfalls nicht und sie widerspricht vor allem nicht den Forderungen für die Kategoriestruktur. Sie ist auch nicht abschließend (i.S. von komplett), aber das habe ich auch nicht behauptet. Dir wird z.B. auffallen, dass ich aus Gründen der Wartbarkeit der Kategorieangaben z.B. nur einige deutschlandweite Kategorien angegeben und auf Thema-Brücken-Ebene wenige bis gar keine genutzt habe (obwohl das angebracht wäre, um den verwendeten Kategoriebegriffen tatsächlich gerecht zu werden).

Polydimensionalität bei der Kategorisierung bedeutet, dass man auch Sichtweisen zulassen muss, die man nicht mag, sofern sie nicht falsch sind. Das hier ist keine Spielwiese für uns beide, sondern ein System das alle und damit auch möglichst viele Anwendungsfälle ansprechen soll.

Was bitteschön meint heillos überfüllt? Der Technik ist es gleich (völlig egal), ob du 42 Millionen Bilder als flache Liste, in eine Baumstruktur, oder eben in eine polyhierarchische Ordnung bringst. Was stört es dich z.B. wenn in der obersten aller Kategorien, CommonsRoot alle Medien am Band navigierbar sind? Es berührte deinen Anwendungsfall überhaupt nicht! Er wird dadurch nicht beschnitten, nicht gestört, nicht geändert. (Das gleiche gilt für Substrukturen an anderer Stelle.)

Wenn du in deine Lieblingsbibliothek gehst und dort nach einem Buch suchst, dessen Autor in Sachsen gelebt hat, dann wird man dir nicht 422 verschiedene Listen in die Hand drücken. Das wird man nur tun, wenn dort jemand wie du seine Ansicht durchsetzen konnte (kleiner Seitenhieb).

Falls du ein Bild einer Brücke suchst, deren Namen du nicht kennst, dann ist es im Übrigen völlig hinderlich, dass die Brückenbilder hier regelmäßig, vorrangig (und ohne Not) zunächst nach Namen kategorisiert werden. Das ist eine Unsitte, die ich für meine Kat.-vorgänge sogar teilweise übernommen habe, leider und einzig aus dem Grund, dass ihr viele Vorschreiber ebenfalls verfallen sind.

Die Kategorisierung von Objekten nach (Eigen-)Namen ist ein wichtiger Anwendungsfall unter vielen, dem das Kategoriensystem gerecht wird. Wie du am Beispiel der Alten Elsterbrücke in Plauen sehen kannst, die sehr häufig umbenannt wurde, kann eine Einordnung der Bildobjekte nach anderen Kriterien (ohne Beachtung des Namens) sogar wesentlich robuster sein. Außerdem kann man so u.U. viel schneller Kategorie-Dopplungen erkennen.

Ich möchte dich nun bitten, davon Abstand zu nehmen, einfach das zu wiederholen, was du mir schon etwa 3x mal geschrieben hast. Es ist unnötig, ich habe dein Anliegen verstanden, ja stimmte ihm unter anderen Bedingungen sogar zu, die hier aber nicht anzutreffen sind. --Cmuelle8 (talk) 22:41, 12 October 2017 (UTC)

Ausschnitt Kategoriegraph

Vielleicht hilft ein schematisches Bild um zu sehen, dass die lila eingefärbte Baumsubstruktur ein eigenständiges Thema ist. Das ganze ist ein Ausschnitt, weswegen auch Platz für die gestrichelt dargestellte Einordnung in Bridges by name war, die wie gesagt aus Gründen der Wartbarkeit vermieden wurde, aber prinzipiell nicht unrichtig ist (vgl. Bsp.), und die sich evtl. auch durch ad-hoc-Rechnung erzeugen ließe, was aber entgegen deinen Annahmen weiter oben nicht automatisch passiert. Es gibt externe Tools (Help:FastCCI) mit denen sich begrenzt Schnitt bzw. Vereinigungsmengen bilden lassen, ohne dass diese explizit so kategorisiert wurden, das arbeitet aber nicht transparent mit dem Kategoriebaum zusammen: du kannst ein Ergebnis dieses Tools nicht einfach in den Kategoriebaum einhängen. Denkbar wäre auch, einen Baum mit Abfragen auf wikidata zu erzeugen, was aber nach meiner Wahrnehmung derzeit nicht spruchreif ist ( teilt diese Einschätzung; ggf. hätte dies ohnehin dieselben Probleme, die hier entstünden, wenn man editierbare Abfragen für den Inhalt von Kategorien zuließe). Gruß --Cmuelle8 (talk) 01:50, 13 October 2017 (UTC)

Hallo nochmal,

wie schon oben befürchtet, reden wir offensichtlich aneinander vorbei, denn mein Anliegen hast Du (entgegen der oben genannten Behauptung) wohl nicht verstanden. Deshalb werde ich die Diskussion hier auch aufgeben (da keine Aussicht auf Konsens).

Einen Hinweis/Antwort aber noch: Du fragst oben: "Was bitteschön meint heillos überfüllt?" Das will ich Dir gern noch beantworten bevor ich hier verschwinde. ;-) Mit "heillos überfüllt" meine ich, dass eine Kategorie mehrere hundert (oder gar mehrere tausend) Bilder enthält und dann kein Mensch mehr was wiederfindet (außer durch Zufall oder durch genaue Kenntnis des Dateinamens). Dem von Dir oben angeführten Benutzer, der eine Brücke sucht (um beim Beispiel zu bleiben) ist damit also auch nicht geholfen, weil er sich durch zig Seiten klicken muss - das ist dann auch nicht besser als sich durch zwei, drei (Unter)Kategorien zu klicken. Das die Technik damit kein Problem hat (sie höchstens langsamer wird) ist davon unberührt.

Eine Bitte habe ich aber doch noch: Kannst Du bitte die zig "roten Kategorien", die durch Deine Änderungen entstanden sind, noch anlegen? Also vielleicht kannst Du ja die einzelnen Äste, die Dir offensichtlich so wichtig sind, immer gleich komplett anlegen, bevor Du die nächsten Kategorien kreierst. Dann könnte man am Ende vielleicht auch besser den Sinn der Unter-Unter-Unter-Kategorien nachvollziehen, wenn die nicht dauernd "ins Leere" laufen.

Vielen Dank und Viele Grüße N8eule78 (talk) 09:36, 17 October 2017 (UTC)

Meiner Wahrnehmung nach liegen wir gar nicht soo weit voneinander entfernt. Der einzige Unterschied besteht darin, dass du den Sinn der (zusätzlichen) Schubladen, neben deiner Schublade (die ich ebenfalls als wichtig ansehe), nicht erkennst. Das liegt mutmaßlich daran, dass du die zusätzlichen Anwendungsfälle (siehe Grafik rechts) für dich genommen noch nie gehabt hast. Aber wie gesagt, nur weil sie sich dir nicht erschließen, heißt das nicht, dass es sie nicht gibt oder dass sie weniger wichtig sind.

Nochmal zu heillos überfüllt: Das ist im Bezug auf eine Kategorie eine subjektive Aussage. Es gibt halt sehr viele Brücken in Sachsen und im Rest der Welt, das ist schlicht ein unumstößlicher Fakt. Wenn du die Kategorien Brücke in Sachsen oder Brücke, die sich daraus ableiten, als heillos überfüllt empfindest, dann ist das deine Sache. Diese Kategorien ändern sich nicht, wenn neue Kategorien gebildet werden, um diese Mengen, bestimmten Kriterien nach, zu unterteilen. Sie sind selbstständig und von jeglichen "Unter"kategorien unabhängig. (Ich rede vom Kategoriebegriff an sich und nicht von seiner Umsetzung auf Commons; das sind (leider) zwei verschiedene Paar Schuhe.)

Wenn du genau weißt, wonach du suchst, dann erscheinen für dich umfangreiche, große, nicht weiter unterteilte Mengen sinnlos. Du steuerst dann direkt in eine Kategorie die nur eine kleine Menge von Objekten umreißt (z.B. Brücke in Plauen). Wenn du z.B. deine eigenen Bilder kategorisierst, dann ist das i.d.R. der Fall (du weißt wo das Objekt auf dem Foto genau liegt).

Wer auf Commons etwas sucht hat diese Informationen nicht. Für den können dann auch die nicht unterteilten Mengen, die dir sinnlos erscheinen, sinnvoll sein. Alle Bilder von Brücken in Sachsen in einer Kategorie am Band navigieren zu können ist sehr wohl besser als, Zitat sich durch zwei, drei (Unter)Kategorien zu klicken, wenn der Suchende eine Unterkategorie nicht weiter spezifizieren kann. Außerdem bleibt es bei der von dir genannten Tiefe (zwei, drei) nicht, denn jedes Mal wenn jemand ein weiteres Spezifikum ganz unten anhängt (Bezirk, Ortsteil, Straßenname, etc.) , potenzieren sich die zu durchsuchenden Kategorien. Gruß --Cmuelle8 (talk) 08:35, 20 October 2017 (UTC)

Ergänzend zum Thema lohnt ein Blick in

• Category:Municipalities_in_Saxony

• vgl. mit Wdh. der Verweise auf Gemeindekats in den Landkreiskategorien Sachsens
• vgl. mit nicht-wiederholender Category:Municipalities_in_Germany (dort wird nur Indirektion verwendet)

• en:Category:Wikipedia_non-diffusing_subcategories

• explizite Sammlung von Kategorien, für die eine Durchreichung auf spezifischste "Unter"kats unerwünscht ist)

--Cmuelle8 (talk) 14:44, 29 October 2017 (UTC)