Permaculture Database

[Paul Cereghino <paul.cereghino@comcast.net>]

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
>