pcplantdb

[Chad Knepp <pyg@galatea.org>]

Richard Morris writes:
 > I just had a phone conversation with Jim about this.
 > 
 > He asked a lot of technical questions about how
 > we would actually implement things, particarly how
 > the communication between front end and server,
 > how we would add the guild type information to
 > existing datasets. How we would stop graffiti
 > and editorial issues.
 > 
 > General feeling is that we need to really do a lot
 > more thrashing out of the details of it all. Whats
 > the database schema? Whats the communication format
 > between server and front end? What precisely do
 > we want for the front end?
 > 
 > On a related note I see ibiblio now have a WikiInfo
 > fork of Wikipedia. If we could link with that
 > it could give us much greater exposure.
 > 
 >      ttfn
 > 
 >              Rich

I've spent a lot of time thinking about the questions that Jim is
asking.  Most of these haven't been discussed on the list, and the way
that I would proceed on my own may or may not be our group consensus.
I haven't prioritized discussing these things until a real (funded or
otherwise) development team forms.

Here are some thing I've thought about.  

Collaboration is the most important thing to do right.  Communication
betweem the front/back end is not as complicated as is communication
between collaborators.  The reasons wikis don't work for us, is that
they don't scale to the complexity of our information, and they don't
work well even for themselves because doing any kind of editing with a
browser based inteface is a serious drag.  We need to create either
fabulous (and specialized) editors or create a mechanism for editing
that works well with existing products (ie so I can use emacs and you
can use Word^H^H^H^Hvi).

Graffitti and editorial issues are REAL issues.  I have a lot of
thoughts and two different possibilities that I remain divided on.
Briefly: Moderation can be done well.  Slashdot is a fabulous example
of moderation done right.  I often read the postings at a high level
of filtering (level 5, only highly rated posts) and get more
interesting infromation from the public response than from the
original article.  Getting this kind of information into a
permaculture database is my lay-awake-at-night fantasy and combined
with wanting to archive/index all the excellent posts from
permaculture@ibiblio was the birth of what I now call Eden.  I think
that we should view the subscribers of that list as our primary target
audience and everything we do should be done in the light of will this
help them and will they use it.

Althought this may seem like quite a jump, another way to create a
framework of collaboration is the a distributed peer-to-peer
network. I don't want to talk about all the details right now, but the
pros seem to be, flexibility/customizable/tailored to the individual
(would accommodate bioregions/climate by design), data redundancy (no
monolithic web app), peer moderation (I could accept submissions from
Toby, John, and Ken but not Mr. Monsanto or Joe Onlinedrugs), could
incorporate private or unshared data such as a garden journal, field
notes, etc.  The cons are primarily around creating something so large
and complex that it is a barrier to entry.  The web is easy to use for
almost everyone and I can't see a way to make some of the aspects of
a distributed peer-to-peer network as brainless as the rest of the web.

The front end can be anything and can/will be more than one thing.
One front end could simply be a text field entry box and a "Search"
button.  Another front end could be a graph based 3D representation of
plant relationships in a guild.  I'm imagining our product to be very
flexible in terms of front ends, in part because the way we need to
get at this data will vary at times and using multiple different tools
will be necessary at times.

Our API between ends can be whatever we decide will best meet our
needs.  I have begun to XML'ize the dataset in Eden and recommend we
do something similar as a medium of data exchange.  This is also the
answer of how to make specialized editors or how to tweak COTS
stuff we know and love to edit with.

One way guild information can be added to the existing dataset by
adding native plant communities and extrapolating (we've already
talked about this).  I still hold that guild building is not our
highest goal nor is it that achievable and would like to downplay that
element if possible.

I don't think that the knowing the database schema all figured out is
that important.  I don't think that for what we are doing that we will
even consider it figured out by the time we have a working product.

-- 
Chad Knepp
python -c 'import base64;print base64.decodestring("cHlnQGdhbGF0ZWEub3Jn")'