Skip to Content.
Sympa Menu

pcdb - Re: [pcdb] complexity, patterns and permahub

pcdb@lists.ibiblio.org

Subject: Permaculture Database

List archive

Chronological Thread  
  • From: jedd <jedd@progsoc.org>
  • To: Permaculture Database <pcdb@lists.ibiblio.org>
  • Subject: Re: [pcdb] complexity, patterns and permahub
  • Date: Mon, 18 May 2009 15:09:51 +0100

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.






Archive powered by MHonArc 2.6.24.

Top of Page