Re: example of a non-monotonic inference needed for interpreting the social meaning of RDF in e-commerce

pat hayes wrote:

>>   In particular I intend to providing the feed to Google in support 
>> of their new Froogle service [3]  and also to publish it off my web 
>> site as an RDF feed.  Were someone to use the RDF feed to determine 
>> if I said that I could delive a particular product at any given time, 
>> they would need to use a non-monotonic inference process.
>
>
> Are you SURE it is nonmonotonic? If you are explicit about dates and 
> what delivery date means, and if you have access to a clock/calendar 
> as an external source of data, and if you time-stamp your information, 
> then the overall pattern of reasoning can be monotonic. The 
> nonmonotonicity will arise if you keep some or all of this under the 
> hood, so to speak, and make inferences which depend on it, in fact, 
> but do not openly acknowledge their dependency.

It is actually very common for nonmonotonicity (of some kind) to appear 
in simple and
obvious examples. Take an ordinary SQL-based database system and start 
building FOL
extensions to it. Every table in a database is mapped to a predicate in 
FOL. The intended
meaning of most (if not all tables) is that the correspoding predicate 
is closed in the sense
that if P(a,b) does not appear in the table then it is not true.

IMHO a suitable way to proceed in such cases is to use a "known" 
predicate and a simple
form of knowledge logic. As we know, knowledge logics tend to be cover some
nonmonotonic logics, but are better and clearer way than a trivial 
nonmononotonic logic:
intended meanings are explicit, not hidden.

Since OWL and the whole semantic web area is actually very strongly 
connected to
"ordinary" databases (that is where data is normally kept in practice, 
that is the language
understood by programmers) I guess that guidelines for combining OWL and FOL
with databases is really crucial in practice.

In simple database-like cases the knowledge-predicate-encoded queries 
tend to be
computable, since closed predicates tend to be used without function 
symbols, hence
derivability is often computable. IMHO it will be possible to encode 
most of the
practical examples of the kind Seth brought using a knowledge predicate 
while still keeping
computability of queries.

"Plain" nonmonotonic reasoning is bad. As we know, it does not work 
without additional
mechanisms for priorities, which are normally ad hoc. Explicit 
nonmonotonic reasoning
with a knowledge predicate is survivable.

Tanel Tammet

Received on Tuesday, 25 February 2003 02:37:10 UTC