pcplantdb

[Stephanie Gerson <sgerson@stanfordalumni.org>]

hello again folks,

I know my email was lengthy, but I was hoping to hear back from at least 
*someone*.  I have cut and pasted it below - would Love to know what you 
are thinking.  And once again, how to proceed?

Have a wonderful weekend,
*Stephanie

+++++++++

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


____________________________________________________________________