语义搜索可用来根据用户向维基站点当中所已经输入的关于页面的信息来找出页面。 这可以简化很多的任务，但其仍需要首先采取手工方式输入语义信息才行。 在有些情况下，我们可能会期望维基站点«更加聪明/智能些»，即使是并未直接输入过某些事实，也可以推演出这些事实。 如本文所述，在有些情况下，SMW可以自动得出此类的推论。
Contents
子类别[edit]
MediaWiki支持着一个类别层级结构（category hierarchy），其有助于简化每个页面上所需的类别语句（category statements，类别声明）。 例如，假设某个维基站点使用着三个类别：«Person»、«Woman»和«Man»。 对于人来说，每个属于类别«Woman»的页面，显然同时也属于类别«Person»。 但是，«Woman»明显更为特殊（具体），许多维基站点（包括Wikipedia在内）都有一项政策就是，要求在特定页面上仅仅使用最为特殊的类别— 否则，页面上往往就会不得不包含数十个类别，以致于难于维护。为了表示一个类别比另一个类别更为特殊，MediaWiki支持着一个类别层级结构；其中，用户只需将一个类别放在相应的子类别页面之上，即可声明一个类别是另一个类别的子类别（subcategory）；比如，页面Category:Woman可能就会含有如下文本：
[[Category:Person]]
详情请参加MediaWiki手册。
默认情况下，SMW会在语义查询当中利用这种子类别信息：当请求所有属于某个类别的页面时，同时也会找出属于该类别的任何子类的所有页面。在上述示例当中，查询[[Category:Person]]同时会返回类别«Woman»和«Man»当中的那些页面。换句话说，实际的查询对应于如下查询：斜体文字
[[Category:Person]] OR [[Category:Woman]] OR [[Category:Man]]
如果类别层级结构更深的话，则SMW还会将进一步的子类别包含进来。例如，可能还有一个称为«Mother» ，由所有有孩子的妇女所组成的类别。 这个又是«Woman»的子类别。那么，上述查询也会检索出类别«Mother»当中的所有页面。
网站管理员可以限制或禁用SMW的子类推理机制。正常情况下，其仅仅支持某一最大深度的类别层级结构。 因此，如果涉及到的子类别链非常长的话，它可能并不会返回所有的结果。 在这种情况下，一种变通的手段就是利用OR来手工创建查询。 但是，这当然并不会考虑到类别层级结构当中的任何变更。
在某些情况下，维基站点会使用并不适合于按上述方式处理的类别和类别层级结构。比如， Wikipedia使用一个称为«Cities»的类别，并不是为了收集所有的城市，而是为了收集所有以某些方式与城市相关的的文章。 甚至将类别«Cities in Canada»用于收集所有与该主题有某种关系的页面。 这并不是类别或类别层级结构的实际问题：语义查询[[Category:Cities]]仍返回的是所有与该主题相关的页面，它并不是仅仅返回实际的城市。因此，有人可能会说，类别名称在某种意义上令人困惑，但这仅仅是对于一个维基站点如何组织的事情。如果一个维基站点并未设有关于实际城市的类别，则没有任何语义查询能够直接产生出所有的城市。
大型维基站点的一个更为严重的问题可能就是所谓的«语义漂移（semantic drift）»。 当某个类别的确切意图并未得到真正说明的时候，就会发生这种情况，比如，因为在其页面上缺乏对其详细的描述。 对于类别的含义，不同的用户则可能有着稍有差异的解读，而这就可能影响他们对子类别声明（语句）的使用方式。 例如，一些编者可能合乎情理地说，«Priest»（牧师）乃是«Religious office»（宗教办公室）的一个子类别（指的是职位类别）。 而其他人则可能认为«Female priest»（女性牧师）乃是«Priest»（牧师）的一个子类别（指的是拥有该职位的人员的类） – 但是，这就意味着，«Female priest»（女性牧师）当中的所有页面同时也隐含地归类在«Religious office»（宗教办公室）当中，从而把人员与工作职位混淆了起来。 因此，重要的是始终在类别页面上明确清晰地描述究竟什么应当而什么不应当归入某个类别，且同时指出可能适合的备选类别。
子属性[edit]
就像类别那样，属性亦可比别的属性更为特殊（或者是特异、具体）。例如，维基站点可能备有用来将城市与国家联系起来的属性«capital of»（是……的首都），儿属性«located in»（位于……）则在广义层次上描述的是某个城市位于某个国家当中。这样，正好每个首都城市同时也必须位于其作为首都的相应国家里面。换言之，«capital of»（是……的首都）就是«located in»（位于……）的一个子属性（subproperty）。只要用户声明某个页面时某一国家的首都，则SMW就应当同时得出结论，该页面与该国家之间也是一种（隐含的）«located in»（位于……）关系。要在维基站点当中表达这样的意思，可在属性页面Property:Capital of当中输入如下声明：
[[subproperty of::Property:located in]]
一旦声明了这个，查询[[located in::Germany]]也会返回首都柏林Berlin，即使是该页面上并没有给出属性«located in»（位于……）。类似的考虑事项也适用于类别的情况，而避免语义漂移的一种好方法就是在属性页面给予详细的描述。
页面的相等性：重定向[edit]
常见的一种情况就是，可以采用不同的名称来指称同一事物。比如，"Semantic MediaWiki"就与"Semantic MediaWiki"同义。 在MediaWiki之中，重定向（redirects）'解决了这个问题，可将读者从一个页面转到另一个页面。但是，在语义维基站点（semantic wiki）当中，我们希望对内容加以组织，并使其更加易于访问，同义词（synonyms）因而可能显得甚至更为重要。 如果不同的编者在标注当中采用不同的页面名称，要创建出仍将显示维基站点统一视图的话，就会很困难。
SMW因此将页面之间的所有重定向均视为同义词。这就意味着，在查询或标注当中究竟采用的是重定向页面还是实际的目标页面，其实根本没有关系。 SMW在内部进行处理时采用的仅仅是重定向目标，而所有的功能也会考虑到这种重定向结构。这种机制仅仅对直接的重定向（immediate redirects）有效：并不支持那些指向其他重定向页面的重定向，而且应当解决这种间接重定向问题（无论任何，这在MediaWiki当中也是如此）。
自从SMW 1.2版起，亦可同样效果地使用针对属性和类别的重定向，因此亦可为属性创建同义词。 对于类别，则不建议使用该功能，而这只是因为MediaWiki的类别功能仍将忽略类别重定向，以致于某些维基站点功能并不会像预期的那样发挥作用。 从一种特殊的语义角度上来说，并不支持诸如正常页面到属性、属性到类别等等之类命名空间之间的重定向。 它们依然创建的是正常的MediaWiki重定向页面，而不是其他任何东西。
推理与打印输出语句[edit]
打印输出语句一般并不执行任何的推理，也就是说，它们将仅仅返回的是那些明确针对某个页面所给出的语句。 在某些情况下这正是所期望的，而在其他情况下则可能是一种限制。 一种变通方法可能就是，基本上通过编写类似下列语句的查询，利用某个模板进行标注，并明确在该模板当中给出两个属性取值：
[[capital of::located in::Germany]]
这等同于同时写上[[capital of::Germany]]与[[located in::Germany]]，但其将仅仅显示一条指向Germany（德国）的链接。
尚不支持的推理功能[edit]
有时出现的情况就是，在一个维基站点当中，雄心勃勃的贡献者会创建某些属性，而这些属性同时又会提示出某种适合于自动推演的特殊含义。 因此，应当注意的是，SMW并不支持下列的任何功能特性：
- 可传递性（transitivity，可递性，传递性）
- 领域（domain）和范围（range）限制
- 数值限制和功能属性（functional properties）
即便是引入了类似于上述情况的属性，甚至是将其链接到了OWL、RDFS、SKOS等等之类本体语言当中众所周知的属性之上，SMW也不会利用此类标注来完成更为聪明/智能的查询。 为了避免混淆，建议不要使用那些类似于已有本体语言当中公认概念的名称，或者至少在相应的属性页面上明确记载这种限制。
在某种程度上，我们可能能够创建出用于实现类似效果的查询。示例页面Germany（德国）和Demo:California（加利福尼亚）展示的是关于逆向关系（inverse relationships）的查询的例子；示例页面Germany（德国）展示的是一个子查询的例子，其在某种程度上近似于一种可传递型关系（transitive relationship）。
