pcplantdb

[Richard Morris <webmaster@pfaf.org>]

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