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 backlinks. 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 inconsistent data. Or am I missing something here? On Thu, Jun 5, 2008 at 12:32 AM, Markus Krötzsch <[EMAIL PROTECTED]> wrote: > 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 [1] and [2]. 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 > problems. > > > Regards, > > Markus > > > [1] "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) > http://sunsite.informatik.rwth-aachen.de/Publications/CEUR-WS/Vol-250/paper_3.pdf > [2] "Pushing the EL Envelope" (shows that a polynomial sublanguage of OWL is > no longer polynomial with inverses) > http://lat.inf.tu-dresden.de/~clu/papers/archive/ijcai05.pdf > > On Donnerstag, 5. Juni 2008, [EMAIL PROTECTED] 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. >> >> Regards >> Keith > > > > -- > Markus Krötzsch > Semantic MediaWiki http://semantic-mediawiki.org > http://korrekt.org [EMAIL PROTECTED] > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > _______________________________________________ > Semediawiki-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > > -- Jonathan "Dataweaver" Lang ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Semediawiki-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
