pcplantdb

[Chad Knepp <pyg@galatea.org>]

Lawrence F. London, Jr. writes:
 > Chad Knepp wrote:
 > 
 > >  o I am super excited and would love to dive into the design stuff
 > >    immediately and off the clock.  It would probably be nice to have a
 > >    tech list for this.  Lawrence? 
 > 
 > Can do, immediately. pcplantdb-tech@lists.ibiblio.org? or something
 > else perhaps that includes more than just plant information in a
 > permaculture database?  maybe pcdb-tech@lists.ibiblio.org?
 > 
 > As soon as you decide on a name and let me know I will fire off a
 > request; we will probably have our list within a week.
 >
 > <snip>

How about hg@ or hg-tech@?  Actually I don't think the name matters
much.  Whatever you pick is fine.  

Richard Morris writes:
 > <snip>
 >
 > The actual grant app and jim's feedback may have some baring on
 > feature set.
 > 
 > For me its
 > 1) A plant database where users can add new information about a
 > plant, and add whole new plants.  If we can do that and nothing
 > else it will be a job well done.
 > 
 > Before we begin I think we need:
 >      A CVS tree for the code (source forge sounds good to me
 >      I'd be happy to set this up)

Go for it.  Might as well get the infrastructure set up early so we
don't have waiting when we get in motion.

 >      Possibly a wiki page for the specifications
 >      (i.e. something we can all contribute to and
 >      which will evolve with time)

I personally dislike Wikis but this sounds ok.  We do need some public
repository of specifications and documentation about the project.

 >      A project description page. Something that
 >      new people can read to get upto speed on the project.

Also as above.

 > Stuff I think should be in there, but not core
 > 
 > - extensible, easy to add new features at later date
 >      (e.g. so we can add a "folklaw" section, or
 >      vote for plants)

I think this is a core element and will only be as successful as our
OO design is correct.  This is super important and something I'm
constantly turning around in my subconscious that occasionally
surfaces as interesting possibilities.  One of them was that as a
sufficiently generic tool set HG could actually provided a similar
service to other sub-communities.  My friend had mentioned that the
home-brewing list he was subscribed to had lots of great info (just
like the permacutlure list) that was promptly forgotten and repeated.
I can see HG being a Wiki tool better than a Wiki for specialized
information.  Anyway, I don't think that creating and distributing a
generalized tool should be a part of the current project, but possibly
something that could be worked backward to later on.

 > - full history of additions. So we can keep track
 > of who added what.

Also essential if only to accurately preserve copyright info.  This is
also trivial to implement for a smallish amount of activity, but may
need some sort of compression for a lot of use, like when the
changelog grows larger than the rest of the data.  Using some sort of
*lossy* compression like dropping the actual content/nature of the
change/contribution and merely attributing copyrights on the object to
the author would solve the size problem at the expense of the
information loss.

 > - buz word complience. Some sort of XML output,
 > rss/atom/rdf so its easy for third parties to
 > access the data.

I've been thinking more about the role of XML in the project and yes,
it would be nice and very doable to translate output to rss.  This
doesn't seem as important to do as soon as some other things.

What has occurred to me is that one of the hardest and most important
parts of the client toolset is the authoring/collaboration part.  I
think it makes complete and total sense for the client to generate
this as an XML document and that the internal data elements all be in
this ML.  In Eden I made up something I called KFML that was a tiny
subset of HTML with an additional tag for internal links like a Wiki's
CapitolWord.  Another [minor] feature of the client would be
translating this internal ML to something viewable; like HTML if the
client platform is a browser.

Anyway I'm hoping I won't have much to do with all that so I hope you
are getting excited about writing [or adopting] a dtd and a validator
that can point out mistakes in the ML to the author.  Sound like fun?

 > - guilds/relationships. I guess we'll need to do
 > something on this line to keep funders happy,
 > initially I think something simple. (I'm happy
 > to work on this aspect)
 >
 > - cool gui interface. Thinkpad type stuff. Again
 > we probably need something on this line and I'm
 > happy to work on this.

I've actually had some more ideas on how to backend something for a
graph based interface that doesn't require any natural plant
communties.  Although it would require a bit of effort I think we
could look at similarity of certain qualities between plants and
display the relationship of respective similarities visually.  This
wouldn't really design a guild but it could allow visual exploration
of plants based on user chosen qualities and even importance of
qualities.  

It is also possible to create a virtual/AI model of a guild and
populate it randomly or with a similarities based algorithm.
Something like a tree guild would require a central tree with an
understory of different sizes or something.  One could also create a
generic aquaculture guild and so on.  This kind of thing seems MAJOR
HARD and although I love challenges I don't think we should try to go
here immediately.

 > - picture uploads.

Certainly and other media types as well such as articles.  This is
were the internal XML gets interesting depending on how much formating
it allows the authors.  Do you allow content to have embedded images
or do you just link to them.  Allowing authors to specify formating
like embedded images may make for a nicer overall read, but opens up
the possibility of really bad formating that detracts from the overall
accessibility.  I think allowing re-edits and having moderation will
ensure that this doesn't persist though.  Allowing formating options
also makes WYSIWYG clients a lot more complicated.  Lots to think
about...

 > In my dreams:
 > 
 > - votes/rating system for plants.
 > - shared Links/contacts/events databases.
 > - etc.....
 > 
 > >  o Implementation details: After we have point 1 of the feature set,
 > >    we need to figure out who is doing what and how.  The how is
 > >    especially important when there is overlap between folks on the
 > >    what.
 > > 
 > >  o Licensing: We need to agree on a license or licenses.  I am
 > >    completely open to suggestion, but I recommend the code base be
 > >    under the GPL and the data set be under the CC BY-SA or BY-NC-SA. 
 > > 
 > There is now a CC-GPL license, which is basically GPL
 > but with machine readable metadata. This may be more
 > compatable with the dataset. I'd much prefer CC BY-NA-SA
 > to CC BY-SA for the dataset.

If we use the PFAF dataset we will probably have to use the BY-NC-SA
unless we can convince PFAF to drop the NC.  The reason I don't think
that the non-commercial clause is important is that if you are already
providing the data in a free form no one needs to purchase commercial
versions to get the information.  If someone wants to publish a book
with the information I think it is a win-win situation.  They may make
a little money on it, but having the information in a format we can't
provide is a good thing for people that want to read a book with their
breakfast and not bang on a keyboard.  The only sticky situation I can
foresee that not having the NC clause could lead to is if someone took
the information and added additional but proprietary information and
then sold it... kind of like the PFAF data with images.  I don't think
this would ever happen because if we have the entire permaculture
community collaborating on it we would have a lock on all the good
sources of information anyway.  This is also why we don't have to buy
the PFAF images, because I'm certain people will start taking pictures
and uploading them as soon as we make it possible.

I think the GPL is a very good license for code with an excellent
legal track record.  It wasn't really designed to cover other sorts of
information so I think the data should be under either the LGPL or GPL
documentation license or something else.  Since the PFAF dataset is
under a CC license and we are potentially going to incorporate it, it
would be very straight forward to use that.

One thing that hasn't been mentioned that I will say for the sake of
thoroughness is the possibility of allowing the authors themselves to
choose the sort of license they would like and offer a selection of
licenses.  This is actually the direction I was going with PCPDB but I
think this is a bad idea because of the amount of internal accounting
it would require in addition to the complexity of having a given
object licensed under multiple licenses.  An appropriate display of
copyright would require us to show each and every license, possibly
having more info about copyright than the plants or whatever.  I also
think that if we pick a reasonable license that folks will have no
problem agreeing to contribute under it.

Another thing for the sake of thoroughness is that the GPL isn't
always compatible with non-free libraries and toolsets.  This will not
be a problem for me because I don't intend to use any non-free
products.  It is my understanding that the most everyone was on board
with the idea of only using free software.

So I propose that we consense on the following:

  Our project [HG] will license the code under the CC-GPL and the
  dataset under the CC-BY-NC-SA.

So what do you all think?  Now would be a good time to hear any
additional concerns or comments you may have.

 > >  o Project details: Uhh... things like a name, although this could be
 > >    as hard choosing the color of paint I would love to start referring
 > >    to it as something other than "project" or "our product".  There
 > >    are a host of other details that may actually be easily answered
 > >    but I cannot immediately recall the answers.
 > 
 > I've been refering to it as the "opensource/community (permaculture) 
 > plant database". But a bit of a mouthfull.

I'm going with HG... it's funky, short, and sweet!  ...maybe it will
stick.  We should have something a little better to release though.

 > <snip>

Stephanie Gerson writes:
 > Group Strategy and Plan of Action

Wow this looks good.  The estimation of times seems close to my own
guesses.  

 > Divided into 3 Tasks:
 >    A) Software Development-to be executed by experienced Computer
 >       Programmers and User-Interface Designers
 >    B) Plant Research and Data Entry-data will be solicited and collected
 >       through on-line Permaculture/Agriculture/Horticulture forums,
 >       listservs, and communities; existing informational resources (books,
 >       magazines, journals, etc.) and plant databases; Permaculture or
 >       related conferences, and on-visits to developing or developed guilds
 >       (many guild designers have already offered their expertise)
 >    (C) Further Outreach/Dissemination-to be performed through the same
 >    channels as data collection

