Skip to Content.
Sympa Menu

pcplantdb - [pcplantdb] comments on 0.2.0

pcplantdb@lists.ibiblio.org

Subject: pcplantdb

List archive

Chronological Thread  
  • From: Chad Knepp <pyg@galatea.org>
  • To: pcplantdb@lists.ibiblio.org
  • Subject: [pcplantdb] comments on 0.2.0
  • Date: Sun, 17 Jul 2005 14:55:03 -0500

Responding to Stephanie's private email on the list because I think it's
good stuff.

> Should uses (i.e. hedge, cancer) be capitalized like the other
> headings are?

Either capitalized or not but all the same, unlike the actual data
which has some of each. I just did a string.lower(use), but could
change it to string.upper(use[1]) pretty easy. What do others think?

> Results take the form of ``Family name [space] Genus + Species name.''
> For example, a search for co rn gives ``Gramineae Zea mays.'' I fear
> that users will click on the family name thinking that it w ill take
> them to the plant (in this case, Zea mays) and will not realize that
> this is what they did . Can we perhaps put the family name on another
> line, or separate both with a comma? For example:
>
> Zea mays
> Gramineae
>
> Or
>
> Zea mays, Gramineae

This is where I like to take direction from Bear. I get the confusion
though. I prefer the later (one line) and will go with that until I
hear different from Bear.

> In what order are search results returned and why? (How is order
> determined?)

Order is determined by relevance score, the number on the left. One
of the reasons I think that sorting alphabetically is a bad idea is it
ignores the context of relevance. Alphabetically sorted a search
result may have the best match somewhere in the middle or near the
end. Tell me again why this is good... I mean imagine if google
sorted results alphabetically. I put a visible relevance score back
into 0.2.0 so folks can see it. Rich suggested translating this into
different sized graphics (trees) at one point.

> Is there a limit to how long search strings can be? Because I searched
> for ``ground cover perennial shrub edible drought tolerant nitrogen
> fixer'' and it only returned ``ground cover perennial shrub edible.''
> I don't think there should be a limit to search string length.

Yes, I limit it to 5 words in the general search for performance
issues. This does need an upword limit (but could be larger than 5)
because of possible malacious uses such as the inserting the contents
of Moby Dick. Eden: Ishmael, hmmm, I'm not finding anything...

Interesting though, most of those words in your example are part of
the controlled vocabulary. Should have produced interesting
results...

> Are you planning to incorporate +, AND, OR (Boolean features)?
> Currently, it ignores lower case and , but seems to include upper case
> AND without actually using it. I'm a bit confused are you still
> working with this?
>
> Also, it seems to ignore quotation marks if I want to search two words
> together (i.e. ``three siste rs). Can we incorporate quotation marks
> to keep multi-word terms intact?

Both of these things are what I mean when I alluded to a search
grammar. I think this would make a good feature request if we can
agree on the definition of the grammar.

> Perhaps we should include a page on search help, helping users search
> most effectively. But I assum e the searching capabilities are still
> evolving?

Good idea, but yes, we are still settling the actual feature set.

> I seem to get way too many results, but as I mentioned above, I assume
> search capabilities are stil l evolving (and will allow for more
> refined searches that will return less results).

I don't think that too many results is a problem if they are sorted by
relevance. If you look at the scores on the side usually only about
1% have a relevance greater than 1. It could be a client side option
to limit the results to scores greater than 1 insuring a higher degree
of relevance.

> I got 148 results for ``corn'' and 3179 results for perennial corn we
> need quotation marks and/or +, AND!
>
> It seems that the easiest/most common search users will want to do
> will be to search for all variet ies of a given plant, i.e. corn. But
> when I search for corn, I get all plants with any reference to
> corn. So I try searching by family, but that includes many things that
> are not corn. So I try sear ching by genus (``zea'') and I get
> anything with ``zea'' in it (New Zealand, etc.) and I didn't eve n get
> corn! There must be a way to get the results I want all varieties of
> corn considering that this will be a very common search. How to make
> this possible?

This is because there is only one search method in use and it happens
to search everything in the dataset. This is good for somethings, but
as you can see fails at more targeted searches. I think that
development of this area in particular will be the most rewarding for
end users. In particular I would like to make an advanced search form
that allowed searching any and all of botanical name, common name,
uses, attributes, cultivars, comments (Ken Ferns mostly), references,
and users. Press one button and bingo much better results.

> I searched for chayote and got many results, none of which are chayote
> or say ``chayote'' anywhere in their description. What's going on?

select * from botanical_name where common_name ='chayote';
Empty set (0.23 sec)

Chayote is a common name not currently in our dataset... Hmmm, maybe
we need a way to add more common names ;-) The reason you get matches
for it is because the sub-strings in chayote, 'chay' and 'ote' are
found as parts of other names.

> If you click on a family name, it simply takes you to search results
> for that family. I assume we w ill elaborate here, add info about that
> family? Family info seems critical to relationship-building and
> substitution, right?

Not sure I'm following you here...

> Right now, when you click on a use, i.e. hedge, there is no way to go
> back without pressing the bac k button. We should add a button ``back
> to search result,'' and/or add the option of searching by u se
> (clicking on hedge would give you another list of plants that could be
> used as hedges, and you c ould do an advanced search to limit search
> results).

Not sure I agree with this. We also don't have back to previous page
buttons anywhere else either. Wouldn't we need those as well?

Good stuff. Lots to talk about.

Cheers,
Chad

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




Archive powered by MHonArc 2.6.24.

Top of Page