pcplantdb

["Lawrence F. London, Jr." <lfl@intrex.net>]

Chad Knepp wrote:
>  > Description of Project Mission, Purpose, and Issues
>
>  > <snipping non-technical bits>
>
>  > In order to develop this resource, TouchGraph, an application development
>  > tool developed by TouchGraph LLC, will be used.[1]  Being a Graph Based
>  > Interface (GBI)-non-linear with a web-like interface-TouchGraph is suited
>  > for representing complex and relationship-based knowledge, and therefore
>  > ideal for the topic of Permaculture. Ideas regarding the informational
>  > architecture of this resource are very specific, and may be further
>  > elaborated upon request.
>
> Hmmm... sounds like something GBI is necessary.
>
>  > <snipping non-technical bits>
>
>  > The field of Permaculture, along with those of Sustainable Agriculture,
>  > Sustainable Forestry, and Ecology, among others will clearly benefit, as
>  > diverse and largely undocumented knowledge regarding guild design will be
>  > pooled into one interactive, co-evolving database offering permanent access
>  > and feedback opportunities. The information therein will provide an in-
>  > depth knowledge base of information regarding plants and their
>  > relationships, essential for guild design and a systemic understanding of
>  > ecology.  Because Permaculture is not a membership-based organization, of
>  > course, anyone will be able to enjoy access and reap information from this
>  > excellent knowledge database.
>
> This description closely represents my own vision, including elements
> of accessibility, a collaborative nature, and a feedback/moderation system.
>
>  > -----------------------
>  > [1] A former iteration of this project plan involved the use of Plumb
>  > Design's Thinkmap, a Graph Based Interface similar to TouchGraph, yet more
>  > sophisticated.  However, Thinkmap is proprietary and quite costly, whereas
>  > TouchGraph is open-source and freely available.  And considering the
>  > proposed project's relationship with Permaculture, we decided to practice
>  > the Permaculture principle of using resources already available-which
>  > TouchGraph is and Thinkmap is not.  If after developing the web resource's
>  > initial stages, we decide that Thinkmap would offer significant additional
>  > benefit, we will reconsider its use.
>
> Using an open source GBI package instead... ok.

Isn't a GBI interface icing on the cake which could be added later. Seems 
hours of programming
effort ought to be devoted to the basic database, user interface, structure 
of the database and structure of the Web interface.

On another note, talking with an artist/computer graphics/video friend of 
mine and mentioning HG
and its initial success at findraising and the existinf PFAF, it occured to 
me that HG may be at the threshold of greatness,
even financial success as well as wide popularity with a significant global 
following. Look at the successes of Mozilla,
Sourceforge, W3 Consortium, Google, ibiblio, PFAF!

A few HG features I would like to see:

text search
database search
browse: lists, indexes, an outline/table of contents/site map (enter the GBI 
here)
    - a way for newbies to find out what kind of information is in the 
database and how search or browse results are delivered,
       information format types (text, graphics, video, sound)
I would like to see HG become a portal to worlds of information related to 
the type of information contained in HG's collection
   Ex: text or database searches would access resources on its server as well 
as that which exists elsewhere on the web;
   i.e. HG as a PCPlantDB Google. This would open up enormous possibilities. 
All others working on Web development projects similar to HG
   could be accessed - to give HG users a very complete picture of what resources exist on a particular plant, guild or info in any of the 

   fields in a plant record. This might represent much data that should exist 
in HG but is too large or cumbersome to include. So HG
   accesses a specially selected extranet. Ex. I have a large collection of material on compost tea/soilfoodweb/soil quality. This could 
contain useful information to read when seeking cultural information on a particular plant. This info is in a Hypermail archive,
neatly arranged, sortable different ways and text searchable with Google. This is a convenient way to organize and present collections on 
various topics. Ths interface is similar to the message archives for this list but different in that anyone can build these archives
from Unix mail files (also Netscape's and Mozilla's mail folder files, plain 
text) -they are conveniently added to Wikipages, ad infinitum.
Cool thing is that one's email folders can be converted to Hypermail 
mail2html archives for Web access.

