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: Tue, 10 Aug 2004 15:29:04 +0100

John Schinnerer wrote:
Aloha,

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


c) is BLOBs, basically - up to you how to handle this on back end Chad.
They're all just data files...would be good to have an attribute identifying media/file type. MIME standard would be one way.
I strongly suggest *not* just hoping the file extension will identify it well enough! :-o
I'll break that when I test it with a file attachment from a Mac... ;-)

Yes they are BLOBS in terms of how they are actually stored.
At a higher level up the system we may want to embed the blob
in a suitable wrapper class

class Blob

class Image extends Blob
int getWidth()
int getHeight()
String getAltText()

class JpegImage extends Image

At the end of the day what we need to do for the html page
is produce the html code

<img src="IMGURL" width="400" height="300" alt="Photo of a bannana">

where the IMGURL is whatever URL which will access the image.
The server will have to return the correct mime media type for IMGURL
in its HTTP response headers.

May well want to attach other various metadata to images and such like,
author, title, latin name of plants.


Micro task: get system to return a page with an image in it.

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.


This goes back to one of our grantor's suggestions - two kinds of moderation.
One for relatively "hard" data, the basic stuff, where some limited group of knowledgeable people make sure this sort of data is as correct as it can be known to be.
One for more "soft" types of data coming in from the larger community - situational, locational stuff that may have more narrative/freeform content than the more basic "hard" data. This could be (as Jim suggested) a peer-group moderation system (as on eBay, etc.) where people get rated as to the usefulness, validity, etc. of stuff they put in. Cream floats, bovine excrement sinks...

My tendancy is not to go overboard on moderation for stage 1.
Initially we will not have that many users so manual moderation
by us will do. I think we should focus of getting a product out the door.

> b) Allow multiple common names for plants (possibly with locilisation > info describing where the name is used and which language it is in)


Definitely useful...here in Hawai'i (and only here afaik) casaurina is called "ironwood"...took me a looong time to find out what "ironwood" was...lots of other things are called "ironwood" elsewhere in the world...

While this is a nice demostration of inheritance, hard-coding
information about off site links is a bit questionable.

Very questionable. I will break it when I test and it will be a bug... :-)
This has to be something like...


Chad:
...data not method, possibly as a attribute of the object in the form of
a list of urls.

Methods not data! First rule of OO design don't expose your
data, expose methods. Rather that

class UDSALink
public String url

have

class UDSALink
private String url
public String getURL() { return url; }
// or something more complicated.

in the latter case its easier to change the method if needed, in the
first case we are tied forever to an internal representation of a url
as a String.

I have plenty of examples of this on my own long-unmaintained resource links pages. Some of the gov't. sites are the worst! Bureaucratic shuffling, webmaster job security, I dunno...they tweak little bits of the URL because some agency moved to some other sub-agency, and everything is broken (again)...

Theres a nice way of handelling this on mathworld. Besides
each link is a little "fix broken link" button, so we can, to
some extent, let our users do the work for us. (or at least point out where the problems are).

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