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 19:55:08 +0000

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







Archive powered by MHonArc 2.6.24.

Top of Page