pcplantdb

[Chad Knepp <pyg@galatea.org>]

Interesting stuff...  Sorry this report is taking so long, I keep
writing, deleting, rewriting, etc.  I'm not going to make any promises
about when I post a draft so that way no one is dissapointed.


webmaster@pfaf.org writes:
 > Lawrence F. London, Jr. wrote:
 > > Could you explain "the Wiki model" as you envision it.
 > > I assume the comparison is between a true relational database
 > > (Sql/Php, Zope, etc.) and a conventional wiki (i.e. wikipedia, pmwiwki, 
 > > phpwiki, tikiwiki).
 > > And how does a true CMS (like the nice one Chad set up or maybe Tikiwiki 
 > > or more elaborate models) fit into all this?
 > 
 > Chad
 > > Actually I think the wiki model is [the most] appropriate for
 > > subjective types of information.  Very technical things such as plant
 > > data are fairly objective (subject to local variances but that's
 > > objective as well) and IMO ideal to the data model I've implemented.
 > > It's highly analogous to the way modern science works.  Scientists do
 > > research, publish papers, and the collective peer consciousness
 > > *moderates up* papers that best describe reality.
 > > 
 > > Questions of aesthetics, morals, religion/philosophy, etc. can have
 > > equally strong opposing ideas and peer moderation may be abused to
 > > favor the majority opinion; although in a best case scenario the
 > > clearest articulations of the ideas (even if opposing) will *rise to
 > > the top*.
 > 
 > OK after some time editing wikipedia I'm a bit more familiar with 
 > strengths and weaknesses of the system. I'll explain a bit more about 
 > wikis and the MediaWiki implementation, which is rather nice.
 > 
 > In a wiki each page consists of a simplified form of html with an easier 
 > syntax. It allows headings
 > == A heading ==
 > === A second level heading ===
 > paragraphs are just made with empty lines. Italic and bold
 > ''italic'', '''bold'''. Lists are marked by a *
 > * First level list item
 > ** Second level list item
 > 
 > This is all the basic formatting needed for most documents. The syntax 
 > is easier than html so its easier for new users to get involved. A low 
 > barrier  to entry and a shallow learning curve are both very desirable 
 > features.
 > 
 > Fundamental to the wiki philosophy is the idea that anyone can edit the 
 > whole text. This can, and does work well. People have probably noticed 
 > that my posts have a high number of spelling and grammar mistakes, a 
 > wiki is ideal here as others with a better grasp of English than I
 > can correct all my mistakes. It allows the whole text to improve with 
 > time. On the other hand I tend to be better at things like categorizing 
 > articles, seeking out references etc. In general the process will tend 
 > to improve the article, each new edit tends to make the article better. 
 > If an edit detracts from the article then it is easy for some other 
 > editor to change the article back.

The above here is the only thing I differ on and most of what you
refer to I would consider more features than integral to the data
model.  Features that may be valuable to our own cause...q

If you've been paying attention to the various tech news sites,
Wikipedia has been getting a lot of flack for the problems arising in
the above, esp. during edit wars and vandalism.  What I've been
calling the Atomic Peer Moderated Collaboration model allows
collaboration on the same data but creates different [Atomic] versions
under their respective authorships.  Peer moderation creates a value
hierarchy where obvious falsifications and vandalism, while allowable,
will never be moderated up.  The fact that all collaboration only
happens in parallel not in overlap protects the dataset from damage
even if individual accounts are compromised or malicious accounts
created and used.

Example: Take the Cultivation Notes comment by Ken Fern for any plant.
Another author, dissatisfied with the information provided could
either copy the text in whole and edit it for greater
clarity/correctness or start from scratch.  Over time if the
collective group of peers determine that the new authors information
is more informative/accurate/authoritative/etc. it would be moderated
up and display before the original.  Alternately a dissatisfied user
could attach a comment to Cultivation Notes with recommended
changes/additions that the original author could incorporate or that
would be read after the original comment and add to the total
information.

I actually think Wikipedia is moving toward or will drift to something
closer to this than it is currently.

 > There are several features which help with the process.
 > (A bit of wiki slang an editor is anyone who edits a page)
 > 
 > Each article also has a talk-page. Here editors can discuss the article 
 > and propose changes, this allows consensus to occur without having the 
 > discussion on the main article. A recent discussion I had on a talk page 
 > led to the construction of a new article.
 > 
 > Registered users can have a watch list. Here changes to any pages which 
 > you have a particular interest in can be recorded. This allows
 > the user to quickly see what articles have changed and review the 
 > changes. Watchlists are one of the reasons why vandalism is quickly 
 > fixed as the vandalism can be quickly spotted and corrected.
 > 
 > Linking
 > -------
 > 
 > The wiki model allows easy linking, just include the name of an article 
 > in square brackets: [[Salix alba]] and the article will be linked. Very 
 > easy and probably better than the WikiWord syntax which required 
 > composition of two words with a capital in the middle. Such links are 
 > one directional.

