permaculture

[Richard Morris <webmaster@pfaf.org>]

> Subject: Re: Interactive Projects/information/guilds database
> From: mIEKAL aND <dtv@mwt.net>
> Date: Fri, 21 Dec 2001 12:04:35 -0600
> 
> I just found this note from a few days ago.  I am really interested in 
> getting
> something mocked up in the very least because I think we will have an 
> intern or 2 by
> the end of march & it is a good time for them to do data entry before the 
> season kicks
> in..  (this is wisconsin)  ..
> 
> & one thing Ive been wondering about, is would it be possible for us in the 
> end to
> design more of a master database strategy that can access any of these 
> other databases
> such as pfaf or the ethnobotany database & import info from them as the 
> result of a
> search?

One good example of this is the gatherer 
        http://www.Kippewa-Gardens.com/cgi-bin/Gatherer.pl
it searches many of the big plant databases and combines the results
of all in one very big web page. Very simple to implement, and
has a good selection of info sources. Might lack a bit on user
interface side but it does its job.

> & what was decided about a separate list?
> 
> mIEKAL
> 
> seems to be one of the shortcomings of list communities that it is easy to 
> have ideas
> & toss them around...  another matter to know how to act.

Yes indeed, one of the big problems here is design of the user
community. What I guess will be needed is one or two people to hold the
thing together, maintain the primary code and data sources and
moderate the list discussions to keep them on target.

The way things seemed to have worked with many of the big 
openSource projects (linux/perl/...) is one person had been mainly 
responsible for version 0.1. When the core code is written
then its time for bug checkers and feature adders to join in and
take things to version 1.0. The fun really starts around version 3:
the first major rewrite, by that time the should be a committed
enough community to have a real good argument!

Maybe its worth going to sourceForge this seems to be the central
focus of much opensource development and much of the structures
needed to run the project are ready built in.

My mind recalls some stuff I picked up recently on a teacher
training course. There are four stages in a group dynamic
        forming - just building relationships
        storming - heated discussion about everything
        norming - arriving at a common objectives
        performing - getting on with it.

We probably still in the forming stage here, maybe its time
to come up with some solid structures so that we can have
something to storm about.

As a help to any on these lists, I'm happy to let people have the
pfaf dataset (and code if they are mad enough!). I'm sure we can
workout something in licence terms later. 

> From: "Lawrence F. London, Jr." <lflondon@mindspring.com>
> Date: Fri, 21 Dec 2001 13:53:37 -0500
>
> We need a DB oriented toward North America and those in Europe need
> their own. I plan to contribute to the North American DB effort. I
> think we need to program our own DB's on our respective servers, using
> whatever DB platform we choose (PHP/MySQL for me), and link them all
> together with a common front end of some sort; then link all this to
> PFAF and other external DB's. Seems this is all possible.

One point: its a good idea to have a system which can work online
and offline. It is a pain to have to log onto the internet every
time you need to search for a plant. PHP/MySQL might do this job nicely.
 
> Those wanting to help with the PFAF DB have a separate list for that
> and we will have our own two (more if necessary) for ours. I feel that
> all aspects of ours should be free to the public (open source, if you
> like that label); this would include data, DB software code, all
> scripts and html code. At any rate, everything _I_do will be free.
> Of course, any of use can get grants and donations to help us get the
> work done.

> From: "Elijah Smith" <elijah@hilobay.com>
> Date: Fri, 21 Dec 2001 10:23:20 -1000
> X-Message-Number: 4
> 
> I think we're all sorta busy til January - I know I am - having those
> mailing lists set up will be great, though.
> 
> mEIKAL, in response to your comments about getting something up and interns
> entering data - my concern is this (and this is sorta something John said
> earlier):
> 
>  Without getting a clear idea of all the data we'll want to track, and how
> it's organized, it will be almost as big a deal to apply "fixes" to the data
> down the road as it will be to enter it in the first place.  An example:
> say, for instance, that a big part of the database has to do with plants :).
> Say, we define a plant as having:
> 
>  one or more common names
>  a latin name (plus variations, synonyms, etc)
>  annual or perrenial
>  hardiness zone
>  comments
> 
>  Ok, your busy interns get to work and enter 500 records.  Then, someone
> says something that makes us realize we need to enter what sort of plant
> this is: groundcover, bush, small tree, big tree, vine, etc.  That means 500
> records need to be individually revisited and updated... which is a lot
> slower than involving that data entry in the initial go-through.  And that's
> a simple example.  I've seen much, much worse... and it's no fun for anyone.
> 
>  That's why design is as big a deal with databases as it in permaculture -
> if you just get a bunch of interns out there, digging swales, installing
> ponds, and planting trees, you might not get a terribly functional system.
> 
>  So I'd like to push for spending January, at least, defining the major uses
> of this system, what it does, how it operates, etc.  Maybe at that point we
> could "version" it out - and version 1 could be just the plant area, and we
> could pin the data structure down, and have a simple data input screen by
> the end of March when your interns arrive.  Or something like that?  Anyone
> else?

