Skip to Content.
Sympa Menu

pcplantdb - Re: [pcplantdb] schema stuff

pcplantdb@lists.ibiblio.org

Subject: pcplantdb

List archive

Chronological Thread  
  • From: John Schinnerer <john@eco-living.net>
  • To: Permaculture Plant Database <pcplantdb@lists.ibiblio.org>
  • Subject: Re: [pcplantdb] schema stuff
  • Date: Wed, 17 Nov 2004 10:39:40 +0000

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?

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?
I thought we were already clear that this wasn't going to be a wiki-type thing.
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.

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.

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?

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.



--

John Schinnerer - MA, Whole Systems Design
------------------------------------------
- Eco-Living -
Whole Systems Design Services
People - Place - Learning - Integration
john@eco-living.net
http://eco-living.net




Archive powered by MHonArc 2.6.24.

Top of Page