Skip to Content.
Sympa Menu

pcplantdb - Re: [pcplantdb] a few things...

pcplantdb@lists.ibiblio.org

Subject: pcplantdb

List archive

Chronological Thread  
  • From: Bear Kaufmann <bear@ursine-design.com>
  • To: john@eco-living.net, pcplantdb <pcplantdb@lists.ibiblio.org>
  • Subject: Re: [pcplantdb] a few things...
  • Date: Fri, 29 Jul 2005 20:03:51 -0700


This is not a response to a synthesis.
:-)

Congrats on getting a decent browser!
Please keep the 'ol IE/Mac browser around, as you may catch some
interesting bugs with it (browser compatibility testing).
Whenever Bear tweaks the web code, give it a once-over for appearance,
styles, layout, etc. with that IE/Mac browser and see if it chokes on
anything.
Yeah, good idea to keep me on my feet.

Meanwhile...
I am wondering if anyone else is wondering what happened to some of the
IMO most fundamental PERMACULTURE-CENTRIC aspects of PIW.

I am thinking at the moment of 'inputs' and 'outputs', e.g. what a plant
needs and what it provides.

Besides being most basic and useful for PC design purposes, this also
provides information that can be 'mined', correlated, etc. to determine
potential relationships.

As far as what I thought we were up to with this phase one of the project,
I thought the idea was to create a PERMACULTURE-CENTRIC plant database,
and IMO that means at the very least we must be able to search for,
return, add and edit PC-centric info such as 'inputs' and 'outputs'.

Since afaik info of this nature doesn't much exist as such in our startup
(PFAF) dataset, let's not forget to include it in the DB just because it's
not in our startup data. Let's consider what else of a PC-centric nature
also doesn't exist in our startup data and include that also.

In other words, I'm concerned that with so much initial data of a certain
meta-type, we are missing and/or forgetting to think about and implement
more PC-centric aspects that are not present in PFAF data or
functionality.

There is some info on 'inputs' and 'outputs' in PFAF data. However IMO
it's not easily recognizable as such, and I assume therefore not readily
searchable as such.

For example, how would I get a concise result set of plants that provide
fodder of a particular type, and/or for a particular animal?

How would I get a concise result set of plants that thrive in acidic
tropical soil conditions (considering this as an 'input')??
Good points John. Note also that were still working on a reasonable HTML front end for this, it'd be nice to get on to the rich client, but I think we still have a ways to make this good and functional.
So, on that note, and considering what is in the DB as it stands take a look at Chad's advanced search @ http://dev.permaculture.info/advanced.html
As a starting point, could we regroup these, or most of these into inputs-outputs?
As I see it:
Inputs:
Hardiness
Suitable Locations
Tolerates
Prefers

Outputs:
Fast growing Slow growing Fixes nitrogen Scented flowers Provides food for wildlife
Uses

I'm not sure where or if Habit can go some where. Though the Habit -> of -> Tree -> supports -> Vines, so we might be able to reinterpret some habits to those ends.

Looking at Suitable Locations...
It seems like we might want to set this up to go 2 ways.
Right now, there are values for the input side. For example plants that grow in heavy shade.
But this is also an output, some trees produce heavy shade. So if a user adds a tree that outputs heavy shade, one of the searches for plants would be those that need heavy shade.
How to represent this, especially in an HTML client is an interesting challenge. The user would want to find plants that handle heavy shade, but only Under the Tree. Some search values apply to the whole guild's environment (hardiness, unless we figure for the potential to create micro-climates), some only to a subsection heavy shade under tree, high pH under Pine Tree, etc.

I think as a start we can try to re-factor the advanced search into the inputs-outputs model.
Cheers,
Bear





Archive powered by MHonArc 2.6.24.

Top of Page