pcplantdb

[Chad Knepp <pyg@galatea.org>]

Bear Kaufmann writes:
 > > Not sure exactly what you mean by regroup...we may have entirely 
 > > different
 > > understandings of this...I'll give a few examples of what I mean.
 > As a starting point, I'm thinking that many of the current values in 
 > the database can map to either input or output.
 > At a simpler level (with no real connection to the backend code) just 
 > reorganize the values in advanced search into inputs/outputs, to get 
 > this idea across to the user. Later on, the backend can implement 
 > input-output connection, etc.

Cool.  Still not sure that input/output is enough or necessary.  Is
being the color blue an input or an output?  I think what things are
is implicit.  How about one table of tags containing things like
'nitrogen fixer', 'timber', and 'grows really fast' instead of 2+
tables of further categorizations.

 > > In advanced search right now, if I search on Plant Uses for 'timber' or
 > > 'fodder' I get zero results (all other fields empty).
 > > This I assume is because there are no plants  that indicate fodder or
 > > timber uses in the current data set.
 > Just installed the DB table, and searched for unique values (Chad, I'm 
 > thinking uses_index shouldn't use a varchar for use, but an integer, 
 > related to the uses_glossary).

Not sure I follow you here, uses_index.uses is a *foreign key*
corresponding to uses_glossary.uses is a primary key.  I could add an
integer key as well, but I'm not seeing how that wouldn't be
redundant.

 > Here are the unique values (all 270):
 > Abortifacient, Acrid, Adaptogen, Adhesive, Alcohol, Alterative, 
 > Anaesthetic, Analgesic, Anaphrodisiac, Anodyne, Antacid, Anthelmintic, 
 > Antiaphonic, Antiarthritic, Antiasthmatic, Antibacterial, Antibilious, 
 > Antibiotic, Anticholesterolemic, Anticoagulant, Antidandruff, 
 > Antidermatosic, Antidote, Antiecchymotic, Antiemetic, Antifungal, 
 > Antihaemorrhoidal, Antihalitosis, Antihydrotic, Antiinflammatory, 
 > Antiperiodic, Antiphlogistic, Antipruritic, Antipyretic, Antirheumatic, 
 > Antiscorbutic, Antiscrophulatic, Antiseptic, Antispasmodic, Antitumor, 
 > Antitussive, Antivinous, Antiviral, Aperient, Aphrodisiac, Appetizer, 
 > Aromatherapy, Aromatic, Astringent, Baby care, Bach, Balsamic, 
 > Basketry, Beads, Bedding, Besom, Biomass, Birthing aid, Bitter, Blood 
 > purifier, Blood tonic, Blotting paper, Bottles, Broom, Brush, Buttons, 
 > Cancer, Cardiac, Cardiotonic, Carminative, Cathartic, Charcoal, 
 > Chocolate, Cholagogue, Cleanser, Coffee, Colouring, Compost, Condiment, 
 > Containers, Contraceptive, Cork, Cosmetic, Cotton wool, Curdling agent, 
 > Cytostatic, Cytotoxic, Darning ball, Decongestant, Demulcent, 
 > Deobstruent, Deodorant, Depurative, Detergent, Diaphoretic, Digestive, 
 > Disinfectant, Diuretic, Drink, Dye, Egg, Emetic, Emmenagogue, 
 > Emollient, Enuresis, Errhine, Essential, Expectorant, Febrifuge, 
 > Fencing, Fertilizer, Fibre, Filter, Fire retardant, Flowers, Foot care, 
 > Friction sticks, Fruit, Fruit ripening, Fuel, Fungicide, Furniture, 
 > Galactofuge, Galactogogue, Gelatine, Green manure, Ground cover, Gum, 
 > Haemolytic, Haemostatic, Hair, Hallucinogenic, Hedge, Hepatic, 
 > Herbicide, Homeopathy, Hydrogogue, Hypnotic, Hypoglycaemic, 
 > Hypotensive, Incense, Infertility, Ink, Inner bark, Insecticide, 
 > Insulation, Irritant, Kidney, Kindling, Lacquer, Latex, Laxative, 
 > Leather, Leaves, Lenitive, Lighting, Lining, Liquid feed, Lithontripic, 
 > Litmus, Manna, Microscope, Milk, Miscellany, Mordant, Mouthwash, Mulch, 
 > Musical, Mydriatic, Nails, Narcotic, Nectar, Needles, Nervine, 
 > Nutritive, Odontalgic, Oil, Ophthalmic, Oxytoxic, Packing, Paint, 
 > Paper, Parasiticide, Pectin, Pectoral, Pencil, Pins, Pioneer, Pipes, 
 > Pitch, Plant breeding, Plant support, Plaster, Polish, Pollen, 
 > Pollution, Porcelain, Pot-pourri, Potash, Poultice, Preservative, 
 > Purgative, Raffia, Refrigerant, Repellent, Resin, Resolvent, 
 > Restorative, Roofing, Root, Rooting hormone, Rootstock, Rubefacient, 
 > Rust, Rutin, Salt, Salve, Sandpaper, Sap, Scourer, Sedative, Seed, 
 > Seedpod, Shelterbelt, Sialagogue, Size, Skin, Soap, Soap making, Soil 
 > conditioner, Soil reclamation, Soil stabilization, Stabilizer, Starch, 
 > Stem, Sternutatory, Stimulant, Stings, Stomachic, Straw, Strewing, 
 > String, Stuffing, Styptic, Sweetener, Tannin, TB, Tea, Teeth, 
 > Thatching, Tinder, Tonic, Uterine tonic, Varnish, Vasoconstrictor, 
 > Vasodilator, VD, Vermifuge, Vesicant, Vulnerary, Warts, Waterproofing, 
 > Wax, Waxed paper, Weather forecasting, Weather protection, Weaving, 
 > Wick, Women's complaints, Wood.
 > 
 > I'm surprised not to see fodder in there. You might also try Wood. I 
 > think we need a better UI system then a text box. The list is long, but 
 > it is a limited set of values, so we should show them to people. 
 > Perhaps a Select Box, or break them into categories...Medical, Food, 
 > Animals, Functional...

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

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.

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

 > > I would also want to be able to enter such info when adding a plant or
 > > adding info to an existing plant, as 'outputs'.
 > > If I do advanced search on plant uses for 'tonic' I get 600+ results.
 > > In the summary text that is returned, and in the references linked in 
 > > the
 > > summary text, I do not find any information on use of the plant as a 
 > > tonic
 > > (of whatever sort).
 > > I admit I only checked the first three result items.  However if it 
 > > were
 > > visible anywhere I would assume it would be in the top results for 
 > > sure.
 > > So what is up with this??
 > > If I search on plant uses for 'tonic' and get results, I expect to see
 > > info on use as tonic in the result data...??
 > > Is this because we are only returning some kind of limited summary thus
 > > far, that does not necessarily include the actual info asked for?
 > > Or...what??

