Permaculture Database

[christophe mckeon gonzalez de leon <chromatophore@gmail.com>]

hi,

thanks a lot for the feedback. was beginning to think
i hadn't said anything worth responding to.

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

ok, so very broadly i'll try to sketch out what i'm thinking of.
i'll preface tentative entities with a ~ in the rest of my reply.
sometimes i'll be thinking/talking more in terms of what the user is
experiencing, than actual DB rows, because i am still trying to design
at a high level, but i think you'll see that what i have in mind will
easily map to a DB.

a ~pattern would be user provided media and text at
heart, but it would also know about (have lists of) species, and materials.
it could allow for alternative entries for specific
materials/species, so that we do not have a proliferation
of similar patterns.

patterns could be referenced by other patterns directly,
as parent, child, or sibling. this is something a user could (optionally)
specify when writing or editing a pattern, and would allow people to
set up pattern hierarchies a la christopher alexander.

another kind of relationship could be user specified.
i'm not yet sure how or in what context a user would do this,
but it would amount to a kind of ~pattern_resonance in which
a user can comment on, rate, show pictures, etc, of how pattern X
worked in conjunction with pattern Y. this would be a
richer kind of association then the familial ones above.

other kinds of pattern relationships could be inferred by
the system on the fly. in the case of guilds, if a user is interested
in using one, the system might suggest a few others that might fit in well.
the procedure for working this out could be as simple as looking for
common species, or might have some additional smarts built in which
i haven't thought about too much. one idea could be suggesting
other successful patterns based on the user's location. this
could be equally useful for guilds and building patterns.
if patterns are user taggable, then tag clouds of patterns
could be generated, etc...

~sites would be related to ~users, ~institutions, and ~events
but most importantly ~designs. sites could have fields like
soil type, and pH. how to deal w/ microclimates and differences
within a site and whether it is worth doing, i have not tackled yet.

one step up from patterns would be the ~design.
a design would again, have user media and text at heart,
like the drawings ideas and photos they worked on.
users also list patterns used in the design.
doing so should be exceedingly easy, via a set of pulldowns
or something. if they want to use a pattern not already in the system,
creating it (or a stub), in place, should also be easy.
a design will be associated with a physical ~site.

as their site develops over time, in their site design's diary
and ~diary_entries, users can comment on particular patterns and how
they are working out.
the diary entries would again have images and text, but also a way to rate the
efficacy quantitatively (clicking on a star or two) of specific patterns, or
even species within those patterns.

diary entries will make it easy for users to comment on patterns they are 
using
in their design by pre-populating the entry with the appropriate
fields/inputs appropriate for each pattern. diary entries could also
allow for observations of species, weather, etc which were not necessarily
part of the design or patterns being used. so an entry might mention
that there were many hoverflies that week via something like an
~observed_species entry.

there would be all sorts of other entities, like resources, institutions,
events, howto's (like on www.instructables.com), articles, blog posts, etc..
but just from the ones i have outlined above one could track, for example:

  how a ~species, ~material, or ~pattern is doing vis a vis
    time (from ~diary_entry.timestamp), geocoded location (from
~site), weather (from ~site.location
    and maybe ~diary_entry.timestamp via weather API), user data, soil
type & pH (from ~site),
    user relationships as tracked by groups or messages, combinations
of the above, you name it
  this kind of searching could also be done visually via google maps

so not only is there IMO some quite useful information to be mined
from the DB but on a human level there is a great deal of related
media for people to just directly learn from. where i think it might
get really interesting is when human readable text is searched alongside
more machine oriented data.

>  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

i agree with that, there will of course be concurrent model
design if maybe vague at first, what i should have said was
interface/experience *centric* design. if only to clarify exactly
what we actually want to build and how we will get people on board.

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

consensus would be great but as you say unlikely.
i'm interested in just having people throw around
ideas, and then if people start building things alone
or in groups, then everybody wins. there's also nothing
wrong with several projects addressing different issues/
niches but cooperating to share data for example.

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

i would hope that these people would contribute some
knowledge to the more pedagogic aspects of a permy
site and so find it useful as a teaching tool rather than
a learning tool, but maybe i'm expecting too much.

i do think that even the smartypants might be interested
in using the more social aspects of the site, but also things
like the 'performance' of certain plant combinations over
time and by location might interest them, even if not as
detailed as they would like.

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

that's precisely why keeping the individual 'data entry' tasks as
simple/friendly
as possible is key. that does not mean that collectively the data is 
worthless,
quite the contrary. i'm a big fan of hive intelligence.

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