One thing that I suggested earlier as a possibility to stretch our
funding was to not fund much or any authoring initially.  Not sure
where everyone is on that.

 > Stage 1 - Design, 1 month
 > 
 > A1) Detailed technical spec to be drawn up.  Inc: database schema, mockup
 > of user interface, selection of software environment.
 > B1) Format for information on plants to be agreed.

Hmmm... seems to me that B1) is really part of of A1) specifically
related to the database schema... unless you mean something like the
XML format which still seems to be part of A1).  

I think that an important part of A1) is to be very clear on what we
are creating but try and be quite flexible about the creation and
allow a naturally evolving process.  Even if we write 500 lines on
database schema, I'm certain that it will be in at least some small
way inappropriate to our needs within a month of development and it
would a shame to kick ourselves in the shins by adhering to it.  I
think we can know where we are going and state that clearly but I'm
not sure we can say now exactly how we are going to get there, so I
think it's important to seperate elements of the design into goals and
milestones and expect that the implementation will sort itself out as
we go along.  I also may be out on a limb here because I tend to be a
kind of *dive in headfirst* sort of person.

In terms of design I would like to focus on things like whether or not
to try and include a moderation system in this incarnation and what it
would look like.  Should the client have its own editor?  What kinds
of things other than plants should we include if any?  etc...

 > C1) Contacting partner organizations.  Research into third party datasets.
 > For the above, we would like to have a 1 week physical meeting (ideally at
 > a Permaculture conference, in order to simultaneously collect information,
 > solicit participation from interested parties, and make contacts with
 > partner organizations).
 > 
 > 
 > Stage 2 - implementation, 3 months
 > 
 > A2) Implementation of software. Core database engine and user interface.
 > B2) Collecting and inputting plant and guild data.  Once this web resource
 > is available for input, this task will continue perpetually, carried out by
 > the resource's users.  For purposes of devising a timeline, the initial
 > 'prototype' of the web resource will occur in Stage 2.
 > C2) Incorporating comments from partners.
 > 
 > 
 > Stage 3 - First working version, Testing, 1 month
 > 
 > A3) Importation of plant data to main database.  Initial
 > evaluation of database and user interface.  Testing.
 > B3) Iteration of A3).  More data collection.  Editorial review of data.
 > C3) Incorporating third party datasets.

