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
>
> <[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/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.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
--
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
