Permaculture Database

[Paul Cereghino <paul.cereghino@comcast.net>]

Figure we may as well keep batting this text back and forth... I am 
seeing discrete topics emerge that could migrate to wiki space, but I'd 
like to keep working at a unifying core to this conceptual model.  Is 
this going somewhere.. what are the steps forward.  Are there whole 
alternative conceptual models we should think about?  Fundemental flaws 
in translating this conceptual model to a digital information 
architecture?!  Cases where this kind of conceptual architecture would 
break down?

How would you use the system to generate guilds?  I am imagining that 
the user would start with something.. like a chicken or an apple tree, 
and start wandering.. looking for a good relationship.  They'd grab that 
next object and put it in their "shopping cart", and then use their two 
objects to wander off looking for a new good relationship.  Climate is 
the external forcing -- the overlying constraint that drives the whole 
process.  Once you get a cluster of 2-5 objects, maybe you start 
grabbing only 1-3 objects to find your next guild member... using your 
intuition to seek out weaknesses in function.  This is a model of how I 
often approach design... a data structure should match a natural user 
process.  (makes me think of the Mollison exercise of random assembly.. 
ON TOP OF, INSIDE, NEXT TO, UNDERNEATH, BEFORE, AFTER...)

I've heard us talking about 3 types of nodes

objects - real things that have relationships with other things (maybe 
members of a phylogeny)
functional group taxonomies - hierarchys of traits that define the 
capacities of objects and relate then to other objects (nitrogen-fixers, 
bird eaters)
guilds - are user generated families of objects that have a story 
wrapping them together

the mess is held together by shared membership in functional groups, and 
through a finite set of object to object relationships - a finite set of 
ways in which two objects enhance or degrade other objects either 
directly or indirectly.

If you have one object, you can find other objects that share functional 
characteristics (other small fruit-bearing shrubs) or that are linked 
(potential pollinators for your fruit-bearing shrub).

>  
>
> > I like the nesting hierarchical taxonomy because of how it allows for 
> > navigation.  The idea of heritable attributes has me a little worrisome 
> > if we're using a phylogenetic hierarchy -- the genetic hierarchy is just 
> > structural... proposing how organisms evolved based on structural 
> > similarities, particularly genetically stable structures like flowers or 
> > bones.  From a permaculture perspective a apple tree would have more in 
> > common with a cornelian cherry than with a ground trailing bramble.  
> > Secondarily phylogenetic taxonomies change as taxonomists unravel genetics.
> >    
>
> hm, that's an interesting point; I never thought about it that way. I
> think that attribute inheritance would still work very well on a
> species->cultivar/hybrid node though, and perhaps even higher (e.g., all
> leguminosae would be tagged as nitrogen fixers at the family node).
>  
>
> > Membership of an object in a functional group could be a matter of 
> > debate.  It would be good to have that 'uncertainty' captured in the 
> > data set. 
> >    
>
> we could potentially have multiple parents of a node... thinking about
> the tangly relationships makes my brain start to smoke though :-) but...
> then again, I suppose that's how nature is: tangly.
>  
I am hoping that if many attributes are reduced to functional group 
taxonomies, and that these taxonomies are conceptually clean enough, we 
could get away with single parentage within the taxonomy, and then a 
many-to-many relationship between functinal group nodes and objects.  I 
have no idea how you do that... have an object pointing to any number of 
nodes at different levels within a functional hierarchy.

What I ment about uncertainty is that people disagree.  Even if you 
constrain data structure folks are going to have different annecdotal 
evidence, or be observing conflicting attributes because they are 
working in different systems, or (gasp..) someone might just be wrong.  
How do you work with this?

And there is the huge external driver of place.  The Nature Conservancy 
has done a fair job of describing bioregions in the US (only around 40 
or so).  But a global resource?!  Some things will remain constant.  
Other things wont.  I struggle with PFAF as anything other than a 
brainstorming tool since it is hard to know if some weird species that 
noone I know has ever grown will really grow in my spot.

>  
>
> > In this approach functional 'group membership' creates linkage between 
> > objects as well as allowing linkage to different levels of the 
> > taxonomy... objects float in space until the have membership in a 
> > functional group.  This way you could have several functional taxonomies 
> > to consider different commonly held attributes of groups of object.
> >    
>
> hm, and that way, 'Guilds' could be a root node in the hierarchy, and
> you could create a guild and add nodes under it, just as you'd add
> 'chicken' under 'herbivore' and 'insectivore'.
>
> (funny how the discussion always comes back to chickens and legumes.)
>  
Yep - many secrets in birds that cluck... the narrative of the 
guild/pattern node [Three sisters guild] would justify the inclusion of 
[corn] [beans] and [squash] and how they came together....  Now how 
would the object [three sisters guild] be searched and described.. what 
parameters would describe it? or can it be done only through the 
relationships and the memberships of its constituents?  How much of that 
interrelationship should be imbedded in data structure vs. narrative.

