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.

That is an interesting idea, can you elaborate on what particular 
kind of knowledge logic you mean? (Do you mean McCarthy-style 
circumscription? Certainly that has the advantage of keeping the 
nonmonotonicity kind of localized and easy to find.)

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

You are probably right. You might be interested in the ideas that 
Bill Anderson has been expounding. His company uses a formalism which 
is highly expressive (KIF, in effect) but which has an overall 
assumption of closed-world negation. This gives them a combination of 
expressiveness with effective computability, he claims. Unfortunately 
Bill is in the national guard and has been called into service, so 
you can't ask him directly just now.

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

This sounds like the description logic path. The current discussions 
about rule systems often assume similar syntactic restrictions as 
well.

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

That is a very interesting idea. You really should check up on the 
RuleML website and see what is being said there.

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

What I think will happen is that mechanisms to 'protect' nonmonotonic 
conclusions on the SW will evolve with use.

Pat

>Tanel Tammet


-- 
---------------------------------------------------------------------
IHMC					(850)434 8903 or (650)494 3973   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola              			(850)202 4440   fax
FL 32501           				(850)291 0667    cell
phayes@ai.uwf.edu	          http://www.coginst.uwf.edu/~phayes
s.pam@ai.uwf.edu   for spam

Received on Tuesday, 25 February 2003 13:45:33 UTC