Commons talk:Tag categories

From Wikimedia Commons, the free media repository
Jump to: navigation, search

I like the solution, however I fear that many readers won't understand how this approach and only this approach can solve certain problems with adding semantics to content. Can you elaborate in brief (maybe with one or two examples how easy these semantic informatin will be accessible with your solution compared to the current system) a litte bit more on some limitations of the current existing system and how your approach can solve these things and is thus superior to what exists now (roughly explaining how you can obtain semantic information via the database queries with you scheme)? That way people directly see the direct benefit and what this is all about. Arnomane 21:30, 11 April 2006 (UTC)

I have tried to clarify a bit more in the rationale section. -- Duesentrieb(?!) 09:26, 22 April 2006 (UTC)

On Category:License tags it says, All license tags must be contained directly in this category (not in subcategories). Why? Wouldn't it make sense that Category:License tags attribution is a subcategory of Category:License tags? pfctdayelise (translate?) 03:38, 22 April 2006 (UTC)

Because a prime purpose of this is to have an easy way to get all license tags with a single database query. Collecting the contents of subcategories takes longer, is more complicated, and can not be made part of bigger queries directly. Generally speaking, the reason is that relational databases are not good at handling recursive structures. So, all license tags must be in Category:License tags directly.
I havn't decided yet if Category:License tags attribution should be contained in Category:License tags. For querying tags it does not make a difference, and conceptually it seems to make sense. On the other hand, it may mislead people to remove tags from the main category if they are in a more spüecific category, as is customary and sensible in other contexts. -- Duesentrieb(?!) 09:26, 22 April 2006 (UTC)
Yes indeed. Rather counter-intuitive. So you're saying CC-BY-SA should actually be in three categories, not just Attribution and Share-alike? pfctdayelise (translate?) 11:21, 23 April 2006 (UTC)
Yes, exactly. That way it's easier to handle in the database. If it complicates things to much for the users, it could be changed, but it would make it much slower to use the tag categories for queries. -- Duesentrieb(?!) 12:18, 23 April 2006 (UTC)
Since basically only admins will be doing this, presumably, I think it's fine as long as it's just made very clear. pfctdayelise (translate?) 12:42, 23 April 2006 (UTC)

Translated tags[edit]

Should they be categorised? My guess is not. Most of them are not, but some just copy everything in the English tag including the category. pfctdayelise (translate?) 14:39, 29 May 2006 (UTC)

No, they should not. they should not be used as templates, and they should not be categorized as such. -- Duesentrieb(?!) 00:34, 8 July 2006 (UTC)

categorization helper templates[edit]

Josh Baumgartner added some categorization helper tags for the Commons:Category Ships scheme. Apparently these are used on English wiki. They enforce the standard categorization for ships eg:

{{Cathead battleships of | Germany}} 

generates

  • category:Battleships
  • category:Naval ships of Germany|Battleships
  • category:Battleships by country|Germany

There are about 8 different variants. Do you want these categorized under helper templates, or not categorized at all or under a new grouping- like Categorization helper templates?

-Mak 23:04, 25 June 2006 (UTC)

Please do not add three very similar redundant categories to images. For example please never place an image in a category (category:Battleships) and its sub category (category:Battleships by country) at the same time. Arnomane 10:26, 26 June 2006 (UTC)
Comment noted but off topic. If you don't like what the templates do, talk to Josh, or make a contribution to Commons Scheme on ship categorizations. You may note in the discussion there that I observed that the scheme has a weakness in this respect. You also may be interested to know that this sort of template is in wide use on wikipedia. en:Template:Cathead wwi battleships of Perhaps they need your input there as well. Possibly they are not aware of proper category construction theory. -Mak 23:51, 7 July 2006 (UTC)

I would categorize them as helper templates, and I don't really see their point. I have no strong feelings about using them in gerneral, but in this case, i agree with arnomane that they images shoudl not go into category:Battleships if they alread go into two subcategories. Also, misusing the category sort key to create something like subsections seems like a very bad idea. -- Duesentrieb(?!) 00:38, 8 July 2006 (UTC)

To clarify: there should be one category, Category:Battleships of Germany, for all such images. That category would be in Naval ships of Germany and Battleships by country. No need for a template. A scheme that introduces redundancy instead of limiting it is misguided. -- Duesentrieb(?!) 00:40, 8 July 2006 (UTC)


There are two parts here, one of which I am totally in agreement with you and arnomane on. The plain Battleships category is sometimes thought of as if it is Battleships by Name. It would not be redundant if the template did that. However, it seems a little silly for countries that have only one battleship with pictures to force them to have a Battleships by name category. Anyway- my remark I believe in the ships scheme was that the redundancy problem would resolve itself when the categories became more populated. But really- that is a practical issue for discussion in the ship talk category scheme, not here. I saw both points of view and raised it as a question about what folks wanted to do. I am perfectly happy doing it the Ships by country way only for the time being.

The other part of what you are saying is at issue with what EN: wiki is doing with their Cathead templates, is that not correct? But on this point I see two ideas- that you have no strong feelings about their use, but also that "misusing the category sort key to create something like subsections seems like a very bad idea", Because that is precisely what the Cathead templates are doing. And they are slicing it up by time too, with some really immense names.

It basically is because they have to statically encode what you can do with a dynamic and query. The application they have is navigation. You can quickly jump to another related category because you can vary one of the query terms by varying the cat name. EG: easily jump from Spanish/American War-Cruisers-of the US-build in the 1870s to other cruisers of the same set built in the 1880s, or other cruisers of the same set fielded by the Spanish.

It would be much better if they could have dynamic queries, but due to server loading that is not going to happen anytime soon, so they are implementing their functionality this way. Long term it is no problem because it can be erased when dynamic queries are cheap enough for the foundation to offer. In the meantime they get their navigation by statically encoding.


-I can see their point of view. It is grungy and really makes an extremely detailed category tree. If we think the predominant way people use the cat tree is walking up and down its branches by key clicks or a sidebar navigator, it is definatly not the way to go. -Mak 22:32, 8 July 2006 (UTC)

Navigation helpers, bots and new Wikitext commands[edit]

Well ok. Over a week and no response on the above issue regarding use of categories for a plethora of set intersections useful for navigation purposes. My thought is to avoid such category clutter and to compose static lists formed by doing ands on category lists fetched. But is is an elitist and fragile way of doing it- It could only be implemented and maintained with a bot. A method for civilians would need something like a wiki command like [[{{NEXT_IN_CATEGORY:Battleships&1930s ships}}]]. Do an anded SQL query, sort- find your pagename in the list, return the next in list; alternately return PREV with wraparound. -Mak 21:37, 17 July 2006 (UTC)