>  
>
> > Some form of automated linking would be great.  I suspect having to 
> > manually link objects through a defined relationship would be brutal and 
> > bog down the whole information gathering process, but it may be the only 
> > way.
> >    
>
> If all we concerned ourselves with at first was basic relationships,
> like the primary inputs and outputs (e.g., egg, poop, water), hopefully
> the database would grow more intricate as people join in and create new
> relationships. I think your comment about sources and sinks being
> objects in their own right is very sensible, and we should probably go
> with that. A source/sink table could be as simple as
>
> --------------------------------------
> | relationship                       |
> --------------------------------------
> | relationshipID primary int(10)     |
> | sourceID foreign int(10)           |
> | sinkID foreign int(10)             |
> --------------------------------------
>
>  
>
> > With organisms there are direct metabolic inputs and outputs as well as 
> > indirect benefits by association... I would propose a middle ground with 
> > a finite set of relationships that captures a good/bad, direct/indirect 
> > matrix and includes two kinds of outputs.
> >
> > [object] benefits from consuming [object]
> > [object] suffers from consuming [object]
> > [object] benefits from being adjacent [object]
> > [object] suffers from being adjacent [object]
> > [object] produces/yields [object]
> > [object] does [workobject]
> >    
>
> Yes! What a great idea! I was trying to think of something like that. I
> thought of using 'good/bad', but what's good and what's bad? In the case
> of an allelopath, you might hate it, but I might consider its herbicidal
> activity 'good' to keep some grass in my front yard in check. So
> 'benefit/suffer' is a better term. 
You'd have to have the relationships always be from the perspective of 
the first object... you would just use language to shift the 
description... the designer would have to take on the perspective of 
different objects as they were consulting the database for design 
inspiration...

> And we could expand that relationship
> set to include inputs and outputs, by adding
>
> [object] requires [object]
> [object] provides [object]
Now lets say you have [plant] and you create a relationship between 
[plant] and [water] and call it plant [requires] water... what have you 
achieved?!  Everytime you look for relationships to a water family 
object you'd connect to ALL plants!!



> I agree that relationships should be inherited, like in your next
> example:
>  
>
> > [fruiteater] benefits from consuming [fruit]
> > [fruiteater] benefits from being adjacent to [fruit-producing plant]
> > [bird] suffers from being adjacent to [birdeater]
> > All these are about chicken because chicken is a member of [bird] and 
> > [fruiteater].  And thus the chicken (and all fruit eating birds] starts 
> > to evolve in a way that links it to other objects... you jump to 
> > [fruit-producing plant] and start dialing in you 
> > climate/soil/light/hydrologic conditions...
> >    
>
> I'm thinking now that even things like light, soil, etc could be
> first-order objects, rather than attributes. Under the 'light' tree you
> could have 'full sun', 'partial shade', etc.
>  
A tree that likes full sun in my coastal rainforest may need filtered 
shade in california.  Shade tolerance is mediated by soil moisture.  I'd 
try to look at it more from the perspective of what the plant is 
experiencing... plants that don't like shade don't have adaptations for 
low energy environments.. they are intolerant of shade, which is 
independant on their water needs that may prevent them from being in sun 
under certain conditions... Some plants will fry if transplanted in sun, 
but if they are well established and you remove the canopy, they do fine 
(salal, red huckleberry)!  Again, perhaps a mediation of solar tolerance 
by establishment and soil moisture.  So when you talk about the 
environment as the factor, you are not talking about the experiences and 
capacities of the plant.  Some plants are intolerant of dry soil, so if 
you have trouble keeping your soils moist in the sun, you'd want to make 
sure they are adapted to low energy conditions, and pick you site well.  
What does saying a plant is adapted to partial shade mean to a plant... 
I may be making this complicated... but if you are trying to model you 
want your relationships to be clean and accurate or your start 
propagating error to where your model is useless.

There is some good work by Klinka and Krajina out of British Columbia.  
He defines three adaptation axes (might have been 4?)
1. preference for soil moisture regime that is bounded on one extreme by 
duration of flooding (low Redox), and on the other end by duration of 
drought (days w/o soil moisture).
2. preference for soil fertility regime (focussing first on increasing 
C:N ratio and finally lack of organic matter.)
3. preference for seasonal characteristics (winter cold tolerance)
He thought these where to strongest drivers in plant composition in 
natural systems and indicator species could be used to describe site 
conditions.

Then Grimes the English botanist and his life history strategies 
focussing on two adaptations
adaptation to stress (drought, anoxia, salinity, etc)
adaptation to disturbance (fire, flood, unstable substrate, browse, 
wind, trampling, etc.)

In these kinds of references we might find a critical set of adaptations 
that could cleanly describe plants.  Lots of the garden literature uses 
vague language that doens't really teach you about how the plant makes a 
living... I think that the "sunset garden book" snapshots can breed 
insensitive design, and I'd like to see a stab at really talking about 
plants as whole beings with a range of real physiological 
characteristics and adaptations..

> The database could be dumb about these things, but we would need the
> user interface (especially the search) to be intelligent about them. If
> that were the case, we would have to make the attribute nodes
> (soil-type, hardiness zones, etc) unmodifiable constants.
>  
From the plants perspective, soil type (I assume meaning texture) is 
secondary to biogeochemical cycling environment, moisture, and a 
tendency to go anaerobic (again getting nitpicky on selecting functional 
group trees.)

> You said that defining little tiny details as relationships would end up
> going crazy, and I think that has a lot of wisdom :-) We could certainly
> define complex relationships in a simple, flexible object/relationship
> system, but I agree that it would be better to simply put that in a
> wiki-style narrative. I like the fact that PFAF allows people to add
> comments, but I think it needs a bit more structure. Moderation would be
> valuable.
>
>  
>
> > In short I think we need to humble our data relationships to the level 
> > at which our human understanding can provide consistent accurate answers.
> >