Ring of Brodgar talk:Community Portal/Categories

==Crafted==
Merged(archived, kinda) category talk.
1) Ring_of_Brodgar_talk:Community_Portal#Categories_...
2) Category_talk:Crafted
===1===
:Category:Crafted(old) versus :Category:Curiosity crafted
Both categories were identical in data.
:Not sure at the moment what to do with this.
:Important thing here is that "Curiosity crafted" is actively used for Curiosity table generation. And its a hidden category (One of the reasons for making the category hidden was to not have "Curiosity crafted" appear on the category-bar at the bottom of the subject pages. As "Curiosity crafted" is kinda long.).
:The other categories that are also used for table generation are: :Category:Curiosity foraged and :Category:Curiosity miscellaneous. The "Curiosity miscellaneous" is the default if a item fails to fit into one of the others.
:--.MvGulik. 11:47, 11 June 2013 (EDT)
::I'm wondering if there's a way to split up the table generation to only grab items that are in both say, Category:Crafted, and Category:Curiosity? That way we wouldn't have to have :Category:All Forageables, for example, forageable items could be put under :Category:Foraged and curiosities that are also foraged can be put under :Category:Curiosity. Any curiosities not under Foraged or Crafted could be listed as Misc. if necessary. I haven't looked at the table generation code and am quite drained at the moment. {{#ask: [[Category:Wild Plants]] [[Category:Curiosity]]}}
 should work for an AND union for two cats. Example: 
::So as a layout we'd have a category, Curiosity for all curiosity pages to be under (it could also be a property), and categories for Crafted and Foraged items in general (or properties. productionMethod::Crafted|Foraged?) And then we can select the pages in Crafted AND Curiosities, Foraged AND Curiosities, Curiosities !AND Foraged|Crafted? (Might have to have a separate misc. category if the !AND isn't possible) Building the table shouldn't be much different.
:::{{#ask [[Category:Curiosity]] [[Category:Crafted]] }}{{#ask [[Category:Curiosity]] [[Curiosity:Wild Plants]] }}{{#ask [[Category:Curiosity]] }}[[Category:Miscellaneous]] }}Where Crafted would contain all items obtained through crafting.
::On another note, I've been attempting to group categories in :Category:Content together, it seems mostly self-explanatory but if there are any comments or suggestions on that, I'm listening. I'm somewhat tied up about making a new :Category:Gameplay for things like :Category:Cooking/:Category:Farming and probably :Category:Controls to separate such things from :Category:Article stubs and :Category:Terrain. Any thoughts? Sorry if this doesn't make any sense, like I said, drained. Foetuses [talk][cont.] 12:56, 11 June 2013 (EDT)
:::Some preliminary reply's. As I currently have only a limited/murky view of some of the wiki parts where talking about here. (Kinda focused/distracted on/by some other stuff than RoB-wiki.)
::"I'm wondering if there's a way to split up the table generation to ..."
:::I don't know at the moment if you can select data based on if it exist in two category. I have to look into that. But I also don't know if it would be a good thing (Things kinda murky for me at the moment.).
::::Turns out you can, with those #ask commands I listed, pretty sure. It doesn't matter what pages are in Category:Crafted, {{#ask [[Category:Crafted]] [[Category:Curiosity]]}} should only return a list or table of pages that exist in both. As for if implementation in the table is possible (on Curiosity is where I'm referring to; the tables are split into sections, but all of the curiosities are also listed in one table) it is very much possible. I'll see if I can get some example pages up to explain what I'm talking about a bit better... it all seems like it should work just fine to me, though. No need to separate crafted curiosities or foraged curiosities into their own categories, you can just selectively pick them out, if I understand correctly.
::"... (it could also be a property) ..."
:::I think your bypassing my current general wiki knowledge here ;-) . I have not had much in-dept dealings with properties so far. I have to see if I can find some time to update my knowledge on that part.
::"On another note, I've been attempting to group categories in Category:Content together, ..."
:::I'm not sure if there is much content available at the moment for categories like "Gameplay", "Cooking", "Farming", etc. Other than some useful links to forum topics on the subject. (?)
::::What I mean for :Category:Cooking and so on is to include all pages relevant to cooking, i.e. categories like :Category:Sausages and :Category:Baked Goods, etc. But that putting them alongside other top-level cats like :Category:Article stubs doesn't seem appropriate. Content is as high as it goes, so all pages related to Fishing should go under Content/Fishing. There is a Skills category, in which case I think all articles should be linked to Content/Skills/Fishing, Farming, etc. There really shouldn't be any pages in :Category:Content, I think, (as opposed to pretty much every page linking directly to that category). Each page should reference it through its subcategories, so putting a page in :Category:Sausage should put it under :Category:Cooking which should put it under :Category:Skills which should put it under :Category:Content.
:::::I'm kinda in dubio here. I feel the category tree might become way to branched and deep to easily find something. Its kinda easy to overdo it in my view. But ... well, we will see. ;-) .
:::::Yep. :Category:Content is currently where all game related pages/categories need to flow from. The :Category:Browse (as current true-root category) is for general wiki-organisation stuff only.
:::::Clearing the :Category:Content category of page-links might not be a bad idea ... BUT, if it involved a lot of pages changes its better not to start after having looked at it in detail (CQ: trying to flush out potential problems in advanced.). Will try to take a look at it. --.MvGulik. 09:37, 12 June 2013 (EDT)
:::Think some flow-chart view of the category tree would be useful here, but I'm currently having some other stuff on my plate :-( .
:::Will try to reread your post later on. Your dropping a lot of info/data/idea's, and I need time to digest it properly. --.MvGulik. 16:35, 11 June 2013 (EDT)
::::No problem, completely understandable. :-) I'll see if I can't make it clearer as for changes that should already be present in the hierarchy and an example on my userpage. Foetuses [talk][cont.] 19:50, 11 June 2013 (EDT)
::::User:Foetuses/CuriosityList
:PS: Foetuses, when you edit a page (for something else), could you see about moving the category tags above the first header on a page. Like I did here. ... I should add some note about this to the rules, but never got to it :-(. TIA --.MvGulik. 10:01, 12 June 2013 (EDT)
::The template for category tagging like here, :Category:Content, asks that they are put at the bottom of the page. Perhaps that template thing should be changed maybe. I'll add them near the top of the page from now on I guess. --Deadguy60 (talk) 17:29, 19 August 2013 (EDT)
:I gave clearing the :Category:Content category of page links (CQ(for others): making it only containing links to other categories.) some thought. But considering the Content category page is currently the only page that contains just about all game related pages (And as such must be used a lot by general wiki users) I think its not a good thing to do at the moment. Creating a other major index page first is an option, but that's still a lot of work for just moving the main page-index from the Content category page. I think there need to be more and better reasons for starting something like that at this moment. --.MvGulik. 02:07, 14 June 2013 (EDT)
::Ah, alright, just a thought. :-) I'll see how things turn out with some more thought, then. Foetuses [talk][cont.] 14:24, 14 June 2013 (EDT)
PS: After merging/ditching the separated Ore items/pages. The :Category:Ore has now only one item in it. Personally I don't see really see the point of having categories with just one item. The same it true for :Category:Metal Working if the Ore category is ditched. --.MvGulik. 08:42, 23 June 2013 (EDT)
===2===
Category:Crafted Usage
Other related talk: Ring_of_Brodgar_talk:Community_Portal#Categories_... (nts: re-read --.MvGulik. 14:32, 30 July 2013 (EDT))
I kinda feel the :Category:Crafted(old) is unneeded. Or, based on the used name, should be used for more than just crafted curiosity (like all crafted items). The :Category:Curiosity crafted has in my view the better, although a bit long, name (but that can be changed relative easy.).. See tables below for curiosity placement details.
Objections, Suggestions or other comments ? --.MvGulik. 13:53, 28 July 2013 (EDT)
:Only reason for a category at all would be if it gave some meaningfull distinction (ie behaviour of structure is different from equipment). Only two uses i see for it are for food comparison and curio comparison (as in which can be achived in what general way). Both of those are already "solved" by foraged category. So i don't think there's need for this category at all (as a side note, curiosity foraged seems equally redundant).--Rook (talk) 17:55, 28 July 2013 (EDT)
::I'm not really getting your "comparison" part. With comparing I think of comparing data(values) on items, with categories just being collections of related items(Boolean).. Which is actually what the categories "Curiosity crafted‏‎", "Curiosity foraged" and "Curiosity miscellaneous" are used for (reason why they are currently set to hidden categories). Technically this could also done by using a Boolean property for them instead of a category. ... Will ponder a bit more on this. --.MvGulik. 04:21, 29 July 2013 (EDT)
:::Yes a category is a collection of related items, but for me the question should be if a particular collection is of interest to anyone. It would be so if some sort of unique conclusion can be drawn from it (hence i said comparison). If we used category:crafted for all player-made items in game then it spans across so many completely different objects it becomes useless. Now if we're taking a look at foods it might be helpful to distinguish between ways of acquiring: hunted, foraged, baked, roasted, ground(meet), cheese. So categories for those would serve a purpose, as long as they're not duplicate or otherwise easily made queries (i.e. "category:foraged foods" could instead be achieved by simple #ask[[category:foraged]] [[category:foods]]). As for "category:curiosity foraged" it's one of those that can be replaced by such query. "Category:curiosity crafted" on the other hand cannot be easily made with a query and so it's existence serves a purpose. Of course, all of the above is my view of what category should be rather than some technical specification. --Rook (talk) 06:14, 29 July 2013 (EDT)
::::Roger. I see your point on "category:curiosity foraged". Note that for "Category:Curiosity crafted" the category tag can be changed to a bool property. At which point it can also be easily generated with a #ask query. Which in my view tosses up the question "When to use a category and when to use a property(bool)". The problem here is of course to find a good middle way, as technically you probably could ditch all categories in favor of using properties, and generate all needed lists with #ask queries.
::::On the subject of Category:Crafted versus Category:Curiosity crafted, Skipping over the technical merging stuff, it leaves (in my view) the following questions open. 1) What name to use for this category. Curiosity crafted or something else/shorter. And 2) Ditch it as category completely ? (turn it into a bool property).
::::Dragging "Curiosity miscellaneous" into this to. I think here there is a problem that you can't "NOT" tag on category/property elements with/inside a #ask query. --.MvGulik. 18:31, 29 July 2013 (EDT)
:::::Category (by default) is displayed on page while properties are highly mixed in that aspect (most are displayed but with no linking to actual property page). So i would sugest this approach: if it's something used only to create tables/queries use property, if it's something to be easily browsed on it's own, use category.
:::::I would keep curiosity crafted as category and see how many views it gets over few months, if people use it then let it stay, if they don't, we(you) can remove it later. I would also stick with the name of category as that, it might be long but it's also perfectly clear what it is. As for setting it on pages we can still use ccrafted or maybe even shorter ccraft (or maybe both so editors can use whichever they would be familiar with) but as a variable on which category is automaticaly set rather than a property. This way lenght of the category name doesn't hinder editing and pages with ccrafted already set wouldn't need any modifications.
:::::Curiosity Miscelianous here is somewhat different. As you said it cannot be created by #ask based on lack of property but it can be done so by template (ie if perxep:foraged, if ccrafted:crafted, else: misc). Now the question is if we mark it as property or category and here i would opt for property (since they are a mix of items where way of aquisition is semi-unique for each of them, rather than something common). So with that setup (category foraged, category curiosity, category crafted curiosity, property miscelianous curiosity) we should now be able to fully distingush between them in any queries.
:::::As an extra, miscelianous could be a property encompassing all "leftover" items, not only curios, since we'd be using it in a context anyway. --Rook (talk) 06:58, 30 July 2013 (EDT)
Roger. One thing pushing me towards categories in general as alternative to bool property is that #ask queries do cost more processing power (when used(not sure if there cached. Do you know this Rook, I think you had a talk about this with Spiff some time ago.)). This is currently not a problem (and probably never will with RoB wiki.), ... but still. (Reading up and rethinking stuff... ) --.MvGulik. 14:17, 30 July 2013 (EDT)
:What Spiff told me was actually regarding templates/page generation. Inline queries use caching, but to what extent i don't know (definitly for searching and also for results if frequently used). But that has no bearing on category vs property consideration. If we've got single element that defines page "domain" then, proccessing wise, it shouldn't matter if we set that element as category or property. We still can access either without a query, just on different pages. Now if we have several elements we need to check to define such "domain" then we either need a query or staticaly preset the list. Here again it makes no difference if that staticaly preset list is a category or property and if we decide to use query it will be equally tasking if it searches by categories, properties or mix of those. Real consideration is if it's worthwile to have such lists (like curiosity foraged, being a very simple subset of foraged) and i admit i haven't given it a thought originally. Now question is how often are we going to change conditions or components of such queries. Realisticly that doesn't happen often, 568 edits in last 30 days, most of that on pages that aren't query subjects (talk pages, experimentation, file uploads). Also if you look back at when we were implementing metaobj it took more time editing the pages than for them to propagate, so i think we're safe here, whichever route we choose. --Rook (talk) 16:59, 30 July 2013 (EDT)