Skip to Content.
Sympa Menu

pcplantdb - Re: [pcplantdb] schema stuff

pcplantdb@lists.ibiblio.org

Subject: pcplantdb

List archive

Chronological Thread  
  • From: Richard Morris <webmaster@pfaf.org>
  • To: Permaculture Plant Database <pcplantdb@lists.ibiblio.org>
  • Subject: Re: [pcplantdb] schema stuff
  • Date: Wed, 17 Nov 2004 22:44:17 +0000

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






Archive powered by MHonArc 2.6.24.

Top of Page