Skip to Content.
Sympa Menu

pcdb - Re: [pcdb] some ideas for data modelling

pcdb@lists.ibiblio.org

Subject: Permaculture Database

List archive

Chronological Thread  
  • From: Paul Cereghino <paul.cereghino@comcast.net>
  • To: pcdb <pcdb@lists.ibiblio.org>
  • Subject: Re: [pcdb] some ideas for data modelling
  • Date: Thu, 29 Mar 2007 23:11:39 -0700

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.





Archive powered by MHonArc 2.6.24.

Top of Page