yep that's the hard part. the only real solution to which
is making the site so fantastic from the user perspective,
that it becomes something of a no-brainer to get on board.
so it should be easier to make notes on the site in the
design diaries then doing so on paper because all the patterns
used are there waiting for commentary for instance, and
more worthwhile because of feedback in diary comments
from other people.

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

agree on this and everything else you said about canned goods

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

i don't think we are completely disagreeing. if the system could only
capture such simple relationships as in your examples then, i think the
site might still be useful as a kind of online reference, but that's certainly
not what i have in mind.

you'll be able to do the kind of data analysis i described above with
"how a ~species, ~material, or ~pattern...". the data model is simple
and modeled at the user mental model level, but i think rich enough to
yield quite useful information, while to the user the data entry feels
more like blogging, writing a diary, and sharing with friend.

>  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).

nope, i'm french/mexican (well mexican is technically american) but at
the moment living on the west coast of the US so that's the first thing
that came to mind :)

>  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,
>  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 think that if you ask for too much data from the user you'll
be building a database oriented academic style site, where few
people input high quality, highly detailed, regularly submitted data.
i'm sure that's a valuable thing to do, it's just not what i personally
want to build.

now that i thought a bit more about it, and i hope made it a
bit clearer (to myself included), are there kinds of knowledge
that my tentative model would not be able to handle or be made to
handle in some streamlined user-friendly way?

could you expand on just what you mean by historical trends, and other
bio-entities, and what kind of information you would like to be able
to get about these?

to take one of your examples above, changes in weather.
people's ~sites could be tracked weekly using something like the
yahoo weather API (i don't know how international this is?).
they could upon logging on, have a weather widget showing them their
principal site's weather. they could look at weather history, their
design diaries might also have automated weather entries, etc.
on top of that anybody could access the DB to do whatever deeper
searching they have in mind. in this case, ideally, the only
thing the user need do is supply an initial location. i've
never worked with the weather APIs so maybe they are not
reliable enough for this, but even then, weather could
just become part of diary entries.

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

i had initially thought this might be a good idea, but it's probably too
ambitious/complex. i'm thinking people will be designing on paper
most of the time anyway, possibly with their teacher or more
experienced mentor, and on site, not in front of the computer.
would that be a correct assumption?

so, i'm now thinking, that there can be ~designs associated
with ~sites, which have text, media (like scanned paper designs),
comments + diary as outlined above, but not so much tools for
collaboratively doing the design online.

granted it would certainly be interesting, but the extra complexity i think
would have to be pretty solidly justified before work began. in any
case, it could be added at a later date, given demand/site adoption/geek 
factor.

>  From a technology POV :
>
>  REST is nice, but ...

i think REST is great. in general the simpler a system can be the better
in my book. it's also effectively a free lunch with rails :)

>  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).

my first thought is, if you look at wiserearth, they seem to
be running just fine, and the sign up procedure was pretty straight forward.
if we want to get users on board, we must be prepared to deal with
some deviants,
or else the bottleneck becomes signup, and the thing'll stall before
it gets off the ground.

on the other hand, it would be nice to be able to cut some complexity out of 
the
code by tightening entry. one option is to have a pretty strong authorization
system so that users can still easily join up and start adding certain kinds 
of
content in a controlled way, but only be granted full privileges with the
passage of time and some kind of trust scheme. best of both worlds?

what did you have in mind?

>  RoR would probably not scale to the size that we're talking about.

uh oh, that's dangerous territory :)
i'd have to say, of course it'll scale, we are talking about a
site that'll have way less traffic than even medium sized RoR sites today.

even so there are other issues, the most important
being programmer time and complexity of code,
both of which RoR reduce drastically.

>  I'd advocate PHP becase a) it's what I know, b) it will scale, and
>  c) there's more people that know it.

this will be something to work out. i think it will largely
depend on who is building what with whom and how much time they are
willing to put in.

>  I don't like CC licences, but haven't thought far enough into
>  the best way to approach the various nasty legal aspects.

as long as the information is protected from being
owned by any one person or group it doesn't matter
what the license is. maybe the gnu free doc license would
do it. what do you find objectionable about CC?

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

i was just living in uruguay for about a year. in uruguay many people
don't have computers and use internet cafes. when i wanted a tech book
there, i would get it off p2p and have it printed locally, because
the prices were much higher than in the 'first world' but of course
wages were much lower. i'm sure i wasn't the only one doing that.
if people are collaborating to write potentially valuable & free
information, then having it be easily printable in places like that
would be very useful. that doesn't preclude also making the DB syncable.

that brings to mind a pretty big question, what to do about i18n??

thanks again for the feedback, i had quite a few ideas just
from thinking about your points/questions,
_c