Yes, this is exactly the case.  The [changeable] summary methods for
plants and comments are in Eden.client.Plant.py and
Eden.client.Comment.py.  There is also the *tabled* results format
which omits the summary methods.  Should *tabled* be the default?

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.

 > Good comments John. I haven't added any bugs recently, but we should 
 > keep track of these things there. (Anyone care to add some).
 > Sooo...apparently, filling in most values in the current advanced 
 > search returns the plants themselves, with their summary description. 
 > If you say, fill in tonic under the comments text box, you are taken to 
 > the comments that mention tonic. Honestly this isn't very user 
 > friendly. I think the so called "comments" should remain pretty tightly 
 > bundled to the parent (plant). Ideally, the term would get highlighted, 
 > and the comment cut down to size around the search word. As in my 
 > previous mockup, a comment should should what plant it's from too, 
 > otherwise the user has no idea, what it relates too, unless the user 
 > clicks "View Parent"..I'd prefer the link to the comment just be a link 
 > to the parent's (plant) view page, with an anchor that brings the user 
 > to that comment.

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

      A tea made from the bark is antiperiodic, aromatic, diaphoretic,
      laxative, stimulant and tonic[4, 222]. It has historically been
      used as a substitute for quinine in the treatment of
      malaria[222, 238] 

The two links *Medical uses* and *Magnolia virginiana* take you to the
comment and the full plant description.

 > Note that the simple search does mix comments/plants, and searching for 
 > tonic there does show comments that match.
 > Recommended change: Comments show what plant they are for. 

I think this is already implemented unless I'm missing something.

 > Short summary text doesn't start from the beginning, but is
 > centered around the search term(s). 

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.

 > Link to comment actually links to plant view, with anchor (ie
 > view?plantid=203943#comment239903).

This is very good idea.  Please do this as an issue so I can remember.

 > Cheers,
 > Bear

Cheers,
Chad

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