[seek-kr-sms] OWL Inference APIs (was Re: SMS stuff)

[Ferdinando Villa]

Going back to the DL reasoners discussion, does anyone at this point
share my feelings that we won't get away with this if we don't have a
fully open source reasoner architecture where types and operators for
concrete domains can be arbitrarily extended? As an obvious and
well-known example, implementing any reasoning on space will require
robust spatial operators which are many and complex. Other forms of
reasoning we may need could require access to name resolution services
that require too large a KB to handle in owl. In general, a plugin-based
architecture where we can associate concepts with known literal formats
and operator implementations sounds like a necessity to me.

We may get away with OWL reasoners alone, but if we in fact need
something like this, it sounds to me that we should start planning
sooner rather than later.... and it sounds like something we (Bertram +
Gund) could successfully work on together. There's a lot of experience
here on plugin-based architectures, robust topological operators, and
client/server architectures, and Serguei seems increasingly eager to try
his ideas on DL reasoning out :)...

Ciao 
ferdinando



On Thu, 2004-04-01 at 10:26, Serguei Krivov wrote:
>  Bertram,
> Sure, if we can get the essential part of what we need just with owl ,
> that would be the best option. But I thought it would be nice to have a
> clear idea about availability of this option in context of the
> requirements we have.  We might live w/o Role boxes and feature
> agreements (although they are nice) but we can not bypass the problem of
> compatibility of spatial/temporal datasets. 
> 
> In connection with this   I wanted to ask you and Shawn- how will you
> deal with spatial/temporal context of datasets in your theory of
> semantic types (ref to your paper)- will be spatial/temporal context
> part of semantic type or it will be handled separately as
> spatial/temporal feature?   For example if one wants to check hypothesis
> "In all places where there are bears the species abundance is high"  one
> would possibly need to compare areas where bears live with datasets
> related to species abundance in some areas that covers the bears area.
> How we would then specify constraint that location of one dataset should
> cover location of another. The attribute has location is part of
> ontology (Fig 4 in your paper). Does it imply that location should be
> part of semantic type???? 
> 
> 
> Another point about getting away with existing  reasoners: Here are
> concrete domain expression which RACER supports. My understanding is
> that owl does not support that( please correct me if it is wrong!). Can
> we use that to specify all what we need about spatial locations???? For
> rectangular regions perhaps?? 
> (AN stands for attribute name).
> CDC -->
>  (min AN integer) |
>  (max AN integer) | 
>  (equal AN integer) | 
>  (equal AN AN) | 
>  (divisible AN cardinal) |
>  (not-divisible AN cardinal) | 
> (> aexpr aexpr) |
>  (>= aexpr aexpr) | 
> (< aexpr aexpr) | 
> (<= aexpr aexpr) | 
> (<> aexpr aexpr) | 
> (= aexpr aexpr) | 
> (string= AN string) | 
> (string<> AN string) | 
> (string= AN AN) | 
> (string<> AN AN)
> 
> string -> " letter* "
> 
> aexpr--> AN | real | (+ aexpr1 aexpr1 _) | aexpr1
> 
> (see pages 47 and 50+ of RACER manual) 
> 
> 
> >>Do you have plans to use existing or tweak, extend existing reasoners?
> >>(we have some plans here on that too ...)
> 
> Yes we need a DL reasoner in context of IMA and in context of Integrated
> History KB project we are trying to fund.  In both cases support for
> spatially/temporally explicit reasoning is crucial. In both cases we
> would rather get away with owl and existing reasoners if we can. But at
> this moment I do not know if we can and I want to know it for certain.
> 
> Best Regards,
> serguei
> 
> 
> 
> 
> 
> 
> Bertram
> 
> >>>>> "SK" == Serguei Krivov <Serguei.Krivov at uvm.edu> writes:
> SK> 
> SK> Shawn,
> SK> Thanks for the interesting survey. I also have been looking at DL
> SK> reasoning with focus on tableaux algorithms and found a few points
> worth
> SK> of attention. Apparently there are a few semantic features which are
> not
> SK> part of present owl, but they are extremely useful and they are
> SK> available in some decidable systems.
> SK> 1. Role boxes: In owl one can not say that role Uncle is subrole of
> SK> composition of roles Parent*Brother. Role boxes were avoided for a
> long
> SK> time since in general they lead to undecidable systems. But
> apparently
> SK> some limited (acyclic) role boxes can be added to SHIQ without loose
> of
> SK> decidability:
> SK>
> http://www.cs.man.ac.uk/~horrocks/Publications/download/2003/HoSa03a.pdf
> SK> 
> SK> 2. Feature(functional role) agreement. In owl one can not say
> something
> SK> like
> SK> "for every chemical flow its agent should be the same as agent of
> SK> respective stocks it connect"-
> SK> flow.agent=flow.source.agent=flow.target.agent. But in very old
> system
> SK> ALCF it is possible. Apparently addition of  agreement/disagreement
> for
> SK> functional roles does not lead to undesirability in many even more
> SK> complex cases.
> SK> 
> SK> 3. Reasoning with concrete domain vs time and space. Reasoning about
> SK> space and time may not be important for general users of ontologies
> so
> SK> it is not in owl. But it is important for ecologists and perhaps
> SK> eventually we shall bump in it. Although Racer supports reasoning
> with
> SK> concrete domains such as integers and friends, it does not come to
> SK> space/time. Yet potentially we can use DL reasoner for checking
> SK> consistency of statements about space, time , and even space-time as
> SK> long as they are represented properly (as admissible domain). I am
> SK> attaching paper that surveys this topic in detail. Specifically
> SK> interesting points about space and time are in the end and of course
> SK> there are many references on this subject worth of reading. 
> SK> 
> SK> Certainly it is not possible to combine all semantic features we
> need in
> SK> one decidable DL system.   But I think it would be good to
> understand
> SK> what features are the most important in context of SEEK. Then we can
> try
> SK> to design a tableaux that accommodates most of the essential
> features we
> SK> need.  
> SK> 
> SK> Serguei  
> 
> _______________________________________________
> seek-kr-sms mailing list
> seek-kr-sms at ecoinformatics.org
> http://www.ecoinformatics.org/mailman/listinfo/seek-kr-sms
--