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: "Lawrence F. London, Jr." <lfl@intrex.net>
  • To: paul@heliosville.com, pcdb <pcdb@lists.ibiblio.org>
  • Subject: Re: [pcdb] some ideas for data modelling
  • Date: Sat, 31 Mar 2007 01:39:14 -0400

paul@heliosville.com wrote:

Hard to know where to begin but I'll throw out some random thoughts for what
its worth:

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.

This is pretty interesting and may well prove to be an important feature of
the database,
the ability of the software to display abstractions, speculative concepts,
quasi scientific
observations. Proven guilds could be listed and user-browsed with complete
information about
each entry displayed on demand. Can't you have a table field(?) for guilds that would be unique in that it would describe why a certain collection of organisms qualifies as a guild -
of course the system needs a good definition for guild for users unfamiliar
with the concept.
This gets deep.
A really comprehensive, broad spectrum dataset might acquire a huge amount of
useful information
about fauna, flora, microorganisms, climate, soil conditions, drainage, cultural likes and dislikes (calciphobe, water tolerant, aquatic, tolerates dry conditions, parasitic, symbiosis, nitrogen fixation, ability to make plant-available nutrients (mycorrhizal fungi). All these individual bits, properly tagged could become source data for the DB to use when searching for possible guild components, as per user query.

>or can it be done only through the
>>relationships and the memberships of its constituents?

What is "memberships of its constituents"?

> How much of that
>>interrelationship should be imbedded in data structure vs. narrative.

Some might be embedded in data structure as, for example, yield of a particular plant (squash) in a guild might be increased through more robust growth from nitrogen fixed by beans; conifers survive and prosper because of mycorrhizal fungi. Needs data about a plant should include such information as "requires", "can produce greater yield with <nutrient>" "can thrive in a guild that includes other organisms with attributes such as "provides shade", "conserves water", "is allelopathic", "provides living mulch and/or nutrients", "provides beneficial layer of detritus when it decomposes", attracts "beneficial organism x", repels predatory organism(s) x", "converts soil borne nutrient x to plant available nutrient x", etc.

What do you mean by "narrative". Random length ascii text field, i.e.
anecdotal evidence?

Well, guilds seem to be a new "category" of horticultural methodology. One opts to plant corn, bean & squash together instead of monocropping them. A value judgement by the farmer/gardener. Important when food on the table and/or income is at stake. Therefore giving guilds a high ranking position in the database is probably a good thing. The guild is still something of an unknown in that seasonal or long term yield using this cropping method can't be accurately predicted but may prove to be either equal to a monocrop scheme or may produce windfall bounties, better each year and positively affecting surrounding crops and soil quality. These are things serious farmers and gardeners will pay attention to. Just an idea in support of a prominent position for guilds in the DB.

good question. I'm inclined to still limit structural (i.e., searchable and
analysable) stuff to the rudimentary relationships ([corn] outputs
[sugars], [corn] outputs [structural support], [beans] benefit from
[structural support], [beans] provide [nitrogen], [squash] outputs [green
mulch], etc) and relegate history to the narrative.

What is "relegate history to the narrative"?

As I try to imagine how certain relationships, like the three sisters,
would be constructed, to facilitate the discovery of variations and new
guilds. What would be the relationship between corn and beans actually look
like? What is [structural support]? Is it an ojbect itself, under some sort
of 'random' functional group? Would [corn] really 'output' [structural
support]? or would we have 'support' in our finite list of relationships
verbs and say [corn] supports [climbers]? Is [nitrogen] an object under the
[chemicals] group? Or maybe we should just say [beans] benefit from [corn]
and [corn] benefits from [beans]. All these things are very open to
opinion, and we'd all have to develop a consistent view of all this.

structural support might be considered a plant attribute with the label output (transient but useful or required input for guild companion) as opposed to yield as in corn converted to likker or corn meal.

