User:Badon/Extension:Semantic MediaWiki/Manual/Introduction to queries of interconnected properties

Querying simple interconnected properties

A page can have more than one property, and a property can be another page that has properties of its own. Properties can form a complex web called a connected graph.

Querying properties is the basic functionality of any semantic system. Right now, there is no simple or reliable way to obtain a the value of a property that is not directly connected to the property/page where the query originates. For example, for properties pointing like this:

A -> B -> C

A cannot easily access C, and vice versa, but B can access everything (A, B, and C). If we add D, like this:

A -> B -> C -> D

Then, the semantic interconnection of properties is broken, because there's nothing that can access everything. There's a somewhat complicated workaround here, that seems to be describing the "ABC chain of three" in the first example:

http://smw.referata.com/wiki/Query_linked_properties

It could probably work with any number of linked properties, with increasing complexity - EXCEPT, it's a hack that doesn't work with properties/pages that have commas in them. That means Semantic Maps can't get geographic locations, and nothing that has multiple comma-separated values for a property can work. This has the unfortunate consequence of rendering useless the best practice of pointing properties from child to parent. Not only that, but since the chain of properties can't be navigated, pages cannot inherit properties.

This means that each page must have all the inheritable properties in its graph explicitly defined. This scales exponentially! And, it is a nightmare to update things that change.

There are other workarounds involving Semantic Internal Objects:

Extension talk:Semantic Internal Objects#Combining regular semantic queries with SIO.3F

And multiple queries within templates:

http://semantic-mediawiki.org/wiki/Help:Selecting_pages#Subqueries_for_properties

But obviously, it would make a semantic wiki much more useful if such complex hacks could be replaced with just a simple query. It could even be transparent. For example, let's say you have these relationships:

Object -> Owner -> Location Object -> Type

The two graphs are linked together via the object, because an object has both an owner and a type (of object). The owner has a location, and the object's location is the same as the owner's location. If I want to run a query showing the location of all objects of a particular type, I would be starting from the type and trying to query through to the location. The actual relationship is like this:

Type <- Object -> Owner -> Location

But a simple query could look like this:

Type -> Object -> Owner -> Location

I need to get to the owner, then to the owner's location. Right now (August 2011, SMW version 1.6), Semantic Mediawiki has very limited ability to traverse property "chains".

Within a template, nested #show queries can traverse forward through the property chain. The initial #ask query traverses one step backwards through the property chain. For example, starting from Type, we go backward one step, and then forward 2 steps from Object through Owner to get to Location:

Object -> Owner -> Location Object -> Type

Or represented another way:

Type <- Object -> Owner -> Location

We use an #ask on the Type page to move 1 step in reverse to find the objects:

{{#ask: [[Category:Objects]] [[Type::{{PAGENAME}}]]
| ?
| format=template
| template=Type object locations
| introtemplate=Table start
| outrotemplate=Table end
| link=none
}}

Then the template "Type object locations" uses nested #show to move 2 steps forward to reach the Location:

{{#show: {{#show: {{{1}}} | ?Belongs to | link=none}} | ?Location}}

What we're dealing with is basically just a linked list:

w:en:Linked_list

Singly linked lists have the problem of traversing the list backwards, just like we currently have in SMW queries. But, a doubly linked list could solve that issue in the future, so long as the lack of persistence is dealt with by changing SMW's internal representation of the "back link" when changes are made by the user to the forward link. For example, in the future, the user would see this:

A <- B -> C -> D

But SMW would ALSO have an internal map that looks like this:

A <-> B <-> C <-> D

That would have to be updated internally if the user changes this:

A <- B -> C -> D

To this:

B -> A -> C -> D

Work on SMW's use of a SPARQL database may provide more capable query language features to traverse "property chains" simply:

http://old.nabble.com/Querying-simple-interconnected-properties-tt32276990.html

The current limitations are not intentional. They are a consequence of SMW's compatibility with flat-file databases like MySQL. A SPARQL database like 4Store uses an RDF/XML format that is much more capable.

SPARQL is support in SMW 1.6 when used with a supplemental database like 4Store, in addition to the main wiki database.