Re: Nonmonotonic rules

> >Yep. It seems particularly critical in the service realm, as Stefan 
> >again drove home forcefully in Florida last fall. If you describe an 
> >input's type using an OWL class, at invocation time, what 
> >information must you know, and know to send?
> 
> Hmm. How about having a Rule here, a kind of service-best-practices 
> Declaration from On High, to the effect that ontologies for use in 
> Service applications ought to be constructed so that just being in 
> the class, or maybe classes, is enough. If the input's type is 
> described by membership in a class C or classes C1... Cn, then the 
> ontology defining C ought to be enough for you to either infer the 
> information you want, or to be able to figure out what other queries 
> you might need to make. Then you have at least a snowball's chance of 
> figuring them out before-hand, and so advertising in your type 
> description what it is that you need to know, by listing the relevant 
> classes or inventing a special class.
> 
> >If the class is Person and person restricted onProperty childOf 
> >someValuesFrom Person...do you have to send all the information 
> >about the parents as well?
> 
> I'd say the answer ought to be, no, unless the class description is 
> something like 'person with parents', members of which would be 
> triples of people, rather than just people.

I think, as Pat said, the service needs to be able to ask the query: Is
the input in the class that I require it to be?


> >What if the individual happens to be  a member of parent and 
> >soccerCoach (where neither is a subclass of the other)? Do you send 
> >all you know?
> 
> Exactly, it could never end. It has to be up to the one requesting 
> the information to say what is needed, surely (?).

The service should state what is needed and the requester should be able to
answer the query "Is the input in the class that I require it to be?"
What if the requester lies and crashes by service? Hmm.

A practical solution might be to use a trusted ontology server and query
that one instead.

> >What if you're knowledge is incomplete, i.e., you know its a parent 
> >but don't know any further details about the children? For some 
> >services that might matter, others not.
> >This difference isn't usefully expressed by the simple declaration of type.
> 
> It could be, if there was a global convention to that effect. It 
> would require people to define the classes they needed (such as 
> classes of person-parent-parent triples): in other words, the global 
> conventions would drive the ontologies, rather than the reverse. 
> Which is as it should be, right? We should make our ontologies work 
> for us, not the other way round.

If the service asks whether the input received is in class A and the
ontology server answered yes/no based on whatever info it has then there
shouldn't be a problem.

All this depends on how you define the types and how exactly the service
uses this type information. If the service uses it to ensure that the
object's attributes it needs are defined and have values of the right
type then I don't see a problem (at least in F-logic).


> >(Stefan, feel free to jump in if I'm mangling your point.)
> >
> >It seems to me to be a severe problem: You are likely to often have 
> >too much *and* too little information.
> 
> Nothing that we can do about that, but the real problem here seems to 
> be how to indicate what information to communicate, rather than what 
> information is actually there. If information is genuinely missing 
> then nothing can be done: and there will always be surplus 
> information that isn't required for some task at hand.

Again, I think this problem arises only if the service can't query a
trusted ontology server. But if there is a reliable independent ontology
server, then the service can say: I take your input only if I can verify
with the trusted ontology server that the input you are providing is in the
classes I specified.

> >>How about datatyping? And so on. We keep running into cases where 
> >>people have divergent intuitions which can be traced back to the 
> >>differences in attitude arising from these two world-views. 
> >>Clearly at some level they are similar: Codd's Relational model and 
> >>the DL logic-based semantics all agree on the ultimate nature of 
> >>relations and classes; but the ways that the two communities think 
> >>seem often to be sharply different.  Im not sure how to 
> >>characterize the difference, exactly, but it seems to be that the 
> >>DB world-view sees a sharp distinction between different kinds of 
> >>information, and tends to treat general facts as conditions imposed 
> >>on concrete facts: meta-data as opposed to data.
> >
> >Also, as is apropos, the handling of incomplete information, and 
> >thus the kind of (and efficiency) of the sort of reasoning you can 
> >do.
> 
> Right. I guess that's a good way to think about nonmon reasoning: its 
> a way of (perhaps temporarily) filling in missing information with a 
> best guess.

Interesting. Indeed, the trusted ontology server may use nonmon reasoning
here.  The service may send the ontology server a bunch of rules that
define some class using negation as failure. This is the class that is
expected as an input. Since I am only taking that ontology into account, the
context is clearly defined and thus nonmon reasoning is fine.

> >Oh come! Substiutional quantification rules! :)
> 
> I take it that this is intended as a joke. However, as Im sure you 
> must be aware, logicians tend to view jokes about quantification in 
> the same way that airline baggage inspectors view jokes about bombs. 
> Sniff.

What is the logical equivalent of strip-searching?
(Bijan wants to know :-)


> >>Anyway, just rambling. It might be fun to try to get this 
> >>divergence between world-views stated clearly, though, as the SW 
> >>world seems to require DB folk and logic folk to be able to get 
> >>along with one another.
> >
> >Yes.
> 
> OK, who is going to write it?

Didn't you write it clearly enough in a previous msg?


	--michael

Received on Friday, 23 January 2004 00:12:38 UTC