pcplantdb

[Richard Morris <webmaster@pfaf.org>]

John Schinnerer wrote:

> Aloha,
>
> > I quite agree if what we want for our product is a fixed
> > data-centric 'database' with a fixed set of fields always displayed in 
> > the same order.
>
>
> That's only how the data is stored internally.
> Isn't the whole point of Relational DB (as opposed to heirarchical DB or 
> flat-file DB) that one can do all sorts of relational operations on the 
> stored data to generate more complex/interrelated output?
Structurally a tree structure is richer than a relational db.
You can represent a relation structure in a tree, but can't always 
represent a tree in a relational structure.

For the web server we have three core functions
        1) search for plants by characteristics
        2) display data for a single plant
        3) input/edit/append data
Doing more complex things on the web server gets hard. What sort of 
interface is needed to define a more complex operation.

Do you have an example of a more complex operation, which you might want 
to do.

> > However if we want a more free, 'narative' style for the data
> > then the database concept is not appropriate. If we want something
> > closer to a webpage which has a looser structure, then it is actually 
> > very hard to represent this in terms of database schema.
>
>
> I think we want some narrative aspects in our database, not a whole 
> database of narrative comments.  A lot of what we are going to store is 
> non-narrative - all the plant names, properties, functions, attributes, 
> etc. - isn't that the core of phase one?

Indeed. A hybrid system with some traditional tables and some
marked up text, is what I'm thinking of.

> I thought we were already clear that this wasn't going to be a wiki-type 
> thing.

This is really the central question. Where do we position ourselves
on the flatDB -- wiki spectrum.

> I thought we were clear that this was going to be a serious PC-centric 
> data back end with a clean API that would enable a variety of client 
> UIs, from typical forms in and out to graph-based UIs.

An XML DTD is a good way to define a clean API.

> > Consider the case of book references, from the pfaf-db
> >
> >  >>>>>>>>>
> > Salix alba
> >
> > Edible Uses
> >
> > Inner bark; Leaves; Tea.
> >
> > Inner bark - raw or cooked. It can be dried, ground into a powder and 
> > added to cereal flour then used in making bread etc[2]. A very bitter 
> > flavour, especially when fresh[2, 115], ...<snip>
> >
> > Now the square brackets [2,115] are two references to books.
> > This format clearly fails as it is hard to parse the book references.
>
>
> Hard to parse?
> They start with a left square bracket, contain a sequence of one or more 
> digits [0-9] separated by commas and end with a right square bracket.
> Seems pretty consistent and regular and trivial to parse.

Hard to parse because there are cases where square brackets are used
in a different context. Square brackets do not always indicate a book 
reference. Use square brackets and you must check all user input
for validity.

> And it's only an issue at all if we insist they be embedded like that - 
> that is, tied to a specific phrase within a chunk of narrative text.
>
> If the refs are simply put in a table of references, then for a given 
> narrative text as above we just relate it to the references that support 
> it.
> They won't be stuck onto the exact phrase they're supporting.
> I don't think that's necessary here - this isn't a doctoral thesis or 
> professional journal article that needs phrase-specific footnotes, it's 
> a narrative with a bibliography.
>
> > Links to other webpages, relationships/keywords also fall into the same
> > catagory, i.e. things which might occur anywhere in the plant info.
> > ...
> > Cultivars is another example where a looser structure could be useful.
>
>  > Its is posible that any field might be different for a cultivar than
>  > for the main plant. But creating a table to hold all the posible
>  > differences is going to make things overcomplicated.
>
> > <cultivars>
> > <cultivar name="Cardinal">
> >     This form is grown for its use in
> >     <keyword>basket making</keyword>
> >     <bookrefs><bookref num=131 /></bookrefs>.
> > </cultivar>
> > </cultivars>
>
>
> And where/in what will the above chunk of XML be stored?

Several options. Could have one big XML chunk for each plant.

Could have a separate cultivars table

plant_id | cultivar_name | description_xml
1234 | Cardinal | This form is grown for its use in
     <keyword>basket making</keyword>
     <bookrefs><bookref num=131 /></bookrefs>.

> > For me making things extensiable is a very key aspect.
> > I'd like to make it so that a users can add new fields/items. For 
> > example a yield item could be handy. But we cannot predict apriori
> > what the new field might be. With a fixed database structure
> > it becomes hard to add such a field and only the DB admin
> > can do this. In an XML version its simple a matter of adding a new tag
> > <section name="yield">....</section>.
>
>
> These sorts of issues are of course why I was pushing for object-based 
> design from the start.

Yep, the mapping from object <-> XML is pretty straightforward.
You can take the view that XML is an effective method of serialising
(storing/transmitting) objects.

        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