Skip to Content.
Sympa Menu

pcplantdb - Re: [pcplantdb] comments on 0.2.0

pcplantdb@lists.ibiblio.org

Subject: pcplantdb

List archive

Chronological Thread  
  • From: Chad Knepp <pyg@galatea.org>
  • To: pcplantdb <pcplantdb@lists.ibiblio.org>
  • Subject: Re: [pcplantdb] comments on 0.2.0
  • Date: Thu, 21 Jul 2005 11:18:39 -0500

Stephanie Gerson writes:
> a few responses IN CAPS:
> >
> > 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.
> >
> It depends on the type of search. For plants there is a lot more order
> in the names I've found it easier locate plants when they are arranged
> alphabetically.
>
> A table based layout could be a way round this there could be three
> columns
>
> Botanical Name|Common Name|Ranking|... other stuff we want to display
>
> a user could click on a column heading to order by that field.
> Alternativly this could be in a user preference or a set of radio
> buttons.
> URL could end with &ORDERBY=Common etc.
>
> CAN'T USERS SORT BY DIFFERENT CHARACTERISTICS? SORT ALPHABETICALLY, BY
> RELEVANCE, BY USER RANKING, ETC.?

I think I'm beating a dead horse here, but if you can understand why
Google doesn't sort alphabetically then you can understand why I also
think it's a bad idea. Google displays the results first that it
thinks are the closest match to your search query. Alphabetizing the
results would cause the best matches to placed in some arbitrary
location based on spelling not on relevance to the search query.
PIW/Eden works the exact same way and focuses on creating search
results that are arranged hierarchically according to perceived
relevance. Alphabetical arrangement could be implemented in the
client (client/Search.py) but I'm not into creating something I think
will detract from the end product. I need cranky screaming users
waving pitchforks before I will willing add this option.

Currently we don't access the PFAF rating and don't have a user
rating. As we discussed earlier, a moderation system (although
important to some folks esp. me) is not currently slated for
implementation in PIW 1.0. Adding/editing plants and plant data,
locales, and relationships are the major tasks left IIRC.

> >>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.
> >
> SURE, LET'S DEFINE THE GRAMMAR. CAN YOU PLEASE POST SOME SPECIFIC
> QUESTIONS/ISSUES FOR US TO DISCUSS?

With the advent of the advanced search, I'm inclined to let this one
slide a little. How about after locales and relationships?

> >>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.
>
> THAT WOULD MAKE IT A LOT EASIER. IT'S INTIMIDATING TO GET SO MANY 'HITS'
> SOMETIMES. ESPECIALLY SINCE THERE ARE NO PHOTOS (YET), IT'S HARD TO TELL
> WHICH RESULT IS THE ONE YOU SEARCHED FOR WHEN THERE ARE SO MANY.

What I've been trying really hard to do is make the result you want be
the first one. If this is not the case or it's not on the first page
then either the search query needs refining or I have more work to do.

There are 32090 comments and 7396 giving a total of 40786 possible
hits. I'm having trouble undestanding why number of hits is a
problem, esp. when this will likely grow to over 100000 possibilities
as we start adding stuff. Are the number of results returned from
Google problematic? Does anyone even look at that anymore? I did a
search on Google for 'laetrile' and got 54500 hits... hmmm PIW only has
13, 7 of them are false positives where botanical names match the
substrings.

> >>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.
> >
> SOUNDS GREAT! LOOKING FORWARD TO CHECKING OUT THE ADVANCED SEARCH YOU
> JUST RELEASED.

I'm fairly pleased with the functionality. I think PIW/Eden now has a
definable slight advantage over PFAF in that the advanced search will
allow you to search any and all elements of the dataset in one query.

> >>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 ;-)
>
> WILL THERE BE A WAY TO DO THIS?

Yes, I think I'm going to tackle adding/editing plant names and
attributes next.

> The reason you get matches
> > for it is because the sub-strings in chayote, 'chay' and 'ote' are
> > found as parts of other names.
> >
> OY VE. THIS SUB-STRINGS THING COULD BE PROBLEMATIC. I.E. WITH PLANTS
> THAT HAVE NAMES OF COLORS IN THEM. HMMM... OR WILL RELEVANCE CLEAR THIS
> UP?

It is, but only in the basic search.

> >>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?
>
> In some sense that is the correct behaviour, i.e. it gives the members
> of that family. There are some shared chateristics of families don't
> have too much real data for this.
>
> BUT WHEN IT COMES TO COMPANION PLANTING, ITS OFTEN FAMILIES THAT GROW/
> DON'T GROW WELL TOGETHER...
>
> Have a look at
> http://www.ibiblio.org/pfaf/D_fam.html
> and see if you can spot the similarities.
>
> I'LL CHECK IT OUT TOMORROW, ALONG WITH 0.2.3
>
> NIGHTY NIGHT,
> *s

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




Archive powered by MHonArc 2.6.24.

Top of Page