pcplantdb

[Chad Knepp <pyg@galatea.org>]

John Schinnerer writes:
 > Aloha,
 > 
 > > Cool.  Still not sure that input/output is enough or necessary.
 > 
 > Definitely necessary.  Fundamental PC concepts.  If we are claiming to be
 > PC centric, to teach PC to those not familiar and support those familiar
 > this and more is necessary.
 > 
 > Definitely not sufficient.  Just one common example I chose to illustrate
 > making PIW PC centric.  Many more fundamental concepts need to be
 > supported.
 > 
 > > Is being the color blue an input or an output?
 > 
 > Neither IMO.  Not all properties of an item need to be one or the other.
 > I am talking in this case functional inputs and outputs as in the classic
 > 'chicken' example.  'Needs' and 'provides'.
 > So blue is neither, nor is height, nor is zone, nor is root form, etc.
 > YMMV, we need to converse about this probably.

Inputs, outputs, and attributes?  Does that cover all of it?

 > > This is the problem with controlled vocabularies and one of the
 > > inefficiencies in loose tagging... not everyone uses the same term
 > > when refering to a given thing.  Think of these as tags authored by
 > > Ken Fern.  What we need is the ability to fill in what seems missing
 > > in this tag set (fodder and timber in this case).
 > 
 > IMO we need to add/edit search terms, so that if someone searches on
 > something such as 'timber' that's not in the vocab or however that's
 > working at present, it can be added.

Adding uses to individual plants will happen in 0.3.0.  Being able to
add uses to search results will probably be in 0.4.0.

 > > Implementation wise I'm planning on further abstracting the
 > > search/search results object in order to manipulate it more easily on
 > > both the front and back ends.  In terms of a user experience I think
 > > it would work something like the user searches for uses="wood".  The
 > > result of this search is save-able (think stored queries in the issue
 > > tracker and elsewhere).  The user can then create a tag titled
 > > "timber" and attach it to each result in the query.  Actually the
 > > order of operations isn't important... there could be a tag wizard
 > > that guided through this.
 > 
 > This is exaclty the kind of overhead I think we need to avoid putting on
 > the user.  This is what computers are for.
 > If someone searches on 'timber' we should return all relevant items or
 > indicate that none were found.  We should not be telling them they ought
 > to search on 'wood' instead.
 > Firewood is wood but is not timber.
 > Coppice wood is wood but is not timber.
 > Etc. etc.

What I was trying to say is that users could tag entire search results
instead of just individual plants.  

 > >  > > I would want to be able to search on 'termite resistant timber' and
 > >  > > 'goat
 > >  > > fodder', as more sophisticated examples.
 > >  > Probably wouldn't work, but Wood + Insectide..?
 > >
 > > Well, it could/would work if we universalized a bunch of the dataset
 > > as loose tags instead of column attributes.  I think this would work
 > > with at least uses and locations... maybe tolerances...
 > 
 > This should definitely work.  I can google 'termite resistant timber' and
 > get meaningful results.  I expect same from PIW, though from a different
 > DB of course.

Tagging a plant with 'termite resistant timber' would provide this
instantly.  Is this definable as a relationship?  If not is it a
attribute or output?

 > > The search results were not really intended to provide the definitive
 > > answer on the search query, but to provide information about where to
 > > look next.  Actual information about how to use a plant as a tonic is
 > > provided in the comments specifically Medical uses by Ken Fern.
 > 
 > I think they should provide focused response to the actual query.
 > That's one of the most basic 'gee-whiz' we can provide, I think.

I'm not disagreeing with you here, but this is a pretty serious
implementation task because the front end isn't really in the know
about how the back end is getting the results.  Providing that
information is going to take a bit of doing (10-20 hours).  If this is
essential to 1.0 put it in as an issue.

 > > Wait, how is the current behavior not what your suggesting?
 > >
 > > For 'tonic' in Comments:Text I get results starting with:
 > >
 > > Comment: Medicinal uses --> Plant: Magnolia virginiana
 > 
 > I'm not searching in Comments, I'm searching for Uses.
 > Why would I search Comments:Text when I'm looking for Uses:tonic?

Both comments and plant uses may have this information.  This is one
of those redundant aspects of the PFAF dataset.  Uses are just tags,
while the comments often go into detail about specific uses.  We could
migrate the tags into comments, but not the other way around for
sure.  

 > I guarantee most users are not going to RTFM (or faq or howto or
 > whatever), they are going to poke around and try what seems obvious to
 > *them*.

This assumption is why my initial search form was a single text entry
box.  No matter how much Bear polishes the advanced search form, I
suspect effective use will still elude many casual users simply
because of the [confusing] number of options.

 > > Although I agree that this would be nice it would be a fairly lengthy
 > > implementation (mostly around figuring out which search term goes with
 > > which part of which result).  If you really want need this for 1.0
 > > enter it as an issue.
 > 
 > I would like to see it happen sooner, no bandwith to enter in tracker,
 > Bear if you are willing please do and Chad if you are willing please apply
 > your creativity to this sooner rather than later.  Can always be deferred
 > if it turns out to be too big a chunk to bite for 1.0.

As I said above, I think it is a good thing to add, but I would prefer
to postpone it to after 1.0.  Currently I'm much more focused on
getting the Threshold promised features implemented than polishing the
user interface.

 > Hasta next week,
 > John S.

Cheers,
Chad