Skip to Content.
Sympa Menu

pcdb - Re: [pcdb] [Fwd: Re: [permaculture] To wiki or not to wiki]

pcdb@lists.ibiblio.org

Subject: Permaculture Database

List archive

Chronological Thread  
  • From: Rich Morris <mailinglists@pfaf.org>
  • To: pcdb <pcdb@lists.ibiblio.org>
  • Subject: Re: [pcdb] [Fwd: Re: [permaculture] To wiki or not to wiki]
  • Date: Fri, 22 Dec 2006 01:46:51 +0000

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





Archive powered by MHonArc 2.6.24.

Top of Page