Kfml already has a defined format for this although it's not as
elegant (<link plant=1567>Salix Alba</link>)

I've been thinking of adding STX (Structured TeXt from Zope and
others) support to text bodies to allow easy end user formating of
comments and articles.  Also STX features would probably be translated
to kfml for true portability.

 > There is also the concept of a category, categories allow a form of 
 > bi-directional links. For example the Permaculture article is a member 
 > of the Sustainable Agriculture category. This is indicated by adding a 
 > link [[Category:Sustainable agriculture]] to the Permaculture article.
 > Visiting the Sustainable Agriculture category will show all article in 
 > that category. The category system is very flexible, its not a 
 > hierarchal tree more a web of links, as time progresses the set of 
 > categories can alter as more articles are added and categories fill up. 
 > When they get too full a category can usually be split into two or more 
 > sub categories and the articles divided appropriately. Categories can be 
 > members of other categories which allows a topical map to be constructed.
 > 
 > Another mechanism templates is also very powerful. Templates work by a 
 > simple inclusion system, the code in template is just included in the 
 > article using the syntax {{templatename}}. These allow standard messages 
 > to be included. Templates can also have parameters, written as
 > {{templatename|parameter}} or {{templatename|paramname = value}}.
 > The templates themselves have a limited programing facility with if and 
 > foreach statements.
 > 
 > Templats allow a common format to be used. All plants use a taxobox to 
 > record names and classifications of plants, for example ragwort
 > has
 > {{Taxobox_begin | name = Ragwort}}
 > {{Taxobox_begin_placement }}
 > {{Taxobox_regnum_entry | taxon = [[Plant]]ae}}
 > {{Taxobox_divisio_entry | taxon = [[Flowering plant|Magnoliophyta]]}}
 > {{Taxobox_classis_entry | taxon = [[Dicotyledon|Magnoliopsida]]}}
 > {{Taxobox_ordo_entry | taxon = [[Asterales]]}}
 > {{Taxobox_familia_entry | taxon = [[Asteraceae]]}}
 > {{Taxobox subfamilia entry | taxon = [[Asteroideae]]}}
 > {{Taxobox tribus entry | taxon = Senecioneae}}
 > {{Taxobox_genus_entry | taxon = ''[[Senecio]]''}}
 > {{Taxobox_species_entry | taxon = '''''S. jacobea'''''}}
 > {{Taxobox_end_placement}}
 > {{Taxobox_section_binomial_botany| binomial_name = Senecio jacobaea| 
 > author =[[Carolus Linnaeus|L.]]}}
 > {{Taxobox_end}}
 > this will cause the information to be displayed as a nice table see
 > http://en.wikipedia.org/w/index.php?title=Ragwort
 > http://en.wikipedia.org/wiki/Wikipedia:How_to_read_a_taxobox
 > 
 > Templates also work well with categories. For example a 'flora of' 
 > template could be defined to list a plant as part of the native flora of 
 > a particular country. For example we could used {{flora of|China}}
 > which would automatically place the plant in the category 'flora of 
 > China'. Most of the fields we are interested in could be represented as 
 > such templates {{Height|10}} {{Edible uses|bread}}.
 > 
 > There are some limitations of the template/category system. It is not 
 > possible to include additional info in a category link, for example any 
 > reference to why it is included or a rating as to how good a particular 
 > uses is. It works less well for numeric fields like height.
 > 
 > In RDF terms it does not allow a full triple 
 > [object|relationship|subject] [Budlia|food plant for|butterflies], but 
 > does come close.
 > 
 > In conclusion
 > -------------
 > 
 > The wiki model, in particular the MediaWiki implementation, covers
 > many of the features we need. It allows for extensible pages so new 
 > sections could easily be added without being limited by the underlying 
 > data structure. It has a powerful, flexible and extensible linking 
 > system which nearly meets our needs. Its also an out of the box system 
 > so little work to get it running. Out of interest there is a 
 > permaculture wiki city http://permawiki.wikicities.com/
 > but its rather empty at the moment.

Not a feature anyone is crying out for but adding an article data
element is something on my personal agenda which would bring PIW up to
the feature level of a Wiki.  Actually if you url hack the add comment
url so that parent_id = 0 you can create a comment that is not
attached to any object which in itself is sort of an article (this is
intentional btw, not a bug).  Such comments can be [re]edited, have
other comments attached to them, etc.

 > Rich

Cheers,
Chad

-- 
Chad Knepp
python -c 'import base64;print base64.decodestring("cHlnQGdhbGF0ZWEub3Jn")'