Skip to Content.
Sympa Menu

pcplantdb - Re: [pcplantdb] some quick thoughts

pcplantdb@lists.ibiblio.org

Subject: pcplantdb

List archive

Chronological Thread  
  • From: Richard Morris <webmaster@pfaf.org>
  • To: pcplantdb@lists.ibiblio.org
  • Subject: Re: [pcplantdb] some quick thoughts
  • Date: Fri, 07 May 2004 00:15:19 +0100

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







Archive powered by MHonArc 2.6.24.

Top of Page