From: Markus Krötzsch <markus@se...>  20080606 08:50:35

On Donnerstag, 5. Juni 2008, Jon Lang wrote: > 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. Directly storing the annotations implied by inverses is a possible approach, but it requires me to rethink some parts of the storage engine. Currently, the subject of a property and the source of this annotation is the same, so we can manage annotation by their subjects. This fails for inverses. Asserting that inverses are not OWL inverses but only macros for storing annotations would prevent the principal complexity problems I sketched in my earlier mail. A problem I see is that "Inverse" is not just its own inverse (and therefore symmetrical), but that it also propagates along annotation chains. If you have a chain A inverse B, B inverse C, C inverse D, ... then a single annotation with A would require you to store annotations for B, C, D, ... as well. Moreover, if someone deletes "C inverse D" then you have to remove *some* of those annotations (which ones?). So the ideal would be that each property has at most one inverse. But one still needs to take the effect of property hierarchies into account (subproperty relations always affect both a property and its inverse). > > 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. What kind of conflicts would that be? I also want to mention two alternatives here: (1) "Inverting operator." It would be possible to restrict the use of inverses to queries. One could, for example, query {{#ask: [[Inv(has capital)::Someplace]] }} to get everything with an incoming "has capital" (which would correspond to an outgoing "is capital of"). The syntax "Inv(Propertyname)" is of course just for illustration, and one would need some nicer way of writing this (if there is any?!). I sure see the drawbacks and limitations of this proposal, but it is definitely much easier to implement than the general solution. (2) "Inverse label." Instead of connecting two properties with a general property "inverse" one could allow the property "inverse label" to be used to define a name for the inverse of any property. The effects on storage are similar as in the general case in that I need a management for annotations not created by the subject. However, one could in this setup not make chains of inverses, and one could not have subproperties or similar assertions for inverses. On the other hand, there must be a warning if an inverse name also exists as an independent property, but that can surely be generated during annotation and on the property page that has the inverse. Comments?  Markus > > Or am I missing something here? > > On Thu, Jun 5, 2008 at 12:32 AM, Markus Krötzsch > > <markus@...> 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 subproperty 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 subproperty of something else, then it is also a > > subproperty 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.rwthaachen.de/Publications/CEURWS/Vol250/pap > >er_3.pdf [2] "Pushing the EL Envelope" (shows that a polynomial > > sublanguage of OWL is no longer polynomial with inverses) > > http://lat.inf.tudresden.de/~clu/papers/archive/ijcai05.pdf > > > > On Donnerstag, 5. Juni 2008, kakugo2@... wrote: > >> Hi everyone > >> > >> Myself and a number of other MW enthusiasts host a couple of MWbased > >> 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 howto 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://semanticmediawiki.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. > > http://sourceforge.net/services/buy/index.php > > _______________________________________________ > > Semediawikidevel mailing list > > Semediawikidevel@... > > https://lists.sourceforge.net/lists/listinfo/semediawikidevel  Markus Krötzsch Semantic MediaWiki http://semanticmediawiki.org http://korrekt.org markus@... 