Permaculture Database

[Paul d'Aoust <paul@heliosville.com>]

Personally, I wanted to get into this game because I liked PFAF, but
thought its information could be more searchable -- for instance, we
could put constraints (e.g., tolerates only two hours of direct sun,
loves alkaline soil, and is hardy to USDA zone 6) into our search and
come up with a lot of neat stuff. I appreciate what Paul C is saying
about the complexity of ecosystem dynamics, and the difficulty (or
rather, near-impossibility) of modelling these dynamics successfully,
but part of me thinks, 'well, if it's that complex, will anybody be able
to use it?' We could certainly try to hide all that complexity, but I,
for one, wouldn't know where to begin, and I think it's important that
the system is easy to grok, in case we all lose interest and a new team
of developers comes along.

However, after looking through Paul C's study, I can see what he's
talking about. How on earth do you delve into modelling things like
overlapping and/or nested areas and then describe where plants are on
top of that? But whether you can or can't, it might be important anyway!

The way I see it, we can manage this complexity in three ways (in
increasing order of complexity):

     1. Ignore the issue, and create a simple plant/animal/tool database
        (an uber-PFAF) that doesn't live up to our original dream but is
        still quite useful. 
     2. Allow the finer bits of complexity to live in the comments,
        articles, and so forth, rather than in the data structure. The
        advantage to this is that it's extremely human-parsable; we can
        all understand a paragraph that points out subtleties of
        cultivation of a certain plant. The disadvantage is that the
        reader would have to do more legwork when they're trying to
        figure out connections. 
     3. Figure out some very clever non-linear model for modelling as
        much information as possible. This would allow the software to
        find much more new relationships automatically as the system
        catalogues more and more data. The three disadvantages I can see
        are that (1) it will take some very clever people to create the
        architecture, (2) there may be a lot of false-positives in all
        the relationships the system discovers, and (3) it may
        discourage people from contributing if they have to enter a lot
        of information. (I understand, though, that people could enter
        as much or as little information as they have.)

> Agreed.  I feel that I'm missing something very important about 
>  the subject, and yet I can't work out why (let alone what).  It's
>  not a hugely complex construct, after all.

I think that my biggest frustration with it is that I can model a
relationship between two entities, and I can model a set of attributes
for one entity, but I can't model a weighted relationship between two
entities or between an entity and its attribute without getting into
ridiculously baroque tangles of triplets, the structure of which I
couldn't even begin to imagine right now. As far as I understand, in
RDBMS terms it'd be like having two or three junction tables for one
simple n:n relationship.

> A fortnight ago I went over to FOSDEM [1] and by one of those
>  weird coincidences, on the Friday night before it kicked off, I was
>  in a pub having a yak with one of the guys who was there to do
>  a doing a presentation [2] on SPARQL, RDF and tying in with things
>  like Nepomuk.

Oh, so you do open-source stuff, eh? That's kinda cool; do you do it
professionally (e.g., with Mandriva or some other company), or is it a
hobby like it is for most of us? (I don't do open-source work myself --
although I develop websites with open-source apps -- but that's because
I do work-for-hire rather than my own stuff.)

> It might have been the 11% beer, but I started to 'get it' .. though
>  I really can't work out how it could be applied to the types of
>  problems that we('re going to) have.

That's nice; I'm glad to see that you don't see how it's applicable
either. However, I will say this: we should probably think about
incorporating very simple RDF stuff in order to make this resource
useful for the 'semantic web'. I think this could be as simple as
exposing basic relationships and attributes as a 'dumbed-down' version
of the more robust relationships hidden in the system. For instance, we
could include RDF triplets that say 'chicken likes willow' but not
'seventeen people have said that chicken loves willow and four people
have said that they don't seem to be interested in it at all'.

> Matt - do you have access to the archives?  There's not exactly
>  a *wealth* of background info from this list - a fairly torpid
>  and uninspiring sequence of ponderings, I'd imagine, were I
>  being totally candid.  ;) 

Heh, I thought the debate was pretty exciting.

> The 2 minute summary of my intent is to create a system that will
>  let me record activity / productivity of different elements within an
>  environment - and I thought I may as well add the extra dimension
>  up front to allow others to contribute data about their own
>  experiences.  At the moment it's a plan in my head and a few pages
>  scrawled into various notebooks.
> 
>  Obviously other people have substantively different end-games.

Yes, but they might not be entirely incompatible. As you probably know
from working with KDE, we create fictional users with specific goals,
and run them through our dream system in usage scenarios. It might turn
out that we need to accommodate a few end-games to make it useful.

Here's something we might want to try: Each of us with an idea for a
model can go to the drawing-board, develop the model (in idea-space, not
actual coding), and then explain to the group what advantages and
disadvantages this model would have. We could even model a few things (a
guild, a homestead, a chicken, and a few plant species, for example) and
show what sort of things could be done with those objects within our
system.

How does that sound to you guys? Anybody bored and not working? (ha! I
wish!)

Paul d'Aoust