[alicebot-archcomm] <fetch> vs. <remote>

Ernest Lergon alicebot-archcomm@list.alicebot.org
Mon, 04 Aug 2003 22:01:59 +0200


Gary Robertson wrote:
> 
> Maybe in the end I really need nothing more than an General Interface
> Protocol that can be used for passing structured requests and receiving
> structured replies between the AIML server and other servers.
> 
Now we slowly come closer...

We're dealing with following scenario:

              <remote>
ALICE <------------------> OTHER_ALICE
              proto_R

              <fetch>
ALICE <------------------> NON_ALICE
              proto_F

ALICE, OTHER_ALICE := AIML based bots, implementation nonrelevant
NON_ALICE          := any other server providing structured information

proto_R  := AIML based data exchange protocol
proto_F  := any data exchange protocol

<remote> is the easy part, because we have full control over the AIML
specs as well as the implementation and interface details. As already
mentioned, basically <remote> is just an expanded <srai>.

<fetch> is much harder, because proto_F is different for each NON_ALICE.
In other words: ALICE has to use the protocol NON_ALICE is offering,
because she wants something from her.

E.g.: To make ALICE fetch the price of a book, she can't tell Amazon to
use her protocol, she has to use Amazon's CGI URL returning XML. This
XML has to be processed to extract an appropiate answer. See
http://kosmoi.com/Technology/Web/XML/Amazon/NS4.shtml

E.g.: Let ALICE fetch a stock quote, than she has to use the SOAP
service described by http://www.xmethods.net/sd/StockQuoteService.wsdl

E.g.: If ALICE fetches news, she might have to use RDF/RSS. See
http://www.togetherfest.net/JScript/RSS.xml and
http://web.resource.org/rss/1.0/

etc. etc.

So it might be wise to predefine services and their parameters instead
of writing it on the fly - as outlined for <remote> in
http://list.alicebot.org/pipermail/alicebot-archcomm/2003-July/000874.html

Maybe the AIML could look like following (of course only a raw outline,
not thought to the end, many things missing etc.):

<services>
    <service name="BookPrice"
             url="http://bookshop.url/catalog"
             login="34cxhs74632sao"
             params="isbn"
             returns="XML"
             item="price"/>
</services>

<category>
   <pattern>PRICEBYISBN *</pattern>
   <template>
      <fetch service="BookPrice"><star/></fetch>
   </template>
</category>

Given the input "PriceByISBN 1562056473" the remote call will look like

http://bookshop.url/catalog?login=34cxhs74632sao&isbn=1562056473

and returns

<books>
    <book>
       <title>Harry Potter</title>
...other tags...
       <price>29.90</price>
    </books>
</book>

ALICE reads the tag <price> and returns '29.90'.

Doing a search, which returns multiple results might be more complicated
to handle.

I don't say, it isn't doable but I think, we have to be very accurate
designing those new tags. Thus we must have a close look to the named
issues, especially how to describe the services in a way, AIML writer
can use easily.

I wonder, why other ArchComm members do not join this important
discussion (Vacation time? Heat waves?).

Ernest

-- 
               ProgramV - Alice on Perl - available at
                http://www.virtualitas.net/perl/aiml/

       VIRTUALITAS - Manufacturer of fine OOPPS - since 1996
*********************************************************************
* VIRTUALITAS Inc.               *       http://www.virtualitas.net *
* Ernest Lergon                  *    mailto:Ernest@virtualitas.net *
*********************************************************************
       PGP-Fingerprint 6E6F DC17 A886 342D  D63F 7880 12F5 6BA9
         PGP-Key http://www.virtualitas.net/Ernest_Lergon.asc

---------------------------------------------------------------------
SPAM ALERT                       http://www.virtualitas.net/spam.html
---------------------------------------------------------------------