pcplantdb@lists.ibiblio.org
Subject: pcplantdb
List archive
- From: "John Schinnerer" <john@eco-living.net>
- To: "pcplantdb" <pcplantdb@lists.ibiblio.org>
- Subject: [pcplantdb] PC centricity
- Date: Sun, 31 Jul 2005 13:21:36 -1000 (HST)
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.
> 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.
> 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.
> > > 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.
> 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.
> 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?
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*.
> 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.
Hasta next week,
John S.
John Schinnerer - MA, Whole Systems Design
------------------------------------------
- Eco-Living -
Whole Systems Design Services
People - Place - Learning - Integration
john@eco-living.net
http://eco-living.net
-
Re: [pcplantdb] a few things...
, (continued)
-
Re: [pcplantdb] a few things...,
Lawrence F. London, Jr., 07/29/2005
-
Re: [pcplantdb] a few things...,
Bear Kaufmann, 07/30/2005
- Re: [pcplantdb] a few things..., Lawrence F. London, Jr., 07/30/2005
-
Re: [pcplantdb] a few things...,
John Schinnerer, 07/30/2005
- Re: [pcplantdb] a few things..., Bear Kaufmann, 07/30/2005
-
Re: [pcplantdb] a few things...,
Bear Kaufmann, 07/30/2005
-
Re: [pcplantdb] a few things...,
John Schinnerer, 07/30/2005
-
Re: [pcplantdb] a few things...,
Bear Kaufmann, 07/30/2005
-
Re: [pcplantdb] a few things...,
Chad Knepp, 07/31/2005
- Re: [pcplantdb] a few things..., Lawrence F. London, Jr., 07/31/2005
- Re: [pcplantdb] a few things..., Bear Kaufmann, 07/31/2005
- [pcplantdb] PC centricity, John Schinnerer, 07/31/2005
-
Re: [pcplantdb] a few things...,
Chad Knepp, 07/31/2005
-
Re: [pcplantdb] a few things...,
Bear Kaufmann, 07/30/2005
- Re: [pcplantdb] a few things...search, PC-centricity, John Schinnerer, 07/30/2005
- Re: [pcplantdb] a few things..., Lawrence F. London, Jr., 07/29/2005
-
Re: [pcplantdb] a few things...,
Lawrence F. London, Jr., 07/29/2005
Archive powered by MHonArc 2.6.24.