Required input (required for life) = water, air, light, soil, NPK &
micronutrients in certain minimum qualtities
Beneficial input (displays improved growth with) = growth medium (soil, minimum requirement; soil + cornstalk, better growth medium), extra plant available nitrogen fixed from the air by bacteria, well aerated soil, i.e. aerobic soil condition possibly brought about by dung beetles, earthworms, channels left by plant roots [some doing a better job than others) - also whould affect water and nutrient availability and provide habitat for various beneficial organisms, extra carbon dioxide

For each plant you would have
Inputs 1 & 2; 1 being "required for life", 2 being "will exhibit enhanced growth
with"

Yields harvest portion of the plant, i.e. reason it was planted in the first
place
and/or
Outputs not necessarily harvested portion of plant, transient (corn stalk, used by beans then it rots), incidental (helps build soil, aerates soil, specially good food for earthworms, and so on and on

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


hm. I see what you mean. I thought maybe you could weight the relevance of
a relationship, the same way you'd weight the strength of a relationship,

maybe weight it in terms of whether said relationship also can include a three way relationship involving a third organism, thus paving the way for discovery of a possible guild - this weight factor might be a useful tool in
uncovering hidden guild relationships between plants - i.e. weight #7 = high enough to warrant looking for guild possibilities - then search for other organisms with matching attributes/inputs-outputs to complete a trial guild connection.

but that seems a little baroque.

might be useful

I like your idea of incorporating something like those axes that Klinka and
Krajina suggest. For people coming from a traditional gardening background,
though, where the variables are framed in terms of light needs rather than
energy needs/tolerance versus moisture needs, it might be helpful to have
some sort of 'primer' on the website about rethinking plant needs.

gee, it's getting really complicated, isn't it?


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.


I think we are on the same wavelength, tonight for sure.

---
Lawrence London wrote:


Let's get started on this project. It needs a name. Maybe Permaculture
Relationships & Guilds. Or PCDB (assuming that flatfile, object-
oriented and relational databases are all considered _databases_).
Or .... Permapedia. PC Wiki/DB


I like PCDB, Permapedia, and PermaSphere, which someone mentioned a couple
months ago.

Of them, my favourite is PermaSphere.

Great stuff, glad someone latched onto that. Its my invention from years ago.
My permaculture website is called permasphere - here's the logo:
http://market-farming.com/images/spectrum.jpg
I've been throwing around ecolandtech also as an alternate label for what
permaculture
represents. I own permasphere.com and would be glad to donate it to this
project if it can be used.
These are also available:
permasphere.net
permasphere.org
permasphere.info
permasphere.biz
permasphere.us
permasphere.tv
permasphere.cc
permasphere.ws

With the project we're trying to undertake, I firmly believe that a
custom-designed RDB would serve our needs much better than a wiki. The wiki
creates some exciting possibilities, however. I think there's so much that
doesn't suit itself well to computer analysis, but would be lovely to know.
Like, how good do Chilean guavas actually taste? has anybody made some good
rosehip jelly? I don't know! So many options.

I'd step up to the plate and set up the ibiblio account, but I'm a bit busy
right now -- perhaps in a few weeks to a month, my workload will slow down
a bit.


I think that, if approved, users who submit a lot of data
should have the privilege to "own" their data; i.e. have limited
right to have the final say, within reason, over data revistions
or overwrites of their work


Good idea. An opportunity to make people take pride in their contributions
(and, as a corollary, make sure their domains are kept tidy), but with a
balance of power. Perhaps something as simple as access control on a page,
where admins have full control, and power-contributors have the right to
set a 'requires my approval before publishing' flag.

Great plan. How would you do this with an RDB; it seems native to wikis.

(originals should always be kept

definitely. I think this would be best served by a revision control system
like wikis and software development repositories have. Anybody have
experience writing an RCS?

--
Lawrence F. London, Jr.
Venaura Farm
lfl@intrex.net
http://market-farming.com
http://market-farming.com/venaurafarm
http://venaurafarm.blogspot.com/
http://www.ibiblio.org/ecolandtech





Archive powered by MHonArc 2.6.24.

Top of Page