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 23:33:01 +0100

Chad Knepp wrote:

Hiya Richard,

Could you also say where you are it in terms of using Zope as the
development platform?

If it can run on ibiblio then fine.

No progress beyond going to the bookshop and wondering if
it was worth investing £25 in Python in a nutshell.
Might try to get it second hand!

What do I need? Python, Zope, ZODB, (Z)Catalogue.

To me the object model of web applications is pretty straightforward.
The primary event driven object is a Session. This can be a single
transaction with an anonymous user or a complete login/use/logout
series of transactions. Because http is a connectionless protocol you
kind of have to fake multi-transaction session persistence with
cookies or some such. The Session object is involved with the
manipulation of other objects like Users, Plants, Comments, Searches,
and their inter-relationships. Generic Sessions can be subclassed to
accommodate other types of interactions, like RSS clients, WebDAV,
ftp, CLI tools, etc...

This is the sort of stuff I'd prefer to leave to some
third party package. I can see a lot of work involved in session management, lots of security problems and a lot of work
to get it working sweatly without falling over lots.
I'm sure other groups have spent years getting this right.
Does zope do this sort of stuff?

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

The difference between 2) and 3) are mostly client issues. The
backend implementation could be the same for each.

Provided the backend is style 3) if we represented data in style 2
then we loose all structuring.

4) Moderated collaboration with different editing methods for
different types.

Even better.

> I personally like a narrower approach than
appendthing.php, like the ability to just edit the soil type.
Moderation is the key to sorting the good information from the
less good. I don't really have a good idea on how to display
differing information in a non-confusing way.

Yep I was not at all happy with appendthing.php
a very ugly interface. Far too much stuff to fill in,
which would put a lot of users off.

Lots of thunking needed to get this sweet.
There are basically three things
1) enter a whole new plant.
2) ammend one field in existing data
3) ammend multiple fields

If someone wants to do a major edit changing several fields
then it could be a real pain if they had to do each separatly.

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

Yes I was thinking our plant object would be a superset of the PFAF
plant attributes.

Cool, although I think there are some problems with the
structure of some bits of pfaf db.

I've cc an email to you (off list) which gets down and dirty
with the plantlocations table, which is full of duplicates
and to my mind could do with some major work.

> b) Have a set of key word/controled voclabulary (for things like a plant > use, or habitat) searchable and easily extractable.

Sure.

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

Ideally this display should have customizable verbosity set by the
user with options like no photos for dialup connections, top ten
relationships, terse plant summary, etc. Cookie based user preference.

Sound good. I've added a printable version (long and short)
displays to main pfaf website. These miss a fair bit of stuff
off like the form for adding comments and the full list of references.

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

Sure.

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

Yes HGObject (and all subclasses) will implement an interface that
includes methods like summarize. In Java this would be an abstact
function. Something like...

class HGOBject:
def summarize(self, verbosity='medium'):
"Returns a text string summary of object"
"verbosity settings include:"
" 'terse' less than 81 characters"
" 'medium' less than 401 characters"
" 'full' complete summary"

return "Stub method summarize of HGObject " + self.id

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

Just tell me how you want it. I can return a list of plant.ids. What
I mean by "write API" is you just imagine what method/function you
want to call and what the output should look like. Maybe something
like...
method search(string)
return list_of_plant_ids

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

Yep pretty much like that.

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

Catalog will do that automagically.

Cool.

Hopefully we can also do something like

Plant plant = getPlant(????)
foreach(latinName in plant.BotanicalSynonyms)
{
print latinName.SpeciesName() . latinName.author;
}

Note use of SpeciesName() method constructs species name from
the Genus and Taxon elements.

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

Sure. Many python programmers use that convention as well.

Great, is this another decision?

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

While this is a nice demostration of inheritance, hard-coding
information about off site links is a bit questionable. When
plants.usda.gov switches to Zope (;-) we would have dig into the
backend and change this. I think this information would be better as
data not method, possibly as a attribute of the object in the form of
a list of urls.

I'd say this is the neatest way to do this. If the external source
changes then is just one edit to the getURL method and its done.
Having to change 7000 URL's does not sound like fun to me.

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

Yes, I even began a merge of the dataset with Eden, but there were
only 600+ plants that matched from both datasets. I did contact them
and they pretty much said it was public domain but the
required/desired (it was unclear) attribution. Structurally we may
want to adopt some of the attributes used in this database. I forget
what specifically intrigued me though...

The overlap might be bigger. Problem stems from different datasets using
different Latin names. Its very likely that different names have been used. Unfortunatly there is currently no gold standard for accepted names and they do change over time as the botanical community is getting more info on how plants are related.

Some sort of cross referencing to go from our nomaculture to other datasets is a vital componant. I had a truely big database 100MB
which handled this cross referencing.

nighty night

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