pcplantdb

[Chad Knepp <pyg@galatea.org>]

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

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!

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