I'm not sure what you mean by A3) but it would be nice to get the PFAF
dataset in sooner than this in order to have something concrete to
work with.  I can make up dummy data but since it's not really much
work to do it makes sence to me to merge in PFAF somewhere in the
early-middle of stage 2.  I estimate that this will take less than 40
hours and represents a fabulous amount of info on 7000+ plants.

 > Stage 4 - Refinement, Production of first release candidate, 1 month
 > 
 > A4) Refinement of software and interfaces.
 > B4) Iteration of B3).
 > C4) Outreach/dissemination activities.  Database launch publicized.
 > The next project-participant meeting/Permaculture conference occurs.
 > 
 > 
 > Stage 5 - Maintenance of live version, Processing Feedback, 5 months
 > 
 > A5) Ongoing maintenance.  At this stage main software track decreases in
 > time
 > Involvement.  However continual maintenance and improvements are needed one
 > week/month for remainder of grant period.  Ultimately, the web resource
 > should be self-sustainable, not requiring a permanent salaried moderator (a
 > responsibility we will assume throughout the grant period), but instead
 > depending on the interest and volunteer efforts of its constituents.
 > B5) Editorial control of data input by users.
 > 
 > 
 > Stage 6 - Project Conclusion, 1 month
 > 
 > C6) Begin spec for next phase.  Complete final report for funding
 > source(s).

I am interested in starting A1) as soon as John is back online and we
have a tech specific list.  I'm not really into doing the conference
call thing and being spread around the globe might be something of a
scheduling problem.  Does anybody here use instant messaging?  I can
see that as having some potential and you can't beat the price.

So when are we fully funded?  When are we to officially start, as in,
when do I start tracking hours?  Also what kinds of activities are
billable?  I could use more info. about the business side of things as
I'm not really sure what the norms are.

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