Skip to Content.
Sympa Menu

permaculture - Re: Interactive Projects/information/guilds database

permaculture@lists.ibiblio.org

Subject: permaculture

List archive

Chronological Thread  
  • From: Richard Morris <webmaster@pfaf.org>
  • To: permaculture <permaculture@franklin.oit.unc.edu>, pfaf_developers <pfaf_developers@yahoogroups.com>, Ken Fern <ken.fern@lineone.net>
  • Subject: Re: Interactive Projects/information/guilds database
  • Date: Sat, 22 Dec 2001 19:50:08 +0000


> 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





Archive powered by MHonArc 2.6.24.

Top of Page