Permaculture Database

[jedd <jedd@progsoc.org>]

 Hi Christophe,

 I approve of patterns (hey, who doesn't?) but I'm not sure how
 you intend to leverage them into a design - either from the back-end
 database design, or for the user-interface.

 I'm not even sure how you'd go about ER mapping for a system
 that could facilitate patterns being plugged into it - at least not
 in any meaningful way.

 Perhaps if you would elucidate on how 'making the pattern the
 central data entity' would actually work?  Specifically from a
 technology POV, and the various 'interactions between patterns'
 that you think the user would be provided / focussing on.


 Anyhoo, thoughts on specific bits of your very interesting post:


> one thing that i've noticed is that
> the central concern seems to be the database itself. as i am thinking
> more along the lines of a practical global permaculture web portal

 Yes, starting from the user interface perspective probably makes
 a fair bit of sense, but speaking for my own approach only I'm happy
 to do both bits concurrently - simply because I am equally bewildered
 as to how to engineer both the UI and the schema.  So I kind of
 see-saw between the two things, at the moment, and probably will
 continue to do so for a few years.

 I also suspect that it'd be about as hard to reach consensus on
 a user interface as on a schema, and since UI's are far less
 interesting to geeks than actual programming .. well, there's your
 explanation.

 Having said that, I'm very keen on seeing what kinds of things
 (via screen mock-ups) people would want in any kind of tracking
 system.


> we also have to think about the user base and how people are going to
> be comfortable both accessing and supplying data. how are permies now
> communicating? mostly in the flesh, or in forums and mailing lists.
> the wikis do not seem to have really taken off. 

 My assessment of the permy community is that a) the really smart
 guys with lots of knowledge are off actually doing things and would
 not find this kind of system useful or interesting but may, from an
 academic point of view, consider it useful for someone else to work
 on (and consequently may provide some interesting answers to some
 specific questions) - this is in keeping with highly skilled people
 in any area I guess.  b) most people don't really know how to
 work with mailing lists - I may be unwittingly reinforcing this
 assessment myself here - and my experience watching people on
 various Pc lists trying to get their heads around snipping, context,
 list management (the 'get me off this list please!' style messages)
 and extrapolating from this I am highly doubtful of the quality
 of data we can expect from your average punter.  c) there's an
 abundance of web resources in the forms of wikis, forums, lists,
 and so on - all managed very locally, occasionally regionally, and
 with little crossover between them  - new efforts are probably going
 to fail unless they're adopted by an existing (strong) group, as
 there's just no effective mechanism to get everyone 'on board'
 as it were.


> a straight non-structured wiki might be just a bit too
> loose for us to be able to do the kind of data-mining i'm thinking
> of.

 Just so.  I suspect we all have the ability to set up a wiki or a
 CMS in under an hour - but to what end?

 I've set my own up (using dekiwiki) but would never open that
 up to anyone else, as the data quality in there is of paramount
 importance to me.  Wiki/CMS just don't have the facilities to
 segregate and correlate user's data - they seem better at
 aggregating it down to the lowest common denominator.

 

> another way to frame the problem is to say that by having more people
> contributing simpler information we will gain more than by having
> fewer people laboring over more complex data entry, because the
> inherent fuzziness of the problem domain lends itself well to

 I'd have to disagree with you here.  My preference is for a system
 that can cope with as much detail as you want to throw at it (and
 of course, conversely, with a certain level of ambiguity).  But I'm
 wary about dealing with a multitude of simple information - I just
 don't see the value in that.  We already have that, arguably, with
 things like 'grow basil with tomato', and 'distance between swales
 increases as slope decreases', and so on.

 To take your example of things not growing along the west coast
 above portland (I'm guessing you're American, given your assumption
 that I know about your geography) I'd suggest that we don't want
 that broad knowledge, but that it's *even more* important that we
 had detailed knowledge here - changes in weather patterns, soil
 types, numbers of people affected, even the rated authority of
 those contributors, historical trends that might connect these
 observations, other bio entities that might be interacting, etc.

 I like the idea of a collaborative or shared-comment design area,
 and started working on such a system just after my PDC some
 years ago.  Unsurprisingly this never amounted to diddly, but
 the idea is still quite appealing.  Similarly the idea of tracking
 (as you say) 'a pile of timber being thrown out at ...' - another
 hybrid freecycle / trading-post / vendor recommendation style idea
 I've been pondering for a while too as it happens.


 From a technology POV :

 REST is nice, but not workable with an authentication system
 IMO.  It's also kind of pointless here.  We can provide an interface
 of some sort - that's relatively easy - and of course some number
 of links will be available to non-authenticated users.  But I really
 don't think interfacing through URL's is necessarily the best way
 for other systems to talk to us (nor do I think this is a big
 concern for some years anyway ;)

 Corollary - I'm not keen on making it 'very easy' for people to join
 in to the system, primarily because doing rollback of this kind of
 system is insanely harder than on your standard wiki.  My goal is
 to have a set of data that I can really trust, not that I can mostly
 trust (as any doubt savagely reduces the value of the whole).

 RoR would probably not scale to the size that we're talking about.
 I'd advocate PHP becase a) it's what I know, b) it will scale, and
 c) there's more people that know it.
 
 I don't like CC licences, but haven't thought far enough into
 the best way to approach the various nasty legal aspects.

 I also don't see the benefit of making everything PDF-able, but
 instead would just make the database syncable for anyone that
 wanted a copy for, as you say, off-line access.  Storage and CPU
 are cheap enough these days that it is (or soon will be) quite
 feasible to have a VM running on your laptop with the whole
 of wikipedia, f.e.


 cheers,
 Jedd.