Open main menu

Wikimedia Commons β

User talk:Auntof6


Welcome to Wikimedia Commons, Auntof6!

Rd232 (talk) 14:29, 26 November 2011 (UTC)

overcategorizationEdit

Unless for technical limitations there is no such thing. Either a statement about an object is true or not. Its impratical (impossible) to gather (capture) all true statements about an object, so naturally we deal with a subset of them on commons. The purpose is to organize (and at the same time describe) media available. There is plenty of subjects to deal with and work on, so you may find your own. I welcome review of my work when done with some timely distance to the edits made. Jamming edits while things are in flux grabs my attention, yes, but not in a helpful way.

When dealing with a multi-dimensional (by a, by b, by c, -criteria e.g. makes three dimensions) categorization tree, leaves need to have more than one parent. E.g. if a green road bridge called grerobri is the only bridge that exists, a single category will suffice. To tell more bridges apart, one level of indirection might do (but more are not wrong):

  • bridges by color: green bridges{ .. }
  • bridges by function: road bridges{ .. }
  • bridges by name: grerobri

The sets in subcats to by color and by function partition the set given in by name.

For a second (and on..) level of indirection, to deal with even more bridges (as is done on commons..) it continues like this:

  • bridges by color: green bridges{ green bridges by name: grerobri, green bridges by function: green road bridges{ .. } }, red bridges{ .. }, ..
  • bridges by function: road bridges{ road bridges by name: grerobri, road bridges by color: green road bridges{ .. } }, tube bridges{ .. }, ..
  • bridges by name: grerobri

The partitioned sets get smaller with every (added) level of indirection: This is the one and only desired effect for the purpose of organizing large sets. For the describing aspect however, indirection may (in extreme cases) even continue if the size of the set has reached a single instance. This does not contradict or falsify the traditional concept of categories, see en:Categorization.

Inexperienced people on commons often claim that a category should not (let alone cannot) appear twice or more below its main category, neglecting the fact that most categories indeed have more than one main category: grerobri being a bridge is one point of view (one main cat), but another main cat is "colored objects" (there is no need to identify grerobri as a bridge to correctly categorize it to "green objects"). "Named things" can also serve as a main category, because grerobri may be assigned to completely different objects as well.

"Named things" for example, is silently assumed on commons for most categories that directly include instance names, albeit without the usage of a by name metacat. In the example with two indirections above

  • green bridges by name
  • road bridges by name
  • bridges by name

metacats are used. If we did not focus on bridges for a moment, we can easily see that a main cat for the first may also be named colored objects, for the second named infrastructure objects, which in general ripples up to named things and not things being a bridge.

If by name metacat is wiped, it is harder to see that instance naming is simply one aspect (one dimension) of statements about an entity:

  • bridges by color: green bridges{ grerobri, .. }, red bridges{ .. }, ..
  • bridges by function: road bridges{ grerobri, .. }, tube bridges{ .. }, ..
  • grerobri

.. and if some more metacat keys are wiped:

  • green bridges{ grerobri, .. }
  • red bridges{ .. }, ..
  • road bridges{ grerobri, .. }
  • tube bridges{ .. }, ..
  • grerobri

OK, let's remove grerobri from the "main cat". Now its clear that grerobri is not a bridge name in its own right, correct? It's only so for green bridges or road bridges. What if I am colorblind and have never seen a car drive across grerobri? .. In this case I will neither navigate to green bridges nor road bridges (among tons of other cats). However, I've heard that the bridge is called grerobri. So what I'm looking for is a by name category (which is strictly assumed the top-level main cat if it does not exist).

This example transfers imho to a lot of other cases where an entity is not found at the expected metacat or combinations thereof. A road bridge is also a bridge in its own right; whether people know its being used as such or not does not really matter. --Cmuelle8 (talk) 00:37, 8 October 2017 (UTC)

Beechcraft aircraft by facingEdit

Thanks for your alertness to retain the Template:MetaCat for this cat. Just so you know, on categories using Template:Mfr aircraft by facing, just simply use parameter 2 as 'meta' and it will include it automatically, so no need for a separate MetaCat inclusion. Josh (talk) 16:51, 27 October 2017 (UTC)

