Permaculture Database

[Rich Morris <mailinglists@pfaf.org>]

Richard Archer wrote:
> At 12:39 PM +0000 21/12/06, Rich Morris wrote:
>
> > Users can edit the the wiki, by clicking on the edit tab at the top of
> > the window. This will take you to a form like
> > http://www.pfaf.org/wiki/index.php?title=Cichorium_intybus&action=edit
>
> I must say, MediaWiki does have some interesting cross-linking
> features. But still, I don't see how it could be postulated that
> having users fill in a form with lots of boxes and with server-side
> validation is any harder for them than creating the following,
> freehand, without errors:
>
> ==Physical Characteristics==
> {{height width pic|height=1.5|width=0.5|habit=Perennial}}
> {{habit|Perennial}} growing to {{height|1.5}}m by {{width|0.5}}m. <br>
> It is hardy to zone {{prop|Hardyness|3}} and is {{prop|Hardyness|not
> frost tender}}. <br>

This is where the revision history of a wiki comes in. You can compare
any selected versions of a page, see
http://www.pfaf.org/wiki/index.php?title=Cichorium_intybus&diff=22359&oldid=22348
which shows an addition of a use property.

Recent changes shows all the recent edits
http://www.pfaf.org/wiki/index.php/Special:Recentchanges
and logged in users also have a wacthlist showing pages they are patrolling.

Automatic validation can tell you if a specific property is legal, but
not if it is sane. So AV could pick out a negative or non numeric
height, but not spot if a tree has only a height of 10cm. We get quite a
few reports by email of such error.

> And I can see that the article is then stored in the database
> as this massive chunk of text. If you wanted to perform an
> analysis of the data you need to parse all the properties
> out first. (e.g. {{prop|Hardyness|not frost tender}})

The properties come ready parsed, done during the save of each page, put
into a database table, exportable in xml.
http://www.pfaf.org/wiki/index.php/Special:Properties/Salix_alba
and with code level access from SQL queries.

> And Rich admits "the current website update cycle is a nightmare".
> Well, that works in reverse, extracting the data from the Wiki and
> restructuring it as a normalised database for deeper analysis
> would probably be even harder.

I've generally found the need for deeper analysis very low, even the
advanced search on the main pfaf site is only getting about 10 hits a day

/database/search_name.php       15282 search by latin/common name
/database/search_use.php        8022  search by plant use
/database/search_prop.php       86    advance search

this is what has led me away from the database ideas, most people don't
really care how the data is represented. Make the common things easy and
the less common things possible.

The underlying data representation is simple and powerful, basically
three columns, object name, property name, property value

Cichorium_intybus       Genus   Cichorium
Cichorium_intybus       Family  Asteraceae
Cichorium_intybus       Family  Compositae
Cichorium_intybus       CommonName      Chicory
ichorium_intybus        Author  L.
Cichorium_intybus       Vitamin B6      0
Cichorium_intybus       Vitamin C       0
Cichorium_intybus       Use     Appetizer
Cichorium_intybus       Use     Bach
Cichorium_intybus       Use     Cardiac
Cichorium_intybus       Use     Cholagogue
Cichorium_intybus       Use     Depurative
Cichorium_intybus       Use     Digestive

This can represent one to one relationships (e.g. genus) and one to many
relationships (e.g. uses). Its extensible, in that new propeties and
values can be easily added. Its sort of inspired by objects in
programming (or basically the C stuct) where each object has a set of
members. This also maps well onto N-Triples form of RDF
http://en.wikipedia.org/wiki/Resource_Description_Framework
The extensible nature, is similar to javascript prototype which I think
is the 'duck typeing' objects used by smalltalk.

> I still maintain that the dataset should be stored directly into
> an SQL database, and get there via custom forms with strict
> validation.
>
> The data-browsing side of the system could look just like the
> Wiki, it would just take a little more work to get there.
> And IMHO the admin side would be much cleaner and simpler by
> using well-designed forms.

It is actually a lot of work, to get an system with user input. You have
to handle
:user logins
:some sort of abstration mechanism so the underlying database is switchable
:input validation, to check for sql injection attack
:logging and error reporting facilities
:revision control, at the very least some form of reverting facility to
remove spam
and thats before you even begin to think about divising the schema.
Which is a hard task if you want to model everything in permaculture.

I've seen a lot of project get stuck and fail at one of these steps. I'd
estimate at least three months to get an primary verision release. I'd
far prefer to basically skip all of that, and use some exsisting
software which does 90% of what we need, the other 10% can be done with
extensions. Then we can devote time to the actual content, which is
where things really get interesting.

> And you get a portable, structured dataset into the bargain.

Indeed.

        Rich
--
Plants for a Future: 7000 useful plants
Web:   http://www.pfaf.org/
Post:  1 Lerryn View, Lerryn, Lostwithiel, Cornwall, PL22 0QJ
Tel:     01208 872 963
Email: webweaver@pfaf.org
PFAF electronic mailing list http://groups.yahoo.com/group/pfaf