Help:Inheritance in hierarchies

The problem
Suppose that you want to do two things:
 * (a) You want pages (or maybe subobjects) D1 and D2 to be members of C, C to be a member of B and B to be a member of A.
 * (b) you also want to create queries where if necessary, you let the software infer from this tree of hierarchically organised relationships that D1 and D2 are also members of both A and B (or C a member of A and B, etc.).

A common scenario for this situation is the use of subclasses in many ontologies, ranging from broad (A) to narrow (D1, D2): for instance, 'Circle' (D1) and 'Rectangle' (D2) could be subclasses (or arguably, instances) of 'Positional shape' (C), which is a subclass of 'Shape' (B), which is a subclass of 'Object' (A).

Unfortunately, SMW does not currently support this kind of (transitive) inheritance. To stay with our example, results of a query of the following type:

will not automatically include pages (or subobjects) with property values of B, C, D1 or D2, nor is any additional special syntax available to make this work. However, a number of workarounds may be considered, depending on your specific situation.

Workaround using categories
A possible solution is by making every single item a member of its own category and by using subcategories to establish a hierarchy:


 * Page D1 and D2 are in Category:D
 * Category:D is a subcategory of Category:C
 * Page C is in Category:C
 * Category:C is a subcategory of Category:B
 * Page B is in Category:B
 * Category:B is a subcategory of Category:A
 * Page A is in Category:A

Having done so, you can now run a query like

and retrieve pages that refer to discussions of items A, B, C, D1 and/or D2.


 * Having to add a (sub)category for every single item could become quite tedious and laborious. By comparison, the workarounds given below are more difficult to set up but will be less work once they're firmly in place.
 * You cannot add subobjects to the hierarchy because subobjects cannot be members of MediaWiki's categories.

Two workarounds using queried property values
These approaches assume that you are using a template as the basis for each page (A, B, C, D1 and D2). The workaround can be summarised as follows:


 * Membership of each 'child' page to a 'parent' page is indicated using a property, e.g. "Property:Member of" (datatype 'Page').
 * Each page also uses another property, e.g. "Property:Subsumes items" (datatype 'Page'). Values of this property include both the source page itself and all of its child members. In our example above, the property values on page A will then be A, B, C, D1 and D2. This is the tricky part. How this can be achieved will be explained below.

The tricky part, option 1

 * In the same template, include something like the following

Disadvantage:
 * Could be slow to change/update if the chain of dependencies goes on at considerable length (a query relies on another query which relies on another query which relies on another query, etc., etc.). If you're concerned about this, consider option 2.

The tricky part, option 2: using the 'tree' format
This workaround uses the 'tree' format, although the 'oltree' format may be used instead. The three salient features of the 'tree' format are: (1) it lets you use a single property, here "Property:Member of", to give you a bulleted view of the hierarchy of pages A, B, etc.; (2) The root parameter lets you choose the top node of the tree; and (3) you can apply further formatting to each individual result if you add a template to the template parameter.

Reproduce these steps in reverse order: (b) before (a)

(a) In the main template for each page, include a query like:

(b) Create a new template, here 'Template:InheritanceTreeFormat', and add the following:



What these steps amount to is this:
 * (a) Each page will show a tree starting from that page.
 * (b) Every result produced with the 'tree' format will be stored as a value of "Property:Subsumes item".

Disadvantage:
 * This is an experimental approach as the template feature may not be ready for use. See GitHub (#123) for a bug report and discussion. The main issue that's brought up here (the omission of duplicate items) has little impact, but you may find that certain results are not at all reproduced in the tree.

The query
Regardless which option you prefer, you can now use the following query to retrieve all pages referring to items A, B, C, D1 and/or D2:

Feedback
For any wider discussion, the user mailing list is always a good place to start.