pcdb@lists.ibiblio.org
Subject: Permaculture Database
List archive
- From: jedd <jedd@progsoc.org>
- To: pcdb <pcdb@lists.ibiblio.org>
- Subject: [pcdb] jedd's requirements
- Date: Fri, 30 Mar 2007 19:25:12 +1000
Some thoughts, very loosely grouped with minimal flow. I'm sure
we'll deal with it. I notice a few things below are starting to be
touched on elsewhere on the list
The phrase 'nesting hierarchical taxonomy' doesn't sit well with
my language centre. (Isn't there a tautology in there?) My take
on hierarchy (apart from a preference for the original religious
meaning) is that it isn't an appropriate concept to try to apply to
this kind of database. This stuff cries out for an rdb.
A taxonomy .. is unavoidable & implied, and will likely require
much administration.
I'm still not sure how the permaculturedb and plantdb's goals
differ -- though I use plants (below) as examples (I refused to
succumb to peer pressure and talk about chooks!) every item
in the landscape (as well as the non-physical items) need to have
a presence in the database. It seems to me that a plantdb would
necessarily be a subset of the pcdb. And/or having both implies
much duplication of effort.
----
On input, any reference to a month is highlighted - to the user,
and if forced, to a moderator.
There are strictly defined references to what a season means, f.e.
And they're aligned globally, so rather than starting on the
solstice/equinox (as they do in some countries) they start on the
first day of the month before each of those things, and ends on the
last day of the month after. Yes, that neatly aligns with where I
happen to live -- but that inherently reduce the benefits of same.
I'd also want to make measurements - weight, distance, volume, etc
location agnostic. I'd really prefer to make everything metric, as
imperial measurements of those things blows goats something chronic
(do we distinguish between US miles and gallons, as distinct from UK
miles and gallons, or indeed anyone else's takes on those 'standard'
measurements?). IOW, I'm down for some foresight.
I want weightings for various relationships -- and I see this as hard
to get, because it's going to be hard [for people] to give .. and that
will be because once someone sees a relationship is defined they
are unlikely to comment on it, particularly if it's one they agree
with .. whereas that's exactly where I'd want them to pipe up. For
example, mulberry and grape grow well together, or so the rumours go,
and doubtless many people believe that to be the case, some with and
some without first hand experience. I think there's probably a number
of weightings involved there, with the most important one being the
existence of first hand experience to vouch for the affect one org
has on a specific neighbour. We could have a weighting on how many
people *believe* in such an effect .. but it'd be of questionable
value, IMO. We'd definitely want a weighting on the level of the
effect, of course.
I'd want that weighting to be affected by, and affect, the weighting
of any comparative analysis between an unknown contributor and myself
when I start doing searches on relationships between two orgs - such
that someone with comparable soil (sandy loam, pH, organic content)
and climate (humidity, days > 30C & frosts per year, hours of sunlight
(latitude), elevation) and microclimate (aspect, exposure, proximity
to the sea, living canopy, human structures) got a higher weighting
than someone living in an entirely different environment.
----
Consider a particular plant. I'd want to know:
o Climate preference
o Climate tolerances
o Size (optimum)
o Size (variable based on climate)
o Soil preferences ... tolerances
o Water requirements ... tolerances
o Sun/shade requirements ... tolerances
o Functions
o Warnings
o Companions
- sliding scale, say -10 to +10
- textual caveats for any cited companions
- climates where certain companionships will or won't work
- obviously there's a conceptual 1:n relationship here
o Herbal / medicinal uses (perhaps a sub category of functions)
- recipes
- doses
- contraindications
o Food potential
- as above
(Union of those two:
- containers / materials that can and can't be used in the
preparation - discolouration warnings, spoilage, corrosion ...)
o Weed potential
- impact
- seasonal / microclimate / weather / soil / etc influences
- methods of control
o Pest potential
- impact
- seasonal / microclimate / weather / soil / etc influences
- methods of control
o Propagation methods
o Fertilisation requirements .. tolerances
o Varieties (links to other instances, with replication of the
common bits to this specific variety - this can get messy as you
want to distinguish between specific varieties that may have
very different medicinal properties but share pretty much every
other property - contributors will not update both sets of data,
guaranteed).
o Performance - different metrics and under different conditions
- comparison performance early, mid, late season
- correlation to weather for each year that perf data is provided
o Dimensions (and how they vary based upon the above)
o What it looks like (ie, pictures)
- up close
- just after germination (each week snapshots) for identification
- flowers
- each pic can contain links to information about climate,
fertiliser, timings, location, soil types, etc where it was
grown (obviously this would come out of a person's profile,
unless that person wasn't registered with the system (but still
wanted to add that information in) and/or deal with time-
dependency (an utter nightmare in db's) if that person's moved
since the picture was taken or took it at a site other than
their registered and annotated home site
o Yield potential under each permutation of the above
Now -- most of that information needs to be modifiable for my own
site based on microclimate and the various results from offering
it different amounts of water, sun, fertiliser, and different soil
types, different areas (microclimates) and different companions, etc.
I'd want another dimension to the data by being able to compare my
results (or predict same) based on other people's data - so I'd want
the system to be able to fuzzily compare my environs (specified
elsewhere in the db) with anyone else that's entered some data for
this particular plant, with it identifying microclimates and seasonal
timings, yearly weather variations, and so on.
The companion plantings obviously scale (once you're outside the
above context) to an n:n relationship - so you'd obviously want to
be able to identify both guild members and facilitators (between
plants that are themselves incompatible).
I haven't even considered starting to do up an E-R diagram for
any of this stuff -- that's some way off.
----
Usage of wikipedia (etc) -- recommended, as it aligns with my desire
to not reproduce (and maintain) related, detailed, but ultimately not
core information. It also nearly fits my requirement that all core
information be portable -- ie, that I can relatively easily sync 'the
database' with a local copy and then use that offline. A facility to
pull in all single-order links from the primary site would therefore
be desirable.
Jedd.
-
[pcdb] jedd's requirements,
jedd, 03/30/2007
-
Re: [pcdb] jedd's requirements,
Lonnie Brown, 03/30/2007
-
Re: [pcdb] jedd's requirements,
jedd, 03/30/2007
-
Re: [pcdb] jedd's requirements,
Lawrence F. London, Jr., 03/30/2007
-
Re: [pcdb] jedd's requirements,
jedd, 03/30/2007
-
Re: [pcdb] jedd's requirements,
Lawrence F. London, Jr., 03/31/2007
-
Re: [pcdb] jedd's requirements,
jedd, 03/31/2007
- Re: [pcdb] jedd's requirements, Paul d'Aoust, 03/31/2007
- Re: [pcdb] jedd's requirements, Paul d'Aoust, 03/31/2007
-
Re: [pcdb] jedd's requirements,
jedd, 03/31/2007
-
Re: [pcdb] jedd's requirements,
Lawrence F. London, Jr., 03/31/2007
-
Re: [pcdb] jedd's requirements,
jedd, 03/30/2007
-
Re: [pcdb] jedd's requirements,
Lonnie Brown, 03/30/2007
- Re: [pcdb] jedd's requirements, jedd, 03/30/2007
-
Re: [pcdb] jedd's requirements,
Lawrence F. London, Jr., 03/30/2007
-
Re: [pcdb] jedd's requirements,
jedd, 03/30/2007
-
Re: [pcdb] jedd's requirements,
Lonnie Brown, 03/30/2007
Archive powered by MHonArc 2.6.24.