pcplantdb

[Richard Morris <webmaster@pfaf.org>]

Chad Knepp wrote:

Great post Chad.

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

Too right. One thing which struck me as, was the
first person I've talked to on the phone about this
project was Jim. If anyone want to give me a ring
my numbers at the bottom of the page.

At some point we are going to start making
decisions. Should we have some sort of
decision making process? How do we organise
ourselves?

> The reasons wikis don't work for us, is that
> they don't scale to the complexity of our information, 

Or to put it another way. Each page in a Wiki's is
unstructered data. The data we are dealing with is
inheriently structured.

> and they don't
> work well even for themselves because doing any kind of editing with a
> browser based inteface is a serious drag.

Agreed. One good thing about a wiki is that the markup
is quite simple, much easier than html.

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

You can get quite a lot of good editor clients out
of the box in a lot of open source packages. The eclipse
projects SWT GUI package makes it very easy to build
a custom editor in java. Whats data input like in flash?

Theres several ways that structured data could be entered:

1) Either a form based page with lots of input boxes
        there about 54 fields in the pfaf db, that
        a very messy page.

2) Using some sort of maarkup language al la wiki
        One posibility is that a page could be supplied
        with pre built section heading, something like

- Latin Name

- Common Name

- Edible Uses

and the user could fill in the text between.


> 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.
I'd be quite interested in seeing a slashdot for permaculture
(or actually the whole green thing!) Personally I find
it a better system than mailing lists for a certain types of
discussion. (But it would not be a good substitute for this list).
The code for slashdot (slashcode) is opensoucre so it would not
be too hard to do.

> 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.
I talked a bit to Jim about RSS, he was very enthusiastic.
Lots of sites are now delivering their data in RSS with
is a specifit XML format good for listing news items.

This could work well with a peer-to-peer network. basically
providing the tools to make it easy for the different permaculture
sites to share information together. Good sharable items
could include event listings and group directories (i.e. links).

> 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.
Somehow the XML format seems to be the core of the
project. I'm presuming that this will be the primary
format between client and server. With that in place
different api's will be possible.

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

A simple solution might be allow a "plant list"
which could just be a simple list of plants, maybe
with a desriptive text and a title.

> 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.
We will need at least some core to build on, some rough
framework.

        Now it gets interesting!

                Rich

--
Plants for a Future: 7000 useful plants
Web:   http://www.pfaf.org/ same as http://www.comp.leeds.ac.uk/pfaf/
Post:  1 Lerryn View, Lerryn, Lostwithiel, Cornwall, PL22 0QJ
Tel:     01208 872 963 / 0845 458 4719  
Email: webmaster@pfaf.org
PFAF electronic mailing list http://groups.yahoo.com/group/pfaf