Re: Model question

Hey All,

I love Kevin Gamiel's question.  My guess would have been that the
unnecessary distinction between database and result set is just a
reflection of the difference between objects that pre-date  z3950 versus
objects that were invoked or invented for z3950.    People maintained named
databases before z3950, and so as the object of searches the concept of
"database" quickly took its unquestioned (and unquestionable) position among
the formalities.  But databases do not require a prior referent and so 
could not be
classed with the later invocation of "result sets", which of course must be 
*derived*
from something.  From a practical design point of view, databases are 
*given* and
cannot be questioned, while result sets are new to the picture.    The 
former are
necessary,  the latter are convenient.    The resulting apparent redundancy 
in the
final specification is the customer's finger print.

-mark :-)
mcrane@ii.com






At 04:38 PM 7/24/03 +0200, Edward C. Zimmermann wrote:


> >
> >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 12:47:58 UTC