Skip to Content.
Sympa Menu

pcplantdb - [pcplantdb] proceeding, rants, and questions...

pcplantdb@lists.ibiblio.org

Subject: pcplantdb

List archive

Chronological Thread  
  • From: Stephanie Gerson <sgerson@stanfordalumni.org>
  • To: <pcplantdb@lists.ibiblio.org>
  • Subject: [pcplantdb] proceeding, rants, and questions...
  • Date: Mon, 09 Feb 2004 14:39:11 -0800

Hello everybody,

Wonderfully lively discussion. Of course, it is essential to discuss the
concept of guilds, guild-design, and their usefulness. I have a few
responses:

1. Someone mentioned having this tool offer “[documented] natural plant
communities” instead of guilds-as-recipes. This is an interesting idea.
In this way, the tool we propose would be quite similar to the Visual
Thesaurus (http://www.visualthesaurus.com/online/index.html) - parallel
to the manner in which the VT allows you to choose an initial word and
find its synonyms, a natural-plant-communities tool would allow users to
choose an initial plant and find its natural-plant-community. Displaying
natural-plant-communities (and not so-called guilds) would encourage
users to learn on their own about the communities, and how to weave
appropriate guilds from the information they learn (versus giving them
“guild recipes”). However I would have 2 concerns: what if a plant is
part of more than one natural-plant-community (would you be able to
specify “biomes,” and would this help)? And how would this help users
come up with novel and functional combinations of plants?

2. “I would want to look for all known relationships of (for example)
White Oak with various other plants.” Isn’t this what our proposed tool
would allow users to do? But instead of in a table, ideally represented
in a web-like visual interface (more resonant with the concept of
relationship itself)? Please visit the Visual Thesaurus (I know there
are flaws with it, but I find it a powerful tool to use as an example.)
Now, in the same way that users of the VT choose an initial word, users
of our proposed tool would choose an initial plant. Clicking on the
plant, for example the White Oak, would bring up all the plants that
White Oak has a “positive” relationship with (they would float around the

initial plant in the same way that synonyms in the VT float around the
original word). (Or, perhaps, “positive” relationship lines could be one

color and “negative” relationship lines could be another – analogous to

synonyms and antonyms in the VT.) And users could click on the
relationship line itself (the line between the original plant and any
plant it has a relationship with), and learn more about the relationship.
Certainly, relationships are complex and cannot so easily be divided into
“positive” and “negative,” so this clicking on the relationship line
would (in my opinion) be the most essential lesson here. Is this making
sense? What are the flaws with this proposal?

(Also, clicking on the relationship line would somewhat alleviate the
concern: “I think guilds can get in the way by overemphasizing a
particular scale of subgrouping (the guild level) in the design to the
extent that other levels of scale are not as available; such as the
relationship that only two different species might have on the smaller
scale and on the larger scale, viewing the relationships and
functionality of the system as a whole.” Of course, the tool could offer
different scales of guilds, allowing users to zoom in (for example, on
the relationship between two plants) and zoom out (for example, on the
relationship between the guild itself and the surrounding environment/
community). But this is quite complicated, and personally, I don’t find
a problem with choosing a particular scale (the plant-community itself)
to work with/represent – especially if users can zoom in on the
relationship between two different plants as mentioned above.)

3. “I also think that guild focused design has the potential to endorse a
particular grouping as being an infallible and superior implementation
to the point of stifling the creative exploration of what could lead to
even better systems.” Hopefully not. As I understand it, the tool would
allow for many possibilities (as users clicked on one or another plant
having a “positive” relationship with the original one chosen). Plus,
the more information about plants and their characteristics/relationships
with other plants is entered into the db, and the more the tool is used,
the more possibilities for plant relationships there would be…or couldn't
we design it this way?

4. Someone described guilds as “examples of patterns to look for and
work with locally, not recipes.” Yes indeed. So perhaps, could the tool
instead be theme-based instead of plant based? For example, instead of
working with specific plants, you work with specific plant
characteristics (fixes nitrogen, likes partial shade, shallow roots).
Along the lines of what Richard Archer wrote, “we would need to work
out why those plants were synergistic (or antagonistic) and use these
findings to hone the search for synergies.” Exactly. And therefore the
tool would be more of a guild-design-methodology tool than a guild-design
tool— helping users with the process of guild design rather than being a
make-your-own-guild tool. And this would perhaps alleviate the concern
that, as someone eloquently wrote, “guilds are a co-creationary *process*
, not a ‘thing’”? Does this idea make sense?

5. “The total complexity of the relationships within a typical guild is
staggering and can only be represented (or understood for that matter)
simplistically at best.” Agreed. Perhaps this tool could be starting
point for people, but ultimately they would have to pursue their own
research/practice…

6. I am interested in Chad’s Eden tool. How can we integrate our
proposed tool with Eden? Or, what might Eden need (if we were to build
off of Eden) in order to incorporate the wealth of information about
plant relationships, and make it useful and useable in helping people
design functional plant-communities?

I initially understood our intention as organizing information about
plant relationships in a useful and accessible tool, so that people could
use the tool to help guide them in the design of guilds/natural-plant-
community, and Permaculture practice in general. I veered towards GBI’s
and the Visual Thesaurus as a model because I find parallels between, on
the one hand, relationships between words in language and, on the other,
relationships between plants in natural-plant-communities. Furthermore,
I find a web-like interface to be ideal for mapping and representing
relationships (versus a table or dry text).

I understand Chad’s concern that “Guilds modeled after natural plant
communities are also highly bioregional and the translation from natural
plant community to guild is not usually obvious (and therefore not
algorithmic), further complicating an accurate software model.” However,
first of all, users could specify their bioregion (and the tool could be
designed to be bioregion-specific). Second of all, if the plants in the
db were stored with all the characteristics which have been mentioned
(i.e. pH requirements, root size, height, relationship with sun, etc.),
then wouldn’t an algorithm be possible? Yes, relationships are extremely
complex and contingent on many factors, but couldn’t we include such
factors into an algorithm that would recognize, for example, that plant X
which is short, needs shade, and needs a neutral pH would have a
“positive” relationship with plant Y which is taller, broad leaves (to
provide shade) and also needs a neutral pH, but would have a “negative”
relationship with plant Z that…? I am definitely oversimplifying, but
wouldn’t this be possible? (I ask out of curiosity, because I honestly
don’t know.)

Finally, someone asked, “Is a guild design tool really the number one
software <-> permaculture intersection on peoples lists?” This is a
critical question. What do people think?

Looking forward to more discussion…

peace
*Stephanie



+++++++++++++++
Stephanie Gerson
sgerson@stanfordalumni.org
(h) 505.758.2806
(c) 415.871.5683


____________________________________________________________________






Archive powered by MHonArc 2.6.24.

Top of Page