pcplantdb

[Chad Knepp <pyg@galatea.org>]

Richard Morris writes:
 > John Schinnerer wrote:
 > > I told him you had put yourself forward as the one with the most
 > > hardcore development chops and I don't recall anyone protesting
 > > that too loudly.
 > I've a fair range of hardcore dev chops too!

In all honesty, I think a lot of my abilities but I don't have much
professional experience.  I would encourage people to look at Eden
though to get an idea of my work.  The Genesis_0.1.0 release was
written in 7 days (no lie/joke/unintentional arrogance).  

 > <snip> 
 >
 > > His main concern is how will we in practical terms dive in and
 > > proceed if he gets us some money.  The likely amount he mentioned
 > > coming through in July was in the $12k - $20k range, if it does.
 > > What could we do with that, he wants to know.  He likes what we
 > > are about as he's heard it thus far.
 > 
 > This seems to be about the figure I was expecting, much less than
 > the original proposal, hence much less salaried development time. I
 > suspect this will mean that we'll have to focus on the core
 > elements leaving the bells and whistles till later.  I guess this
 > would encourage us towards a Keep it Simple Stupid (KISS)
 > development model.
 > 
 > > I told him my take was that phase one would be a simple,
 > > practical, PC-centric plant database architected in such a way as
 > > to be able to grow from there.
 > 
 > Yep.

Word smithing here, but I would rather leave out the plant specific
part, or I can buy into the plant part if part of the growing is to
accommodate things other than plants eventually.

 > > Focus would be on clean and robust back end, clean and open API
 > > and a simple front end to start, with the clean and open API
 > > making all manner of front ends possible eventually/as resources
 > > emerge.
 > 
 > Yep sounds good. The API does seem key. To some extent there does
 > seem to be seem to be a corespondence between API, XML-DTD and
 > database schema. I've read quite a bit on how there can be fairly
 > canonical mappings between the DTD and schema.  And the format of
 > data returned by API calls (i.e. XML format) is really part of the
 > API.

I'm starting to fuzz out on what the front end would actually be
anymore.  I would be interested in hearing what you think the front
end is going to do and what the back end going to do.  Part of the
problem is that my head is getting a little full of ideas.

 > > It would serve initially as one answer to the inevitable
 > > PC-course participants' question "...so where can I find
 > > permaculture-relevant information on plant attributes and
 > > functions so I can use them appropriately in designing??"
 > > 
 > Yep, it would be good to know what our users want.
 > > 
 > > >Yeah, I can see how an object DB would tie in neatly with an
 > > >object method of peer to peer data exchange.
 > > 
 > > 
 > > I actually think it's a better model whether peer-to-peer or not.
 > > Myself, I pitched this to Jim as strictly my take/my preference.
 > > He seemed to like the object based approach.
 > 
 > I've no real problems with an object based approach,
 > apart from never having played with it. I'm not
 > really sure on the advantages though; compare a
 > plant object
 >      class Plant {
 >              String LatinName;
 >              String CommonName;
 >              ...
 >      }
 > 
 > To a typical RDBS table
 > 
 > Table Plant
 >      Field LatinName
 >      Field CommonName

The OO model is actually a lot more than that because it also includes
methods (and more).  For example you could also do things like format
your output within the object.  One of the features of Eden is to
return search results in a short summary form (like google) instead of
just latin/common name.  If each plant object had a method to generate
a summary of itself I could just iterate over the search results
calling the summary method of each object to generate my page.

class Plant:
      def __init__(self):
          self.LatinName="NULL"
          self.CommonName="NULL"
          ...

      def Generate_XML_Summary(self, format_style="default"):
          xml =  self.LatinName, self.CommonName
          xml += ...
          return xml

 > The one question I would have is if some binary format
 > object would be passed between front-end / backend.
 > To my mind text formats have a lot of advantages here:
 >      1) Their intrinsically more open, you just
 >              need to look at the data. Which format
 >              would you perfere to work with HTML or
 >              Word?
 >      2) They might make things harder for clients
 >              any client in any language can parse
 >              XML or other text format. But will
 >              MyFavoriteLanguage be able to interpret
 >              objects created in YourFavoriteLanguage?

I agree with what you are saying, but as I said earlier it's becoming
less clear to me what the distinction between front and back is.
Communication between them is ultimately dependent on the answer to
that.

 > > Again, if this is built carefully the guild aspect will be both
 > > implicit and an emergent property.  Some added logic to extract
 > > and/or extrapolate guild information from plant objects and
 > > voila!  Stephanie's dream realized!  ;-)
 > > 
 > Brain too small to understand this! Please expand.

Graph based mapping of information is a snap when you are dealing
objects.  One can easily add a method to traverse a set of objects in
an arbitrary fashion (like linked lists or other data structures in C)

class GuildAblePlant (Plant): 
      """ Guild capable plant """
      ...

      def GraphOnClimate (self, length_of_list=25)
          """ Traverse based on climate similarities. 
              Returns a list of plants in decreasing order of
              similarity. 
          """

          ...
          return list_of_plants
          

 > <snip>
 > 
 > >>What should I be reading/looking at?  I also have some
 > >>concerns that may just be questions if I look into it more (like
 > >>performance).
 > > 
 > I'm not sure if speeds/performance is going to be much of an
 > issue. The DB is small, 7000 entries, most things can
 > query that in less than a second.

640K ought to be enough for everyone... ;-) I'm hoping for 7 million+
objects.  Performance will ultimately matter but optimization can
easily be done later.

 > >>I personally think XML is just the latest in a long list of
 > >>useful but tremendously over-hyped technologies.
 > > 
 > > Yah...
 > > 
 > >> I don't think there is even that much to it as a technology.
 > > 
 > For simple things its as good as any other text based format.
 > It can get really hairy when you start looking at
 > XPath, XLink, XML Schema, namespaces etc. etc. When you
 > get too involved in all the fancy bits it looses its
 > simplicity and the markup to data ratio goes sky high.
 >
 > > I thought there was way more to it than there is due to all the
 > > hype...I was surprised to find out how relatively simple it is.
 > > Which is good in the sense that it's more accessible to more
 > > people.  Anyhow, the hype generates active use of it and it's not
 > > IMO a 'bad' technology, so more potential for growing the
 > > community of project participants who might (for example) build a
 > > front end of some sort using the XML in-between because it is
 > > familiar/comfortable for them.
 > 
 > I'd agree strongly here.

XML is just a consistent and generalized approach to markup language.
In our situation I think it makes sense for things like this
<temperature type="Celsius">17</temperature> and then allowing for
user preference to specify output units such as 17C or 67F.  (Hope
that renders ok in HTML aware email clients)  This was my intention in
xml'izing the dataset in Eden (still on the todo list, not done).

 > <snip>
 >
 > > 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).
 > 
 > What I'm doing for modoration of reader comments to PFAF DB
 > is that I get emailed a copy of every comment submitted.
 > It should be quite easy to do have a accept/reject email response.
 > 
 > To my mind such a system is all we'll really need for version
 > 0.1. The rate of submissions will probably start small
 > (aprox 1 comment a day), so the workload will not be too hard.

That doesn't sound like it would scale well.  It also doesn't sound
like a fair, balanced, or collaborative method of moderation.  I am
willing to keep it simple but not that simple.  

 > <snip>

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