pcplantdb@lists.ibiblio.org
Subject: pcplantdb
List archive
- From: Chad Knepp <pyg@galatea.org>
- To: PCPLANTDB <pcplantdb@lists.ibiblio.org>
- Subject: Re: [pcplantdb] ahhh
- Date: Thu, 30 Sep 2004 14:44:48 -0500
Richard Morris writes:
> <snip>
>
> > > Not sure how to get it running at home, any pointers?
> >
> > If you unzip/untar it into $ZOPEINSTANCE/Products/ and then restart
> > Zope you should be able to add HG elements from the ZMI. As I said
> > before, it is not very usable. In fact that release was pre
> > manage_AddProduct which was preventing me from adding HG objects to
> > HG... ack!
> >
> OK I'll give it a go. Indeed it seems to work and I can now create an
> HGPlant object. Strangly it seems to be named with just the epiteth of
> the name so Salix alba apears as just alba. Cool.
Actually I don't think it's really worth your time trying to use what
I put out there. I think it's best use is to look at the code and see
where I'm going. It is still all in flux even then...
> <snip>
>
> > > I'd feel easier if the Botanical Names and Common names each had
> > their
> > > own classes. I think this could be useful in the long term when we
> > might
> > > want to expand the types of name allowed, (say if we want to add a
> > > language for a common name, or if we have a rose specalist who's
> > > interested in forma). These also advantages if the accepted name and
> > the
> > > synonyms shared the same type.
> >
> > This will probably be the case, common names being a subobject of the
> > plant root. One thing I need to know from the group is what
> > constitutes a unique plant root object. I think the line between what
> > is a cultivar or very minor subspecies is perhaps a little fuzzy. One
> > thing we could do is have subobjects be children of multiple plant
> > root objects where the information was sufficiently similar.
>
> Yep. There are advantages of such a scheme. In pfaf dataset the "known
> hazzards" section is often the same for all the plants in a family.
> By having each plant in a family point to the same "Hazards" object
> would save replication. Slight worry that this might make things more
> complicated, KISS (Keep it Simple Stupid).
Yes, I'm worried about the complications too, not from an
implementation perspective, but from a user one. I think it would be
good to introduce set objects that are collections of other objects
(such as all plants of a family) in order to define things like the
above. Specifically for 'Hazards' and data imported from third
parties, I'm ok with some replication but when users want to start
defining relationships we are going to need to come up with a way to
group objects together and define their relationship with other
objects. This is kind of an advanced idea that I'm not sure how to
explain easily to users that have a lot more experience in the field
than in front of a computer. Implementation wise any search result
could be transformed into a set. Even better, these sets could be
dynamic ones that actually execute and return search results when
called thereby keeping up with changes.
I think is sort of a user interface thing. In order to create a
relationship between elements you first have to select the elements to
relate, if this is more than one element you have to group them
together somehow. This seems like a pretty complex process. How can
we make this easy?
> > Anyway,
> > my question is what combination of nomenclature should we use to
> > identify a unique plant in the context of what will be the most useful
> > division to our users.
>
> For a botanist the full species name including the author is used as a
> unique identifier. UDSA uses a short code string SAL01 etc. I've found
> it nice using a species name "Salix alba" which makes it easy for third
> parties to work out the URL for each plant
> http://www.comp.leeds.ac.uk/cgi-bin/pfaf/arr_html?Salix+alba
> its also had minor development benifits as I can easily find the records
> in each table for a particular plant without having to remember its
> special code.
Specially is this family, genus, species, ... and what else? And
which combination of name bits should be a unique plant that can be
fully represented if it also contains info on
cultivars/forma/varieties or the like...
Essentially I'm looking for a somewhat arbitrary line, but a real
line, in this botanical name stuff to say this is a unique plant and
all the deviations below this level can be adequately expressed by
subobjects.
--
Chad Knepp
perl -e 'print pack"H*","7079674067616c617465612e6f72670a"'
-
[pcplantdb] ahhh,
Chad Knepp, 09/25/2004
- Re: [pcplantdb] ahhh, Lawrence F. London, Jr., 09/25/2004
-
Re: [pcplantdb] ahhh,
Richard Morris, 09/27/2004
-
Re: [pcplantdb] ahhh,
Chad Knepp, 09/30/2004
-
Re: [pcplantdb] ahhh,
Richard Morris, 09/30/2004
- Re: [pcplantdb] ahhh, Chad Knepp, 09/30/2004
-
Re: [pcplantdb] ahhh,
Richard Morris, 09/30/2004
-
Re: [pcplantdb] ahhh,
Chad Knepp, 09/30/2004
- <Possible follow-up(s)>
- Re: [pcplantdb] ahhh, Stephanie Gerson, 09/27/2004
Archive powered by MHonArc 2.6.24.