I'm not familiar with Keith's solution; but here are my own thoughts
on how this should work:
In MW, there's a capability of looking up which pages link to the
current page (i.e., backlinks). In SMW, the inclusion of inverse
relationships would be most naturally implemented by applying inverse
properties to a page's backlinks: that way, if A contains B and
"contained by" is the inverse of "contains", then B will automatically
be contained_by A. This necessitates a modification of the MW
backlinking algorithm to identify potential "semantic backlinks", and
further requires that a page's factbox examine the page's backlinks as
well as its normal links when determining what semantic data applies
to the page. If backlinks are stored in a table instead of calculated
on the fly, this shouldn't excessively impact access time.
Oh, and the property that defines a property's inverse relationship is
its own inverse; so establishing that B is the inverse of A will
automatically establish that A is the inverse of B through B's
You could even put in a test when saving changes to a page: if the
change includes establishing a property that conflicts with an
existing "backlink property", reject the change on the basis of
Or am I missing something here?
On Thu, Jun 5, 2008 at 12:32 AM, Markus Krötzsch
> Hi Keith,
> thanks a lot. I will definitely consider your patch soon. The current delay in
> doing so is due to the complete rewriting of the storage engine. But let us
> discuss your proposal first, since I feel there are some problems that may
> still need to be solved.
> Inverse properties are of course a natural feature that is also available n
> the OWL DL ontology language which SMW uses for data export. A general issue
> with inverse properties, however, is that they can create performance
> problems in querying when further expressive features are added. Examples
> where such effects were studied are  and . Of course, SMW wants its
> query evaluation to stay computationally tractable (i.e. polynomial), so we
> have to be a little bit careful here.
> Even in the current simple case (where inverses certainly do not affect
> tractability yet), there are some effects that SMW's query engine would need
> to take into account:
> (1) Properties that are inverse to themselves are symmetric.
> (2) If P is inverse to Q, and Q is inverse to R, then P = R.
> (3) If P is a sub-property of Q, then the inverse of P is a subproperty of the
> inverse of Q.
> (4) Item (3) also works in similar ways with other situations, e.g. if a
> symmetric property is a sub-property of something else, then it is also a
> sub-property of its inverse.
> Does your implementation currently take these effects into account? The
> problems do not become smaller if future extensions like transitivity are
> added. Maybe you can comment on your current approach to tackle these
>  "Inverse Roles Make Conjunctive Queries Hard" (shows that the conjunctive
> querying problem for more expressive ontology languages jumps up in
> complexity by one exponential when inverse properties are added)
>  "Pushing the EL Envelope" (shows that a polynomial sublanguage of OWL is
> no longer polynomial with inverses)
> On Donnerstag, 5. Juni 2008, kakugo2@... wrote:
>> Hi everyone
>> Myself and a number of other MW enthusiasts host a couple of MW-based sites
>> that make use of SMW.
>> A problem I came across when working with semantic relations was the lack
>> of inverse properties, a way to define a name for an opposite relation (A
>> *is part of* B, therefore, B *contains *A).
>> I have attempted to fix this issue with some minor changes to the SMW code.
>> I am sure this is an obvious feature SMW will eventually have, as noted in
>> the documentation.
>> Here is an example of my use of the changes I made:
>> http://www.nazuz.com/wiki/Heading_up_%28sailing%29 // this page contains
>> the semantic data
>> http://www.nazuz.com/wiki/Reducing_heeling_%28sailing%29 // this page has
>> limited semantic data, but much inverse data
>> http://www.nazuz.com/wiki/Property:Is_a_method_of // The inverse property
>> of "Is a method of" is defined here. ( [[Inverse::Property:Can be achieved
>> by]] )
>> I also had to setup http://www.nazuz.com/wiki/Property:Inverse . //
>> Explanation is on the page itself.
>> All in all the changes were limited, but I ran into trouble with the
>> printfactbox method as it runs inside a parser hook, and the idea is to
>> load inverse properties even if there are no semantic syntax matches on the
>> page. The printfactbox is running from the skin in my version.
>> It would be nice to see this sort of possibility in future releases, as it
>> provides a better way to navigate between pages using the semantic
>> relations rather than the outdated category system. It is also a must for
>> how-to wikis.
>> I don't know if someone else has already done this but this way my approach
>> in any case.
> Markus Krötzsch
> Semantic MediaWiki http://semantic-mediawiki.org
> http://korrekt.org markus@...
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> Semediawiki-devel mailing list
Jonathan "Dataweaver" Lang