pcplantdb

[Richard Morris <webmaster@pfaf.org>]

> Date: Tue, 8 Jan 2002 22:00:19 -0800 (PST)
> From: John Schinnerer <eco_living@yahoo.com>
> To: pcplantdb@lists.ibiblio.org
> Subject: [pcplantdb] basic issues redux
> Reply-To: pcplantdb@lists.ibiblio.org
> 
> Aloha,
> 
> Just duping this to this list...I want to clear this up...
> 
> > We have already been through this discussion.
> > I said that one is needed for North America and that only those
> > living there will likely contribute, especially in the data
> > department...
> >You, of course, are free to work on any one you
> >choose...
> 
> I think there's some misunderstanding about what exactly we are
> creating.  For the non-technical, and the technical who haven't thought
> about it yet:
> 
> There are two basic elements to a working *database* - the *engine* and
> the *data*.
> 
> The *engine* is the software that does the work of taking in,
> organizing, managing, categorizing, etc. etc. and handing out the data.
> 
> The *data* is the information that the engine is designed to handle,
> manage, sort, categorize, return, etc. etc.

Good distinction.

> A useful, working *database* consists of an *engine* that is populated
> with (has in it) relevant *data*.
> 
> My understanding has been that we are proposing creating a PC plant
> database *engine* as an open source project, freely available to
> whomever finds it useful.

I'd hope its a little more than that. I hope that we will be
actively encouraging and facilitate the creation of plant datasets.
I'd hate to see a fancy interface with nothing in it.

> Different individuals and groups may have their own *data* that they
> want to put into a (not *the*) database.  Each uses the *engine* we
> create to input, manage and output the data they consider relevant.
> For initial development purposes we may use primarily N. American plant
> *data*, but it doesn't matter to the design of the *engine*.
> 
> Ideally we design the *engine* so that it can access any or all of the
> various *databases* (engine + data) that are created using it.

Maybe I've a slightly different view. From a my SQL point of view
a database just seems to be a collection of tables, queries, input 
and output forms are not included. I suppose I'm conceptually thinking
of collecting datasets (collections of tables) rather than databases.
 
> That is, the *engine* can communicate with other instances of itself
> (the engine running on one server can communicate with the engine
> running on another server) to search the *data* in other *databases* on
> other servers.

For starters I guess we should stick with things on one server.
Remote linking is a whole other can of worms.
 
> If PC-relevant plant data is as 'universal' as we imagine, the *engine*
> will be applicable to databases for all areas of the world - that is,
> it will handle data for 'N. American' plants equally as well as for
> 'African', as for 'tropical', as for 'Siberian', as for whatever.
> 
> This is also basic software design practice - separate code from data
> (from presentation, but that's not an issue here...yet... ;-)
> 
> This is what I am interested in contributing to.  Y'all can make the
> *data* for your particular *database* as provincial or global as you
> want, but let's not confuse that with the design and implementation of
> one PC plant DB *engine*.

        Rich
--
Plants for a Future: 7000 useful plants
Web:       http://www.pfaf.org/  or  http://www.comp.leeds.ac.uk/pfaf/
Main Site: Blagdon Cross, Ashwater, Beaworthy, Devon, EX21 5DF, England
           Tel: (+44 845) 458 4719
Email:     webmaster@pfaf.org (web related queries only)
PFAF electronic mailing list http://groups.yahoo.com/group/pfaf