Permaculture Database

[Paul d'Aoust <paul@heliosville.com>]

On Tue, 2007-27-03 at 09:46 -0700, Paul Cereghino wrote:
> Yea!! its moving again :)  Thanks Paul!

heh, glad to be of service.

> 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.

> 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.)

> 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. And we could expand that relationship
set to include inputs and outputs, by adding

[object] requires [object]
[object] provides [object]

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.

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.

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.

wow.

Paul d'Aoust
(I'm gonna hafta start using my last name if there's another Paul here)