Permaculture Database

[jedd <jedd@progsoc.org>]

 Hi Paul,

 Ahh .. I'm partly envious, as I have a bit of forced time on my
 hands as I attempt to find my next contract.  Hence the looking-
 around for some coding project to keep me busy.  :)

 My code .. is marginal at this point.  I'm using CodeIgniter, a
 PHP framework, and I'm mostly just stretching the mental muscle
 as I do some learning.  At some point I'll crank up a trac db,
 publicly visible, and post some code, but .. well .. don't hold
 your breath on this one.

 I have a vague theme-capability working, though.  ;)

 PFAF - I think they're pretty free with who they share their data
 with - but I'm not sure how easy it would be to import it into
 a more formalised database.  I think there was some permy site
 that got a tie-in to the PFAF data (one of the guys on this list
 a while ago got some funding I think for such a pursuit../)

 Then there's the encyclopedia <sic> of life mob:
   http://www.eol.org/  

 But *they* are very much aiming at a 'page per species'.  I'd be
 aiming at something less grandiose and yet way more complex.
 I only want to track useful organisms - so that rules out 95% of
 the species on the planet - but I also want to separately track
 each of the sub-species, varieties, forms, etc.

 And beyond that, obviously, way more complexity.

 Btw, EOL's faq page talks about 'in the future' a lot, with regards
 functionality that is pending.  And nothing in there is written
 after mid-2008.  Similarly their press release page.  Their FAQ
 talks about releasing technology (they espouse the fact that they
 use free software - ruby, rails, php, mysql) but there is nowhere
 on the site to acquire their code, schema, or db content.  They
 talk about how they'll provide services 'at all levels' and are
 intending to become part of the semantic web - but no information
 is provided on non-HTML ways of interrogating their database.

 But enough about EOL.


 Anyway, I don't think that acquiring data will be the difficult
 bit - if it is really important we can work out ways of importing
 data from other sources - but my expectation of usage is that
 I'll go buy an Anzac variety peach tree, say, and then I'll put
 all the details I can find about that thing into the DB.  I don't
 really care if the DB doesn't know about some fruit bat species
 that exists in another country - that'll be for someone else to
 worry about (and maybe update the database with details on).


 I should say that up front, my design goals might not match
 yours, or indeed anyone else's.

 I set up a wiki of my own to record the history of my land, that
 is, what I planted, where I planted it, what was done to it over its
 life, including when/if it died and causal and contributory factors
 to success or failure.  But it's obviously hugely unwieldy, and does
 not offer any useful way of interconnecting entities - organic or
 otherwise - across times and locations.

 I considered trying to write a plug-in to my wiki/CMS (I am using
 deki, and it has much potential for mash-ups, plug-ins, etc) but
 quickly concluded that, ultimately, realistically, the scope of my
 plug-in would soon exceed the scope of a CMS or wiki by several
 orders of magnitude - it'd be easier to write my own CMS component,
 or drop one in, later on, rather than approach it from the other way.

 Anyhoo, my goals are quite simple :)

 I want to record the details of everything I do on my property, and
 that includes (but isn't limited to!) the following:
 o  weather/climate information
 o  all unique data about each organism I have or introduce
 o  lifespan of organisms
 o  harvest / production (quality & quantity)  of organisms
 o  interactions - positive & negative - between entities
 
 That's the (relatively) easy bit.  I decided that trying to modify
 this later would be pointless, and what I'd like to do in the
 mid-term would be to get some friends jotting their information
 in there too, so I need to abstract this out by just one level - and
 that will allow me to have multiple users, and multiple locations
 (with n:n relationships of course), and details about organisms
 (harvest, timings, etc) relative to location.  Adding in that
 indirection layer later would be near-impossible, hence I'm going
 through the pain right now of considering everything from a
 multi-user and multi-location perspective.

 I haven't even begun to contemplate ways of describing non-
 organic entities, or rather their attributes, influences, and
 requirements against other organic or non-organic entities.

 (Well, actually, I did start to ponder a way, using a fixed set of
 'affects' attributes - maybe a scale of 10 or 20 - with the middle
 being zero affect, negative being adverse, etc.  The relationship
 would thus have a quanta attached to it, and then just requires a
 descriptive aspect - such as 'shades'.  So something can shade
 something else, and this has an affect (including zero affect).
 This would allow a fair level of abstraction, and involves lots of
 tall thin tables (which is encouraging from a design POV) but
 the determination of affects, and the location/climate/soil/etc
 influences of how much that affect is, is where I get bogged down.)

 Heck, I can't even work out a way of managing the basic
 taxonomy - I've looked at tree hierarchies, but I think bio
 taxonomy breaks a lot of the requirements of most MPT(?)
 style libraries that plug in to an RDBMS.  I'm thinking of the
 gaps, the optional taxa, the handling of deprecated synonyms
 and so on.

 I'm currently pondering geographical information - looking at how
 I can define a location, what scale to use, how I can do sub-sites
 within a larger site, if that should be recursive or just have a limit
 of N levels, say.  Do I use sunset zones, USDA zones, require the
 user to enter some climate data to identify my own metric for
 comparing climates/zones, or allow all of the above.

 So, I would dearly love to see any of your surviving and
 non-crumpled ER diagrams if you have them around.


 Hmm .. after writing all that .. I'm wondering if it might be worth
 setting up a mini-wiki for us to, in the very short term, identify
 our respective intents - pseudo-page mockups say - and get an
 idea on whether we are, or at least could be, heading in roughly
 the same direction.  Note that I'm being *very* narrow with the
 intent of this repository - it'd be purely to discuss ideas on design
 approaches, schemas, etc.  There's be no mention of peach trees
 anywhere in the thing.  :)

 cheers,
 Jedd.