I disagree a bit here. If you look at all the coding books they
are very heavy on design first, but if you actually go talk to the
coders it quite another story. Get something quick and dirty running
learn by your mistakes, improve, make more mistakes, redesign, go back
to the idea you first though of, etc. Getting some data in early will
be good to get some idea of what's needed. 

> From: "Lawrence F. London, Jr." <lflondon@mindspring.com>
> Date: Fri, 21 Dec 2001 16:03:47 -0500
> 
> pcplantdb@  general
> pcplantdb-tech@ technical
> pcplantdb-data@ information

cool.

> > Without getting a clear idea of all the data we'll want to track, and how
> >it's organized, it will be almost as big a deal to apply "fixes" to the 
> >data
> >down the road as it will be to enter it in the first place.

True, contradicting what I just said earlier.

OK some thoughts on the data structure:

actually before looking at this its well worth having a look at all the
other databases out there, there are a supriseing number out there.
I've a fair few links to other sites see
        http://www.comp.leeds.ac.uk/pfaf/Links_4.html

Meta-data: (about the contributor)
        First Entry:
                Person (probably linked to a contributors table)
                Date (submitted, accepted)
                Notes (what still needs doing)
        Modifications:
                Person
                Date
                Notes (what was changed)
        Editors:
        Data checkers:

might want to note in text what was changed by who.

Plant Data - data can be entered at all levels:
        Often there are common characteristics common to
        all plants in a particular genera/family
        and also particular cultivars will have differences
        from the main species.

Botanical name:
        Genus
        Epitaph
        Sub. species
        Variety
        Author (allow for multiple names one field for each)
different fields for each bit of name will make somethings easier,
might be possible to automatically combine into another field.
I've had a few problems parsing the Author fields.

Each synonym should also have above data.

A feature should allow for the differences in gender endings
on the plant names and these can be rather inconsistent.

Common names:
        Name
        Location name in use

might want to get the good name dataset from 
        http://metalab.unc.edu/herbmed/database.html
plenty of other places to pinch names from (ask me for details
later).

General Text description about the plant. A fairly informal 
description about the plant. Useful as the key attention grabber
about the plant, go to be short to the point attention grabbing.
Will appear at the top of page.

Apple:
        One of the most useful fruit bearing trees around.
It grows all over the northern hemisphere. The fruits are delicious
and very nutritious. There are hundred of cultivars of the plants.

Cultural Info about the plant:
        Apples have a long history in british folk lore, the
practice of wassaling still carries on today. ....

Geographical range:
        Got to be as tight as possible, maybe counties in UK,
states in US (or smaller).
Should specify whether its native to each area or introduced. Could
have lots of fun with the user interface to this bit so you could 
draw a map and click on it to add those areas. 
        http://www.ibiblio.org/pfaf/D_area.html

Hazards:
        Hazards to health
        Invasive species, noxious weeds, controlled plants.
        Plants particularly noted for pest carrying.
        References to official documentation.

Life-span or life cycle
        Time to first fruiting
        Max age
        
Height and Width
        max and min for full grown plants. Some indication as to
how long it takes to reach these.

Hardiness
        The hardiness zones plant grows in. Maybe want to specify
a range of zones for these. Of more use to US people than rest 
of world. Might want some more useful info such as conditions
in which the plant can survive (min temp), 
and conditions necessary for it to bare fruit (length of growing
season).

General growing conditions:
        (for all of these will need to indicate if data not
        available N/A)
        Ph ranges (or very acid, acid, normal, base, very alkaline)
        Soil types (in the text fields we have about 50 different
                soil type listed. See
        http://www.ibiblio.org/pfaf/D_canned.html#SOIL
        Shade tolerance
        Wind tolerance
        Drought tolerance

Noted Pest & Diseases:

Habitats:
        Another tricky one lots of possible habitats:
        http://www.ibiblio.org/pfaf/D_canned.html#HABIT

Cultivation and propagation:
        Quite a few sub categories. #include <gardenerinput.h>
        
Edible uses:
        edible part
        use
        yield (we completely missed this one!)
        notes
        (we mixed up the part and the use in the same field)
        See:
        http://www.ibiblio.org/pfaf/D_edib.html
        for the categories we go and the ones we missed. 
        The ethnobotany database has a very good table of plant uses.

Composition:
        Vitamins, Carbohydrates etc.

Medicinal Use:
        Scientific name and common language description of conditions
        http://www.ibiblio.org/pfaf/D_med.html
        we are week on treatment, which is being rectified by our
        herb factsheets.

Other uses:
        Quite a tricky one as the uses are so diverse and two different
        names can be used for same use.
        http://www.ibiblio.org/pfaf/D_other.html
        Should be easy to add a new use. Might want some way to
        link the use to other related uses.

Phew, I think I've run out of breath!

        Hope your solstices were cool

                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