@Joshbaumgartner: Sounds good. Two questions:
--Auntof6 (talk) 19:24, 27 October 2017 (UTC)
I've been doing a lot of tweaking on the template in question, and it seems one of my errors escaped. It's been since fixed. The category should show up cleanly now for you. Josh (talk) 19:32, 27 October 2017 (UTC)

@Joshbaumgartner: Category:Aermacchi aircraft facing right is showing up as a metacat, but it's not one. Could you take a look and see what's wrong? --Auntof6 (talk) 05:18, 28 October 2017 (UTC)

The template was working correctly, but on the category, needed to say 'face=r' instead of 'face=m'. Fixed. Josh (talk) 05:31, 28 October 2017 (UTC)

Category:Images by User:Christian FerrerEdit

It is a user category, mine, it groups photographs taken by me therefore it has his place inside Category:Photographs by Wikimedia Commons users, maybe the name is not the best however it is a user category and I chose the name I want. Please stop doing that, I'm not going to play this game a long time therefore it is the first and last warning. Christian Ferrer (talk) 17:20, 6 November 2017 (UTC)

Category:Old maps of county towns in EnglandEdit

I was surprised by this diff.

My intention with the {{CatCat}} template was that if a map image comes in of a county town which does not already have a category listed here, then a new category should be created for that town and the image put in it. The number of county towns is limited. Almost all already now have categories; so the number of further categories that will be needed (if any) is likely to be very limited.

In my view there should be no images left in this category itself. My understanding was that the template {{CatCat}} signals this. I'm therefore not clear why you removed it. Jheald (talk) 16:11, 15 November 2017 (UTC)

@Jheald: I removed it because the category is not named in a way that prohibits individual files. Cases like this are usually handled in one of the following ways:
  • Instead if {{catcat}}, use {{categorise}}.
  • Rename the category to something like "Old maps of England by county town" or "Old maps of county towns in England by name". Either of those would use {{metacat}} but with different parameters.
By the way, I requested deletion of the two categories that are empty. It's not the practice to keep empty categories, even when they're part if a set like this. --Auntof6 (talk) 16:46, 15 November 2017 (UTC)
I am prepping an upload of 5000 maps and plans of England at all scales - see Work in progress page, and project development page. I would appreciate it if target categories were not deleted. Jheald (talk) 17:14, 15 November 2017 (UTC)
Then maybe you could either put one or two files in the empty categories so that they're not empty, or put a note on the categories saying when you expect them to be populated. --Auntof6 (talk) 17:18, 15 November 2017 (UTC)

Changed cat keys under Trams by settingEdit

Before these edits of yours, these four subcats were neatly listed under the same heading (🛤) at Category:Trams by setting:

This was done to keep these four subcats, which share a common topic, together for better use; the creation of an intermediate category, something like Category:Trams by setting concerning the type of track, was deemed needlessly cumbersome.

Now, after your change of the sorting keys, these four are scattered all over the place, interspersed among not specifically related subcats — helping nobody’s dissimination or browsing needs, accomplishing nothing but irrelevant alphasorting.

-- Tuválkin 00:50, 16 November 2017 (UTC)

I don't think we should be using images as sort keys. I don't see a problem with a subcat for these, but another option is another sort key such as an asterisk. --Auntof6 (talk) 01:37, 16 November 2017 (UTC)
  • Thanks for your prompt reply. Two points:
  • This "🛤" is as much as a character as this "*". If it is rendering in your browser as an image (as it is in mine, too) and you find it annoying (like I do), then fix your browser (as I’m trying to fix mine — I’ll let you know how it went). The difference is that "🛤" means "track" in its semantics (and not just in its glyph, like "#" or "⨳"), while an asterisk means a lot of stuff but none of it is "track". That’s why I chose it.
  • There is an advantage in an intermediate category, though, as it can be categorized as a sibling of similar cats for other types of rail vehicles.
-- Tuválkin 03:54, 16 November 2017 (UTC)
Return to the user page of "Auntof6".