Help:Categories and properties

The snicdocs wiki makes extensive use of properties and categories, in part to simplify navigation for the users, but mostly because it permits straightforward creation of dynamically generated lists, tables and mashups using the semantic mediawiki extension. This, however, requires generous peppering of category and property tags onto wiki pages, using great restraint and strict discipline so that nomenclature does not run rampant and diverge (see: the problem with the semantic web).

Categories and properties have many things in common, however with gross oversimplification one could say that categories tend to be easier to use and are more magic, while properties are more flexible. Categories are big things. Adding categories to a page not only annotates the page to fall under those categories, but also adds cross links and generates indexes. They are great for searching and finding, but less good for dynamic generation of content. For example, this table:

{{#ask: [[Category:Bioinformatics]] [[Category:Application expert]] | ?centre | ?expertise }}

could not be generated if the pages had not been annotated with properties stating that NSC is a place where a person works, and that these other things are in fact stuff they do good. The reason we don't drop categories altogether is that categories have much added sweet sugary magic which would take a lot of boring effort to recreate with properties each time they're used in that fashion.

When to use one or the other should be quite obvious from gut feeling or looking at examples, but if in doubt: use categories. If using categories leads to awkwardness or unwanted effects, use properties.

Guidelines for creating new categories and properties

Do not invent categories and properties recklessly!

Check these lists first, to see if any of the already existing ones may suit your needs:

Special:Categories

Special:Properties

Use singular for names

E.g. Application expert, Resource, Centre...

Follow the naming protocol for titles, headings and names

It's right here.

Use descriptive and unambiguous names

Especially for properties. Keep in mind that these will be used to define searches and will also end up as headings in dynamically generated tables, unless other people do extra work to change it on each use.

Are you creating a new subcategory?

Categories can be nested in a DAG (tree) structure. Look at the current list of top categories:

Special:UncategorizedCategories

Does yours fit on that list, or will it fit better as a sub(-sub)-category? Drill down and see, and annotate your new category accordingly.

What does it mean, exactly?

What does it entail? How should it be used? Add a brief and unambiguous description to the property page (eg: Property:Expertise, or Category:Application expert). Leave no room for misinterpretation, as this could potentially make your work useless.

Use Type:Page (the default) for properties

You of course have lots of freedom when it comes to selecting a type for your property (cf. Special:Types), but generally, you should use the default unless it would be ludicrous to do so (e.g. it's a number, date, etc...). These are examples where the default "Type:Page" is the most useful: [[expertise::python]], [[expertise::MSA]], [[centre::NSC]], [[image::warface.jpg]]. In short, do not mess around with types and everything will probably work out OK.

Except when it's ludicrous to do so

Property:Description is of type string, because these should be unique, should be a phrase, and would thus look silly as a page heading or link, and for other reasons that are clearly written out on its property page. A numeric property that gives the number of petaflops on a resource would likewise be silly with Type:Page. If need arises, combat need with careful consideration, and when you finally give in, choose another type and provide reasonable rationale on the Property page.