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: Chad Knepp <pyg@galatea.org>
  • To: pcplantdb@lists.ibiblio.org
  • Subject: Re: [pcplantdb] Richard Re: dataset and client/server API
  • Date: Mon, 9 Aug 2004 15:10:13 -0500

Hiya Richard,

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

Richard Morris writes:
> Chad Knepp wrote:
> <snip>
> > 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.

Yep.

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

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

4) Moderated collaboration with different editing methods for
different types. 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.

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

Yep.

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

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

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

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

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

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

--
Chad Knepp
python -c 'import base64;print base64.decodestring("cHlnQGdhbGF0ZWEub3Jn")'




Archive powered by MHonArc 2.6.24.

Top of Page