pcplantdb

[Richard Morris <webmaster@pfaf.org>]

Stephanie Gerson wrote:

> hi folks,
>
> Is this something you could raise in less technical terms on the PIW list?  I
> think it would be a valuable discussion - not necessarily to reach a consensus
> but just to hear what folks have to say...
I think it would be good to get the framework set up first.
> ------ Original Message ------
> Received: 01:39 PM PST, 01/24/2005
> From: Chad Knepp <pyg@galatea.org>
> To: Permaculture Plant Database <pcplantdb@lists.ibiblio.org>
> Subject: [pcplantdb] DTD 0.001
>
> Ok, couple/many things... long overdue.
>
> The nomenclature aspects are mostly what I had in mind.  Also I think
> we need a lot of markup for the various atomic data elements like
> height, hardiness, etc, which you touch on with physical and growing
> conditions.

Yep. Still a lot of work to do. I kind of only got half way through.
> A lot of the rest of the existing data (the text blobs) I would like
> to move to a more universal context such as that of a comment.  These
> include cultural notes, propagation notes, know hazards, edible uses,
> medicinal uses, and other uses.  These could be as individual comments
> or grouped together as a single comment by Ken Fern.  This is a point
> that needs additional discussion.
I've mentioned elsewhere about a "Section" concept. In XML
<section name="Edible Uses">
        Yummy.
</section>

> I also want to check in about the time frame of moving to a fully
> XML'ized version.  This represents a significant amount of work that
> does benefit the development of additional clients but not much else.
> Currently there is not really much movement to develop additional
> clients so I think full XML'ization could be postponed as a future
> funded becomes available.  
Yes I beleive so. In view of time issues, its probably best to
concentrate on other issues for now, allowing user input seems to be the 
top priority for now.

> As the end product I would like to provide methods that completely
> XMLize the data, but also provide shortcut methods (for optimization
> reasons) that handle formated content.  More specifically what I'm
> referring to is DescribePlant method in Kfml.py (lines 106-245) which
> takes over 30 data items and makes a paragraph instead of wrapping XML
> around 30 items handing it to the client and let the client unwrap the
> XML and turn it into a paragraph.  In the short term the shortcut
> methods would be the first available.  As custom clients need/demand
> real XML the detailed methods can be filled in.

Yep, this is a kind of human readable/machine readable distinction.
Do really need to produce both depending on the client.

> Richard Morris writes:
>  > // classification issues
>  >   <Systematics>
>  >   <Rank>Species</Rank> // What level in family tree this is
>  >   <ParentName rank="family">Salicaceae
>  >           <ClasificationScheme>Conquist</ClasificationScheme>
>  >   </ParentName>
>  >   // by using a ParentName rather than a family tag
>  >   // it might make it easer to represent objects which are
>  >   // higher up the tree.
>  > 
>  > 	// For a cultivar we might have
>  >   <Rank>Cultivar</Rank>
>  >   <ParentName rank="Species">Salix negra</ParentName>
>  > </Systematics>
>
> I don't really understand this.  What exactly is systematics and does
> it currently exist in the dataset?

Basically how to encode where the plant lives in the family tree of 
plants. We have a big tree representation with level
        Species, Genus, Family, Order, Sub Class, Division.
It would be nice to find higher levels for each object.

It could be easiest just to refere to the next level up, ie
a Genus refers to a family, a family refers to an order and order refers 
to a Sub Class etc.

We can get this data from UDSA.

>  > <warnings>
>  >   <HealthWarning>Eating this tree whole is for your health</HelthWarning>
>  >   <Invasive>Listed as noxious/invasive for:
>
> I personally don't believe in concepts like 'invasive' and have some
> resistance to perpetuating that mindset.

Problem is there are lots of introduced plants which can cause big 
problems. In the UK Japanees Knot weed is taking over all our rivers
and smothering out all the native plants.

SOme of the very first comments we had on the PFAF site were on this issue.

To be responsable I strongly beleive we shou;ld include this. There is 
also a leagal requirement in some cases it is illeagal to grow some 
plants in certain areas.


>  >           // How we represent places in world is a big
>  >           // issue, we touched on it back in the archive
>  >           <location>
>
> I think we should have a <locale> tag instead of location and a clear
> definition of what a locale is.

Yes, much better idea.

>  > <GrowingConditions>
>  >   <SoilType>...<SoilType>
>  >   ....
>  > <GrowingConditions>
>
> These are examples of the many small items that we have in the dataset
> that may not have immediate methods available... there are probably
> close to 40

Yep, get some system for encoding these.
>  > <EdibleUses>
>  >   // An example of a free text entry (CDATA) with some inline tags.
>  > 	<Keyword>Inner bark</Keyword> - raw or cooked. It can be dried, ground 
>  > into a powder and then added to cereal flour for use in making bread 
>  > etc. A very bitter flavour, it is a famine food that is only used when 
>  > all else fails <reference><book>...</book></reference>
>  > Young shoots - raw or cooked. They are not very 
>  > palatable<reference><book>...</book></reference>].			
>
> I like the <reference><book> tag idea, and can think of subtags for
> <reference> 
>
>  > </EdibleUses>
>  > 
>  > </plant>
>
> I still have a lot of questions about comments that I don't even know
> how to articulate.  A lot of the issue for me is about how to create
> (or not) subject/topics and how to display different comments based on
> what criteria.  Things like EdibileUses seems like the topic of a
> comment, but is it one comment under a fixed topic, or a subsection of
> a general comment about a given plant?  

Must dash.

Rich