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

Thu Apr 8 07:50:45 PDT 2004

FV>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?.... 

Since it is also related to our past discussions please allow me to draw
some implications from what Ferdinando suggests here. The question is
how to reconcile OWL and non standard semantic features both mentioned
in Shawn's design document, p.4. In page 4 there are references on OWL
Ontologies and just next to it- Additional Constraint. The question is
how we would possibly use these two things within one system.  One
possible approach: While continue using OWL as ontology interchange
format we may have far more flexible underlying language that is
amendable to extension and have power to express all OWL-DL  and more (
who really cares about non DL part of owl?) Examples of such formats
are:

DLML: http://co4.inrialpes.fr/xml/dlml/
DIG: http://dl-web.man.ac.uk/dig/2003/02/interface.pdf

DIG is supported by FaCT and RACER, and it is rather web service
protocol then format. Yet it is based around SHOIQDn ~OWL+ support for
some concrete domain operators.DLML is meant to be markup for any DL, so
it is flexible, but I did not see any applications that use it.

The interface tools we develop may rely on those DL interchange format
but support import export to owl. This approach would allow to reuse
existing ontologies and at the same time use other rich semantic for
concrete domains, role composition etc as soon as they arrive in the DL
market and supported by reasoners.

The reasoner plugin mechanism may allow  specifying the subset of
possible semantic constructs that respective (plugged in) reasoner
support. As you know the set of them can be even derived from the name
of respective DL. This would allow using variety of reasoners arriving
in the market as soon conversion from/to their native format to/from DL
interchange format is provided. 

Ferdinando-I hope I did not misinterpret you?

Alternatively- what other mechanism can be used to reconcile OWL and non
standard semantic features both mentioned in Shawn's design document?
One way is to use one more expressive language , such as DLML which will
take care about the synthesis.  But do we have any other way to combine
owl with additional constraints?

serguei

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
-- 