Skip to Content.
Sympa Menu

pcplantdb - Re: [pcplantdb] Job One

pcplantdb@lists.ibiblio.org

Subject: pcplantdb

List archive

Chronological Thread  
  • From: Chad Knepp <pyg@galatea.org>
  • To: Permaculture Plant Database <pcplantdb@lists.ibiblio.org>
  • Subject: Re: [pcplantdb] Job One
  • Date: Sat, 18 Dec 2004 18:27:16 -0600

Bear K writes:
> >> Fully agree. I believe I mentioned that I wanted to see the back-end
> >> discussion restarted. I've mentioned a few DB related ideas without
> >> much response.
> >
> > Partly due to actually having to learn something about RDF in order to
> > respond intelligently ;-)
> Yeah, sorry, didn't mean to sound pushy.
>
> > RDF does look quite interesting and a discussion you missed out on
> > early on was a desire to make our information accessible to other
> > systems. We supposed would probably be something XML. RDF may be the
> > XML technology for this.
> >
> > As exciting as RDF may be, I'm pretty hesitant to switch chosen
> > platforms both because of shyness to try out recent technologies early
> > on and feeling a need to focus on getting promised features into PIW
> > not learning new stuff (as much as I love that).
> >
> > Moving to RDF could be a feature of future funding proposal...
>
> Yes, lets not scrap the work you've put into developing the system now.
> It seems though, that with all the requests to add information and
> relationships, plants linked to microorganisms, comments linked to
> their authors, book reference information, etc, that developing the
> RDBMS schema and handling the code that interfaces with it would build
> exponentially in complexity (perhaps a slowish curve though?).
> So getting the plant information on-line, a got interface and display
> of the info, using the current system seems like the pressing concern
> right now, we should perhaps look at this system, and perhaps plan on
> transitioning to it for Phase 2. It seems like this system matches a
> lot of what folks were looking for in a system. OOishness,
> relationships, XML, RDBMS. Honestly, I still need to research this
> more. Being able to output a standard XML format, then using XSLT as
> Richard suggests would be great. Transforms for Grokker compatibility,
> or TouchGraph compatibility, lite PDA client, etc should be within
> reach then. I'll also work on keeping the HTML and CSS clean, and make
> sure all styling is in the CSS to allow for new CSS based designs.

I'm absolutely positive that the [LAMP] technologies we are currently
putting together for PIW will be supplanted in the future by something
more powerful/appropriate. With this in mind my orientation to the
current work is to not design us into a hole. Keeping the dataset
independent of the code, clean, and well documented are the best
things I think we can do to allow easy migration to future
technologies.

On the other hand, although the latest greatest technologies promise
a lot, I doubt they will be as featureful/easy/scalable as
advertised. This was my experience with Zope anyway... which I still
love, I just don't think it will really do everything effortlessly
anymore.

> Hmm, yes, we could provide a "low bandwidth" style sheet, cut most/all
> of the images, etc.
>
> I'm thinking of pulling the search box out of front page text, putting
> it into a right nav block, and having it on all pages. Any objections?
> Should we also have a search tab which provides an advanced search
> page, and is what's shown when results are put up?

There are a number of different kinds of searches that are currently
unused by the existing site. They include search by name specifically
and a botanical family search. I have also fantasized about a search
form that would be something like "I'm looking for a (pull down box
with things like plant, tree, shrub, vine, critter, etc) that is (pull
down box of various properties) and ....

There are also a lot of preferences that can be set including
summarized/tabled search results (default is summarized), number of
results per page (default 10, max 100), score threshold, and some
different report types. This would be a cookie based... but
configured from a static page.

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




Archive powered by MHonArc 2.6.24.

Top of Page