Markus Krötzsch wrote: > 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).
Hmm... You said in your original post that if If P is inverse to Q, and Q is inverse to R, then P = R. I was operating off of that basis, which in conjunction with OWL DL would have meant that the only possible inverse to Q is P (since OWL DL doesn't allow you to equate relations). That said, the original premise isn't true: The Father and Mother properties both have the Son property as an inverse (and vice versa); but they also both have the Daughter property as an inverse (again, and vice versa). So Father is inverse to Son, and Son is inverse to Mother; but Father does not = Mother. If and only if a given property has exactly one valid inverse property can backlinks based on it automatically have properties assigned to them. Otherwise, you must explicitly declare which inverse relationships are being used in the target document to have an unambiguous two-way association - at which point the "inverse" isn't any different than any other relation in the target document for the purpose of queries. I could see tweaking the Edit page to provide a list of backlinks to properties that need inverses to be specified, along with a list of suggestions for resolving them (e.g.: "Drew references this page as a Son. Please include one of the following properties in this page:", followed by a drop-down box containing '[[Father::Drew]]' and '[[Mother::Drew]]' as options, with script that inserts the selected link into the edit box.) Leave this as a suggestion only; the editor can choose to ignore the advice and not include any of the inverse relations on the page, although it may be considered bad form to do so, and the advice will appear on subsequent edits until the issue is resolved. This laxity would necessitate a Special page that lists all pages with unresolved "inverse links", to help with site maintenance. This replaces my original proposal concerning backlinks, which now only play a role by providing a list of pages that might have properties in need of inverses. Property:Inverse has Property:Inverse as its only inverse (i.e., it's symmetric); so if you include [[Inverse::Property:Son]] on Page 'Property:Father' and then edit Property:Son, you will be advised to insert [[Inverse::Property:Father]] somewhere in the page. As long as the editors follow the advice given, the wiki will always have a full set of bidirectional relationships wherever appropriate, easily searchable using the existing algorithms. That said, I'd also like to see subtypes of Type:Page that reference specific namespaces: so Type:Property would be a subtype of Type:Page that effectively prepends "Property:" to the front of the reference. For example, if Property:Inverse specifies Type:Property, then [[Inverse::Father]] would be essentially the same as [[Property:Father|Father]] for the purpose of what page it links to, plus the semantic annotation. This would lead to cleaner code: in the above example, you'd include '[[Inverse::Son]]' on Page 'Property:Father', and then you'd be asked to include '[[Inverse::Father]]' when you edit Page 'Property:Son'. >> 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? Never mind. Upon further review, this is a non-issue for inverse relations. -- 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
