Re: Query == Implication of Response in a (Blackboard) Server Agent

> >An interesting way to handle queries, which shows a relationship
> >between queries and logical implication, and why it's nice to encode
> >(describe) RDF queries in RDF:
> >
> >    loop
> >       receive more RDF data
> >       add its reification (with any source information) to KB
> >       (let it be de-reified by security axioms)
> >       query KB for any unattempted action-requests
> >       for each such action-request:
> >          attempt it
> >          mark it as attempted
> >       end
> >    end
> >
> >With this approach you don't query "What's the temperature in
> >Dallas?", you say "For all X, if X is the temperature in Dallas, then
> >there exists a request for someone to send me concat('reply 12=',X)."
> 
> I find this puzzling. OK, suppose I'm an agent whose job it is to 
> respond to requests. If you send me a request, I will do my best to 
> respond to it. Bu if you just tell me that a request *exists*, then 
> that in itself is not a request, so I wouldn't respond to it. The 
> point being that the assertion that something exists is not the same 
> as a speech act involving the thing that exists.

I agree one must define these things very carefully, and I'm not sure
what terms will be the clearest.

Let me reformulate the above algorithm in more specific terms.  These
specifics may not be ideal, but they should make the point.

          loop
             wait for a network packet
	     decode it as RDF/XML
	     add each RDF sentence to the KB, like
                 candidateRDFSentence(packetInId, remoteAddr, subj, pred, obj)
             query KB for packetOut(?packetOutId, ?remoteAddr, ?data)
             for each match 
                if ( sent does not contain ?packetOutId ) {
                   send ?data to ?remoteAddr
         	   add ?packetOutId to sent
                }
             end
           end

The KB must contain some bootstrapping rules for extracting logical
sentences (like n3's) encoded in the RDF syntax, subject to various
security concerns.  Then it's up to the client to send data which
results in packetOut(...) predicates being inferrable.  Those rules
will determine packetOutId, conveying the client's uniqueness
criteria.

> >It
> >may seem more complicated, but I think the overall system of
> >client+server is simpler, because there's less contortion on both
> >sides to match an arbitrary query protocol.
> 
> I fail to see how this is a real advantage; it smacks rather of 
> head-in-the-sand. At some point, something has to deal with the 
> protocols that are being used in the transaction, in order that 
> anything will actually happen.

You say tomato, I say modularity and interface opacity.  :-)

It seems like a common issue in protocol design: if your protocol
includes a programming language, you give clients more control and
often a simpler protocol.  In this case, the programming language is
probably something like pure prolog, and the protocol becomes
completely trivial while being extremely flexible.

I suppose one of these days I should hack this up and try it a bit.
The issues that worry me are finding an efficient algorithm (the one
above is clearly, uh, for explanitory purpose) and properly
formulating those bootstrapping rules.  I guess there's a problem of
defining and removing garbage, too.   Perhaps there needs to be an
action loop on remove requests or something, although retraction
complicates some things and there are security issues there, too.

    -- sandro

Received on Tuesday, 20 November 2001 20:07:48 UTC