pcplantdb

[Richard Morris <webmaster@pfaf.org>]

Chad Knepp wrote:
> 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...

Nice to know it works on another system though. I'll wait for next zip 
file before really investigating further.
>  > <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.
I'd say species. There are a few instances where sub species and 
varities have their own pages in PFAF DB. For instance
Allium cepa                     Onion
Allium cepa aggregatum          Potato Onion
Allium cepa ascalonicum         Shallot
Allium cepa proliferum          Tree Onion
not 100% sure if these are sub-species or varities.

There is a case where we might exceptionally want a particular cultivar 
to have its own page, when its particulary important or differs in a 
large extent from the main species. Apple cultivars spring to mind there 
can be lots of variety, with dwarfing rootstocks.

There is a case for just having, whatever the user wants as an object,
a bit more wiki like. Occasionally there are pages in pfaf db for a 
whole genus

Latin Name              Common Name     Family
Castanea species        Chestnut hybrids Fagaceae
Ceanothus species                       Rhamnaceae      
Crataegus species       Hawthorns etc.  Rosaceae
Escallonia species      Escallonia      Escalloniaceae
Fuchsia species         Fuchsia         Onagraceae      
Hemerocallis species    Day Lilies      Hemerocallidaceae       
Hosta species           Hosta           Funkiaceae
Lavatera species        Tree lavatera   Malvaceae
Lilium species          Lily            Liliaceae
Mentha species          Mint etc.       Labiatae
Morus species           Mulberry        Moraceae
Quercus species         Oaks            Fagaceae
Rubus species           Hybrid berries  Rosaceae
Sorbopyrus species                      Rosaceae
Sorbus species  Mountain Ash, Whitebeam Rosaceae

and it might be fun to have pages for families.

Then we have the guild question, are their pages for a guild.

Wacky idea: go for the anarchic approach. Whatever the users want as a 
object they can have that as an object, user picks unique identifier 
which might be a botanical name, or something else. When creating an 
object the user can import any section they want. If the object has a 
height then the user can include a height field. If the object has a 
geographical range (which might apply for guilds as well as plants) then 
the user can import/implement that that. Think wiki with structure 
rather than database. In the end it could be a more general system which 
could be used in other fields.

Whoopse not the best line in the sand ever!

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