Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Rightclick on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
From: Jon Lang <dataweaver@gm...>  20080606 11:39:19

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 twoway 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 dropdown 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:FatherFather]] 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 nonissue for inverse relations.  Jonathan "Dataweaver" Lang 
From: <kakugo2@gm...>  20080605 06:26:52
Attachments:
Message as HTML

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 
From: Markus Krötzsch <markus@se...>  20080605 07:33:17
Attachments:
Message as HTML

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/paper_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@... 
From: Jon Lang <dataweaver@gm...>  20080605 10:52:10

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 <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/paper_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 > >  Jonathan "Dataweaver" Lang 
From: Markus Krötzsch <markus@se...>  20080606 08:50:35
Attachments:
Message as HTML

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@... 
From: Wei Dai <weidai@we...>  20080615 00:08:09

Markus Krötzsch wrote: > > (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]] }} > I had sent in a http://osdir.com/ml/web.wiki.semediawiki.devel/200612/msg00008.html patch for something like this back in 2006. I'd really like to see this feature make it into SMW, so I can upgrade my SMW installation. And what if we first implement this, and then add a feature which might be called "inferred properties"? I'd like to be able to associate any property with a query that would allow SMW to infer this property from other existing properties. For example, in a wiki with People, Papers, and Algorithms, I'd like to have a Designed property which can be manually annotated, but can also infer that Person A designed Algorithm B by the fact that he wrote Paper C which introduced Algorithm B. Then inverse properties would be a special case of inferred properties, since a property and its inverse can be linked to each other by inverse queries.  View this message in context: http://www.nabble.com/SMWinversepropertiestp17663060p17845133.html Sent from the Semantic Mediawiki  Development mailing list archive at Nabble.com. 
From: Jon Lang <dataweaver@gm...>  20080606 11:39:19

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 twoway 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 dropdown 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:FatherFather]] 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 nonissue for inverse relations.  Jonathan "Dataweaver" Lang 
From: Markus Krötzsch <markus@se...>  20080608 12:50:38
Attachments:
Message as HTML

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 inverseassertions 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 twoway 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 dropdown 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:FatherFather]] 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 nonissue for inverse > relations. OK.  Markus  Markus Krötzsch Semantic MediaWiki http://semanticmediawiki.org http://korrekt.org markus@... 
Sign up for the SourceForge newsletter:
No, thanks