On Freitag, 6. Juni 2008, Jon Lang wrote: > 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).
Yes, the only possible *semantically distinct* inverse is P (which is always equal to R in this example). But some wiki user can still make two distinct property pages for P and R, and SMW then has to figure out that these are equivalent *for the current information on inverses*. If the inverse-assertions in the wiki change, then statements for P and R may again become different from each other, so SMW would also have to keep them separate in some sense. > 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. As you demonstrate, "Son" just is not the inverse of "Father". This is so, since there are examples where this inverse is not true: Bob may be the father of Alice, yet Alice is not the son of Bob. the following are pair of inverses in this context: "parent of" -- "child of" "father of" -- "has father" "mother of" -- "has mother" "has son" -- "son of" "has daughter" -- "daughter of" You see why we often use "has" and "of" in our property names ... > > 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. Inverses are always unique. It's how they are defined. I do not know what a concise name for the relationship between "father of" and "son of" could be, but it is not the inverse in the sense in which this term is normally used. I think we can also ignore the above relationship since, as you also said, there is not much one can conclude based on such a relation. > > 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. I get that idea, but it seems to be a special case of more general relationships one could specify. The above example combines multiple pieces of information: * "has son" is a subproperty of "has child" * "has child" is the inverse of "has parent" * all cases of "has parent" are either "has mother" or "has father" Thus, any page that is the target of "has son" is also the target of "has child" and hence must have an inverse link "has parent". This is what an SMW with inverses enabled would need to conclude automatically. Then, finally, SMW could offer the user to refine the relationship "has parent" into "has mother" or "has father". But this is not directly related to whether or not inverses were involved -- one could also offer this refinement in many other cases (even for categories: "This page is an Event. Please try to be more specific!"). Edit suggestions like the above would be very useful and valuable in general, but I think we can separate their design from the design of (semantic) inverses, since they occur in so many cases in the wiki. What you propose seems to be to first develop an engine for making edit suggestions, and then implementing inverses as edit suggestions instead of as necessary (automatic) conclusions. My impression is that this would leave much work to the user where it could be done automatically by SMW (if you have a real inverse, then it is not necessary to ask a user for help in asserting it). > > 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. (Well, besides the fact that these properties are not inverses. I also see that some form of explanation for concluded inverses will be necessary to make such modelling errors understandable to users.) > > 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'. Yes, I fully agree. We already have such a mechanism for types (writing [[has type::Number]] works as well as [[has type::Type:Number]]), and builtins like "subproperty of" should certainly work similar for properties. > > >> 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. OK. -- Markus -- Markus Krötzsch Semantic MediaWiki http://semantic-mediawiki.org http://korrekt.org [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------- 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
