Skip to Content.
Sympa Menu

pcplantdb - Re: [pcplantdb] Richard Re: dataset and client/server API

pcplantdb@lists.ibiblio.org

Subject: pcplantdb

List archive

Chronological Thread  
  • From: Richard Morris <webmaster@pfaf.org>
  • To: pcplantdb@lists.ibiblio.org
  • Subject: Re: [pcplantdb] Richard Re: dataset and client/server API
  • Date: Mon, 09 Aug 2004 13:25:35 +0100

Chad Knepp wrote:

This is mostly to Richard, because we need to start talking about the
client/server API and other things.

Great, yes I think this is timely to.

First off, I would like to get the latest version of PFAF that is
under the CC-BY-NC-SA with or without the images, either as a MySQL
dump or as a CSV fileset with a SQL import script. This isn't super
time critical, but it would be nice to have this by the end of next
week or so. Can you put this somewhere on comp.leeds.ac.uk or ibiblio
for download?

Yes I hope to do this v soon. I'll need to get the database
from Ken. Two weeks sounds good as while I'm redoing the
pfaf website I'm uncovering various minor bugs which ken is
fixing, so we be getting a better dataset if we wait a little
time. I do hope to proceed quickly on this (modulo rest of life).

Secondly, I'm thinking that if the client is written in PHP on top of
Zope it will really make more sense to just describe a
method(value[s]) API than to generate and tanslate XML between the
two. We can easily generate XML for other sorts of
clients/applications but for this particular instance I think a
tighter coupling is the better choice. In terms of proceeding it
would work for me if you just write your fantasy API and I will
implement the methods you need on the backend.

Interesting. I've been thinking a bit about a requirement driven
spec. If we get a good list of requirements then the object model
may fall out of it.

Someting like

The permaculture.info project must
a) Hold data about a plant
b) Hold data about other objects/concepts not necessarily just a plant
c) Hold images, (and later other data formats like mp3's)

The pc.i should
a) allow extensive cross linking (guilds relationships, etc)
b) allow editing and adding of more info
c) be extensible, in that new fields can be added at a later date
d?) Allow locilisation of info. Fruiting times are different
in the UK, US and Australia and tropics.

NOTE: I think b) has a very profound impact on the
object design.

Posible models:
1) Just comments as in current pfaf website
simpliest to do. Just use another table with
an index field and text field (also datestamp, user info etc)
Just displayed by appending contents of text fields
to bottom of main database results.

2) Wiki style. Info on plant is basically just a flat
unstructured text field. Sucessive edits are stored either
as diffs between versions of the page or snapshots
of the page. (also quite similar to cvs)

3) Intericatly interweaved. As in the demo interface
www.ibiblio.org/pfaf/pcplantdb/index.php
I posted a few days back. Plant data is divided into sections
in each section wiki style edits are allowed.

Back to requirements

The plant data should
a) Allow synonyms for plants. Multiple botanical names which can refer to the same plant (possibly with one accepted name).
b) Allow multiple common names for plants (possibly with locilisation info describing where the name is used and which language it is in)
c) Allow multiple family names (these are changing at the moment
for instance the Carrot family has changed from Apiaceae to Umbelliferae).

The plant data may (we will probably want to discuss this further)
a) Have certain numberic fields like height, width, pH range
which can be searched and extracted from database.
b) Have a set of key word/controled voclabulary (for things like a plant use, or habitat) searchable and easily extractable.

API specs: (what the client will need to do)
a) Display complete info page for a plant, with all photos,
relationships. (Also compleate info at a particular time point
or a particular edit)
b) Enable different search stratergies
- free text search
- keyword matching searches
(return plants which match a given keyword)
- field searches, allow specific searches for a combination of characteristics. So the user can put in the charcteristics of their plot (pH, moisture, shade, etc) and find plants which match.
- browse facilities, giving indexes of all latin names
common names, plants a with a specific use etc.

c) Summary of search results, allow synopsis of info about the plants from a particular search. Giving partial info about the plants returned
say returning the Latin/Common names, height and width of plants.

So we need some way to communicte a search from
client to server. Some way to extract info, either full of partial.

Complex Objects

So what is inside the Plant object?
As mentioned above there can be more than one latin name
and more than one common name. This means that we cannot have
just a simple object with elementary fields. The plant object
will have to contain fields which are lists

class Plant
Int ID - unique id for this plant
List BotanicalSynonyms
List CommonNames
....

Might want somesort of hashtable for names so can use a two way
reference beteen the name and the ID. So for example we can
find the id's from a search for a name and find the names for a given id.

Nameing scheme

I think now is a good time to decide on a naming system for classes/objects. Id propose that we follow the Java guidlines
where objects have names like BotanicalSynonyms rather than
botanical_synonyms (i.e. use capitilisation at start of words and no underscores).

External references

Been pondering a bit on how links to other databases could be done
If we want to link to the the Conservation Plant Characteristics at
UDSA's plants database we use a url like

http://plants.usda.gov/cgi_bin/plant_attribute.cgi?symbol=ACPS

where ACPS is a unique identifier used by Plants. In this instance is the ID for sycamore maple (Acer pseudoplatanus L.). Each dataset
has their own particular way in which the url's are constructed.

A nice object model might include

class ExternalReference
abstract String getURL()

class UDSAReference extends ExternalReference
String symbol

String getURL() {
return "http://plants.usda.gov/cgi_bin/plant_attribute.cgi?symbol="; + symbol;

So for each dataset we could have separate object, specific methods in those objects do the work to generate urls etc.

Stuff like this is really where an object model comes in handy
when we really use "encapsulation" linking data and methods.


Finally I'd recomend everyone has a look at the UDSA plant charteristics data they have some really extensive coverage of lots of useful info about a Morphology/Physiology, Growth Requirements, Reproduction, Suitability/Use. It is posible that we may be can include this data (as far as I can make out they only require atribution, but should contact them first).

time for lunch

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