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: Paul Cereghino <paul.cereghino@comcast.net>
  • To: pcdb <pcdb@lists.ibiblio.org>
  • Subject: Re: [pcdb] [Fwd: Re: [permaculture] To wiki or not to wiki]
  • Date: Thu, 21 Dec 2006 22:07:12 -0800

Thank you both for your interest and knowledge... your debate is illuminating.

I wonder if the wiki format is truely the best platform to play with, simply because we don't understand the data architecture that will successfully represent permaculture design -- and I mean only those aspects of permaculture design that can be represented by data. (although I am interested in this road -- I am not convinced that there is actually a labor/benefit payback through deconstruction -- but it would be interesting). Another reason why the wiki approach is where i'm motivated is that I have enormous respect (as in respect for a hurricane or a mountain) for the simple synoptic task of describing reocurring elements and patterns well. I think that this alone would be dynamic and useful exercise to a broad enduser group. In playing with how to structure a wiki we may well discover that a more rigorous data management architecture would add value. The virtue of the wiki is that it allows collective population of the data set, and continuous updating.

Even if we do go down an analytical road... it is best built on a architecture derived from the more collaborative narrative format of a wiki. The scope of the pilot wiki could be constrained for the purposes of exploring how elements stack up into patterns and how they relate to process domain (climate/geology).

Here's a link to a discussion of a conceptual model for decribing the Puget Sound nearshore ecosystem as a precursor to a ecosystem restoration plan. It has some ideas on modeling ecosystem functions that are fairly evolved -- but gives a brutal picture of what it might mean to even conceptually model ecosystem process/structure/function in a limited domain.

http://pugetsoundnearshore.org/techical_papers/conceptmodel_06.pdf

Thank you LL and Rich for offering a wiki platform... I'd be interested in seeing folks with a clear vision attempt to describe the scope of work as a wiki article. This will allow for some incremental back and forth, and clarification of where the tribe is interested in setting up camp. I'd like to hear about what neglinlaksjdfldas wants to go too.. (sorry got tired of cutting and pasting :)

See you'all after xmas
Paul



Rich Morris wrote:

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






Archive powered by MHonArc 2.6.24.

Top of Page