> The only way that my vision differs much the above is that you seem to
> specify that a GBI is an optimal way to represent/understand/create
> guilds and I don't know that I agree with that.  I think that it could
> be a useful tool in a varied toolset of informational tools, but I
> don't think it would be the first thing I would reach for.  PFAF -->
> PCPDB --> Eden have been the tools I use for guild design and to
> better understand the relationship of elements of larger permaculture
> systems.  I see HG as the logical extension of these early tools and
> in that sense I can really get behind the idea that it is a guild
> builder program.
>
> I also think we can do graphing stuff pretty easy esp. if it is keyed
> to similarities or differences in attributes.  As an example, let's
> say that you have a plant and you want to explore other plants that
> are similar in height, shade tolerance, moisture requirements, etc.
> This would be a good way to find replacement/alternatives for
> particular guild members.  Anyway, I think would be trivially easily
> to write the server elements if Richard wants to play with TouchGraph.
>
>
> Chad's Plan.
>
> Here are what I see as the core elements of HG that I propose to
> implement.  I've given estimated times instead of dates.  I do not
> protract coding.  When I enter *hacker* mode I average 50-60
> hours/week.  I'm a lot more efficient when I can consistently maintain
> train of thought than working slower.  Unfortunately I'm responsible
> for a largish veg. garden that is just hitting full on production at
> the moment, so I think it is more realistic to be able to offer 20-30
> hours/week starting August 1st and probably suffer a bit of efficiency
> loss in the multitasking.  After Nov 1st I can swing into full time
> hacking if necessary.
>
> 1. Database creation with basic search and minimal web interface. 
>
>   Estimated time: 60 hours
>
>   Prerequisites: Agreement/design/selection of plant attributes.
>   There are about 100+ different attributes in the PFAF dataset.  Some
>   of these we may not need/want and some are definitely missing.  It's
>   not at all important to get this absolutely correct up front, but
>   changes later on will have to be in both client and server elements.
>   This is to be expected and won't be that difficult.
>
>   Proposed implementation: Python using ZODB and Zcatalog running as a
>   python cgi from a webserver interfacing with a web-browser using
>   html as the intermediary xml, and alternately if desired, as a cli
>   program using text.  I'm not planning on doing a cli unless people
>   ask for it.  It's nice for testing but probably won't be that useful
>   except for serious hackers using it to batch process things.
>
>   Notes: This is basically rewriting PFAF/Eden in our newly chosen
>   architecture.  It took me about 60 hours to write Eden, so I think I
>   can do it again in about the same amount of time.  I suspect that
>   this will be a prerequisite to most other participation.  The
>   html/web-broswer client is a temporary measure for
>   testing/demonstration purposes and does not really add appreciably
>   to development time.  It is also possible/likely that client
>   development will proceed from this initial minimal implementation.
>   The search function will also be a minimal function unless people
>   want something smarter.  Tooting my own horn again... Eden has a
>   very sophisticated search engine.
>
>
> 2. Importing the PFAF/Eden dataset.
>
>   Estimated time: 40 hours
>
>   Prerequisites: 1.
>
>   Proposed implementation: Python custom tools to extract from MySQL
>   and populate the HG object database.
>
>   Notes:  This really needs to happen in order for 1. to be useful in
>   any demonstrable way early on.  Otherwise we will need to make up a
>   couple of dummy/fake plants to test with.
>
>
> 3. Users and collaborative capabilities including [re]editing, edit
>    tracking, graphing functions.
>
>   Estimated time: 100 hours
>
>   Prerequisites: 1. and agreement/design of server-client interface
>   w/Richard.
>
>   Proposed implementation: Adding user objects and authentication,
>   adding edit tracking capabilities, adding client interface
>   capabilities, adding graphing functions(?).  I think that this would
>   be a good time to add user comment objects as well.
>
>   Notes: Not at all sure about the time this would take but at the
>   moment 100 hours seems like plenty.  Most of the work here will be
>   creating a friendly API for the client.
>
>
> 4. Moderation and reputation system.
>
>   Estimated time: 100 hours
>
>   Prerequisites: 1, 3, and clarified design.
>
>   Proposed implementation: a peer reputation weighted information
>   moderation system to indicate information relevancy/validity.
>
>   Notes: Absolute guess about time.  We need to talk more about this,
>   but I really like what John reported of his conversation with Jim
>   F. about a community reputation system of moderation.  Quoting him:
>
> John Schinnerer writes:
>  > In short we considered that different moderation approaches might
>  > be appropriate for different content types, and Jim pointed to the
>  > value of distributing/socializing the work of moderation.  We
>  > considered the difference between brief 'factual' data (climate
>  > zone, shade tolerance, soil preference, water needs, that sort of
>  > stuff) and less brief 'narrative' data (which is much richer and
>  > also harder to corroborate or 'verify' in a simple way).
>  > 
>  > The former could be for example vetted by 'qualified' community
>  > members in a sort of distributed review process before being
>  > published publically.  Who is 'qualified' is TBD and I won't go any
>  > deeper into that at the moment!
>  > 
>  > For the latter, we considered the possibility of a
>  > community-reputation system (like yes, sigh, eBay as a major
>  > example) where people can provide feedback on each other's
>  > narrative info.  People who continually get called on submitting
>  > questionable or bogus information will be visible as such by all
>  > users.  People who consistently submit useful and pertinent
>  > information will likewise be visible as such by all users, and so
>  > on.  Jim pointed out also that this allows for the positive
>  > possibility of people questioning and expanding the simple
>  > 'factual' data based on their own local experiences.  Quick example
>  > - plant X is listed as not viable beyond zone 6 and this is
>  > verified by multiple independent sources (other DBs, experienced
>  > horticulturalists, USDA reference, etc.).  Meanwhile someone
>  > somewhere has been growing plant X successfully in zone 7 and can
>  > describe how they've done so in a narrative submission - perhaps
>  > through the use of some clever design that could be useful to
>  > others as well.
>
>
> Have fun and give your plants my love,
> Chad
>
> P.S.  Good to still have you alive John, sounds like it was close!


--
L.F.London
lfl@intrex.net
http://market-farming.com
http://www.ibiblio.org/ecolandtech