Skip to Content.
Sympa Menu

pcplantdb - Re: [pcplantdb] ahhh

pcplantdb@lists.ibiblio.org

Subject: pcplantdb

List archive

Chronological Thread  
  • From: Richard Morris <webmaster@pfaf.org>
  • To: PCPLANTDB <pcplantdb@lists.ibiblio.org>
  • Subject: Re: [pcplantdb] ahhh
  • Date: Thu, 30 Sep 2004 19:57:44 +0100

Chad Knepp wrote:
Richard Morris writes:
> A slight concern about using HG throughout the code base.
> I supose its a bit of an in joke and we will need to explain it to > everyone who comes along. The danger is that five years done the line we > may be cursing the HG tag. We should at least explain the HG tag > somewhere high up in the documentation.

Sure thing.

Cool.

> I've had a quick browse through the code base Chad uploaded,
> seems like theres a lot of work there.
> > 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.

> Cultivars seems to be missing from the names bit. These are quite > important in the pfaf db as there are lots of different apple cultivars > some of which have different growing requirments.
> > There is a design decision here, should cultivars be a plant in their > own right (i.e. an instance of class Plant) or as in the pfaf db
> as a set of properties depending on a particular plant.

Implementation wise, I've been thinking that the root plant object
would actually only be a unique set of identifiers such as botanical
name. Everything else would be a subobject that held this root as
it's parent. This would allow the cleanest sort of localization
implementation I could think of, where localized info is just an
additional subobject and queries can select the object for localized
info if it exists. Additionally this would allow the possibility to
annotate/comment on any element/subobject. As a data structure this
will end up looking like a non-binary tree. Cultivars would be a
subobject of a root plant object that had cultivar specific info.

Indeed sounds sensible. How we manage revisions to plants so we can keep some sort of history of changes might work well with this scheme.

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

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

> We may also end up with a very heavy weight plant class with all the > properties in it (hence harder to modify). Splitting the plant class > into a main container class which have a number of smaller classes > making up the whole could make for an easier object hiearachy.

I think we are on the same page here...

Indeed, a refreshing change!

Rich


--
Plants for a Future: 7000 useful plants
Web: http://www.pfaf.org/ same as http://www.comp.leeds.ac.uk/pfaf/
Post: 1 Lerryn View, Lerryn, Lostwithiel, Cornwall, PL22 0QJ
Tel: 01208 872 963 / 0845 458 4719
Email: webmaster@pfaf.org
PFAF electronic mailing list http://groups.yahoo.com/group/pfaf







Archive powered by MHonArc 2.6.24.

Top of Page