pcplantdb

[John Schinnerer <john@eco-living.net>]

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