Rosetta Code:Village Pump/Over-categorization

From Rosetta Code
This is a particular discussion thread among many which consider Rosetta Code.


Discussion on the new task categories that have been sprouting up lately


I am not very happy with a lot of the new task categories that have been created lately. Lots of them seem to be too specific. Some of them don't seem necessary. I think we need to stop blindly and unilaterally categorizing tasks and plan some of them out instead. We need to talk about how to organize these tasks in a way that best benefits the users. Some examples include (and I don't mean to pick on Markhobley, but I know he has created a lot so I looked through his for examples):

Too specific:


We need to come up with the way we want to do this. We can use semantic mediawiki to tag tasks (which was a goal for that system here). If we do that we need to figure out how exactly that can happen. We can keep using categories. If we do that I think we need to decide if we want a tree, how deep it goes, how we want it organized, or, if we don't want a tree, what flat categories we want to use. --Mwn3d 02:51, 31 May 2011 (UTC)

I agree with at least some of these. In particular, a category shouldn't be created unless there's multiple existing full tasks that can be categorized with it, and it should be distinct from all the existing categories too. –Donal Fellows 10:55, 31 May 2011 (UTC)

Here's another one. –Donal Fellows 13:25, 31 May 2011 (UTC)

I'd hold off on clearing some of those categories quite yet; it looks like Mark is moving content from his site to RC, and I'd wager there's already an organizational structure in place. If the concern here is about duplicate categories, I seriously recommend taking a look at SMW's semantic properties. You can have a property be a subproperty of another, such that Loop Modifiers might appear as a more specific aspect of loops. This is exactly the kind of problem SMW is designed to be good at. --Michael Mol 16:37, 31 May 2011 (UTC)
How do we set up these sub-properties? I think it would be easiest to have a "tag" template that just adds [[tag::argument]] to a page. We can have multiple tag templates used on the page since they stack (see the "implemented in language" property). The structure of those tags can probably be exactly the same as any category structure we come up with. What do we think that should look like? What categories/tags do we start with? --Mwn3d 16:59, 31 May 2011 (UTC)
If I understand it right, each property has its own page (in the Property namespace), and you can assign properties to those pages as well. See smw:Help:Properties and types --Michael Mol 18:55, 31 May 2011 (UTC)
What do we do with that? Make like a "One level up" property? --Mwn3d 19:12, 31 May 2011 (UTC)
It looks like smw:Property:Subproperty of has the specific information of interest. Add {{#set:Subproperty of=some other property}} to the property page in question. You might have Property:Inverted syntax as a subproperty of Property:Syntax modification, which in turn would be a subproperty of Property:Task subject. Then a semantic query for everything in Property:Syntax modification would list everything directly part of that set, as well as anything in in Property:Inverted Syntax. --Michael Mol 20:17, 31 May 2011 (UTC)
I tried to set something like that up using {{tag}} and Property:Tag. It doesn't seem to be working the way I thought it would. Do the values for the tag property need to be properties too? It seems like this is gonna be one of those things where it takes lots of work to set it up but then after that it's awesome. --Mwn3d 16:48, 1 June 2011 (UTC)
I also just tried using the #show parser function. I get weird error messages like this (you have to click the little warning sign): <ul><li>The symbol "[[" was used in a place where it is not useful.</li> <!--br--><li>The part "]]" of the query was not understood.Results might not be as expected.</li></ul>
I was intending to use that function to put a tag box at the bottom of tasks. --Mwn3d 17:50, 24 June 2011 (UTC)