pcplantdb

[Richard Morris <webmaster@pfaf.org>]

John Schinnerer wrote:
> Aloha,
>
> I'm with RichardA on this.
> XML *in* the data *in* the DB?!? Yuk.  I mean, Yuuukkkkkk!

> Data import/export/transport - sure, that's what it was designed for.
> The rant he links below is IMO more of a good clear explanation of the 
> situation than a rant.

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.

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.

For example consider trying to represent a threaded email discussion
with multiple levels of quotes, this becomes a nightmare to represent in 
a db.

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], it is used as a famine food when 
all else fails[172].
Leaves and young shoots - raw or cooked[2, 177]. Not very 
palatable[172]. They are used only in times of scarcity[105].
The leaves can be used as a tea substitute[61].
>>>>>>>>>

Now the square brackets [2,115] are two references to books.
This format clearly fails as it is hard to parse the book references.
An XML version might have

>>>>>>>>>
A very bitter flavour, especially when fresh <bookrefs><bookref num=2 />
<bookref num=115 /></bookrefs>
>>>>>>>>>

Its beyond me how this could be done in a strict database.
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.

>>>>>>>>>
Cultivars

'Cardinal'
    This form is grown for its use in basket making[131].
>>>>>>>>>

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. In XML
its a breaze

<cultivars>
<cultivar name="Cardinal">
        This form is grown for its use in
        <keyword>basket making</keyword>
        <bookrefs><bookref num=131 /></bookrefs>.
</cultivar>
</cultivars>


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

There are cases where the DB paradime is useful, in those sections where 
a rigid structure is desired, for example in a botanical plant name
where there is a generally agreed structure.

I'm aware that going this route might be moving the goal posts
some what. I'm more concerned that we get something out.

Anyway have a look at wikipedia, they have gone the marked-up narative 
route.

        ttfn

                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