Re: Model question

>
>The search service provides a method for applying a query expression 
>"directly" against a set of databases (DB), generating a logical, 
>server-side result set (RS).  The present service provides a method for 
>retrieval of records from a RS.  The RS is *not* modelled directly as a 
>DB, that is, the search service may not use an RS directly as if it were 

The seperation between database (be it a collection of databases)
and result sets I think is quite natural and reflects the different kinds
of operations. 
Why can't one search a result set? Effectively one can via query refinement.

QueryA ----> RS1

To search for QueryB in RS1?

QueryA & QueryB ... Right? 

With result sets we have the cute possibilities also to do

QueryA ---> RS1
QueryB ---> RS2

And then RS1 & RS2 .. The intersection of the two sets.. Which is also...

The parallel is between Query and result set... The database is just the
domain..

We could have defined result sets as databases.. but would it not have
been more natural to define database as a result set?

This, however, would have created its own ball of problems.. From an
implementor view--- and lets not forget that Z has been implementor driven
(also to its strong disadvantages as in kitchen sink)--- I am quite happy
the way it is..


>a DB.  However, type-1 and type-101 queries (at least), allow one to 
>include an RS reference as an operand, *effectively* turning an RS into 
>a DB, though with some (minor?) loss of functionality.

That's a kludge as in "can do it". Only element makes sense really for 101..
And we just jam it down the throats via the Query.. (where it belongs).


>Was including an RS as a query operand a clever afterthought to avoid 
>changing the underlying data model, or is there a more significant 
>reason to maintain the DB/RS model distinction?

As you recall 101 was a "clever" afterthought but I think it fit well
within the model. If we would have tossed the target/result set distinction

Recall any DB defiens a result set (the universe of a DB is its RS of all
its elements) and these can be combined with all the kinds of things we can
do with result sets... But as a DB? We are limited to just query expressions
to jam down it and that's it.

In this vein, I think we would have, should the direction have been to turn
RS into a DB, lost a lot of power (and made some implemenations a pain)..


>
>Thanks!
>Kevin
>
>-- 
>Kevin Gamiel <kgamiel@cnidr.org>
>MCNC Center for Networked Information Discovery and Retrieval (CNIDR)
>http://www.mcnc.org
>http://www.cnidr.org
>
>


______________________
Edward C. Zimmermann, Basis Systeme netzwerk, Munich
<A 
HREF="http://www.stadtplandienst.de/query;ORT=m;PLZ=80802;STR=Leopoldstr%2E;HNR=
53;GR=2;PRINTER_FRIENDLY=TRUE">Leopoldstrasse 53-55, D-80802 Munich, Federal 
Republic of Germany</A>
Telephone:   Voice:= +49 (89) 385-47074  Fax:= +49 (89)  692-8150
          Cellular:= +49 (179) 205-0539

Received on Thursday, 24 July 2003 10:38:49 UTC