WebSeitz/wiki

Wiki For GroupWare

Wiki For CollaborationWare focuses mainly on shared document editing, which covers a lot of ground. But all unstructured data. For handling Structured Data, let's consider Wiki For GroupWare. (Update: there are now Structured Wiki engines.)

A big need I've found in every SmallCo is Sales Force Automation.

I've looked at SalesforceCom, and I've hacked together a little MsExchange shared folder.

What's the simplest way to get some SFA features into a wiki?

There are 2 main sets of structured data you might want to add to a simple page.

  • info about that person (contact info, etc.)

    • why any structure?

      • want a template just to remember to enter certain data

      • if you plan on PDA synching, or just simple export to structured formats (e.g. VCard)

      • maybe for some querying ('source=nihConference' or 'customerType=investmentBank')

  • some sort task tracking data for querying ('taskAssignedTo=GeorgeB' and 'taskDueDate=12/31/03')

Note that querying almost always involves multiple fields. And that you're likely to end up with some querying on date data.

How can you handle such things in something as simple as a wiki?

  • well, I work with the Zwiki WikiEngine, so there's that lovely Zope ZODB to suck data into, and then you get Z Catalog and other juicy stuff

  • for other WikiEngines, you might be able to extend them. You might not need a SQL engine for data (in fact you'd definitely want a more flexible Object Store). You might even make do with a simple streamed binary file of language objects: but with a WebApp you have to worry about handling simultaneous hits, so you'd need some mechanism to handle that...

Crude idea to chew on:

  • most data types are pretty flat (or you can pretend they are)

  • so you just need a flag list of fieldnames

  • you could require that the lines of structured data go at the top of the page, each line being a fieldname and value (a triple?) (YAML as a format?)

  • when saving a change, you could find/parse those lines and save them into a structured format (just more object properties in Zwiki)

  • if you're very loose/sloppy in data handling, you could tweak your field specs (and create new object types) whenever you wanted and Zope wouldn't care

    • and you wouldn't need to bother tweaking a pretty form (which means giving up nice pulldowns for data validation)

    • though adding a new field wouldn't get it included in a Z Catalog...

This is definitely tempting... I might even stay away from Zwiki Tracker.

Other area: Issue Tracker

for shared Task Management/Commitment-Management

SFA/"flexible metadata" --2003/10/14 22:15 GMT
Hi Bill,

You might also have a look at XmlSchema or the Unix Mbox format.

  • XML is too ugly for humans. Even YAML is a bit geeky

I would definitly advise you that all those pages get a meta-meta-data field, e.g. "X-XML-Schema: http://foo.bar/sfa-v1.1.xsd". That would make it possible to 'validate' the input and it will make upgrading a bit easier.

Also have a look at Archetypes and/or How To Start With Arch Gen Xml">ArchGenXML (I should do too ;)

Regards, Zwiki:PieterB

This is probably a dreadful hack but ... --2003/10/15 02:38 GMT
I'm playing with integrating new functionality with OddMuse using just raw includes and a custom script. On <http://www.synaesmedia.com/beach/wiki.cgi/Code Generation Experiment> I'm using this combination to do a little code generation. The raw data file is written on one page. Another page uses OddMuse's "include" to trigger the external script and sends the data page name as an argument. The script pulls the data from the wiki also the raw include mode.

In this example, parsing isn't very robust, but there's no reason it couldn't be made more so.

I guess something similar could be set up to integrate sales data into the wiki. For example : a form filling script could put contact details into a database, it could also spit out the details in the right format for inclusion into the wiki. Then you hack the wiki, so that any page entitled ContactBob Smith, automatically pulls the Bob Smith record out of the database script and displays it on the page. (Though you should also allow the user to annotate the Bob Smith page.) Meanwhile an Enter Contact page should include an HTML form which allows another contact to be put into the database. Other queries can be handled as calls to the external script.

I think something YAML like is appropriate. Users ought to be able to learn a couple of bits of strange syntax if there's something in it for them. (Or am I naive here?) Maybe you reward them by making the special syntax needed to enter the data properly, also spit out the record in a pretty format.

-- Phil Jones

PIM info --2003/10/20 11:58 GMT
Nice ideas. I'm working on using a Wiki as a front end (one of several) to an RDF store. Info about a person (contact info, etc.) could be stored using the FOAF vocabulary, the RDF iCalendar vocab could take a lot more. The standard Wiki functionality can still operate. The way I'm approaching it is to move towards storing the wiki page content as (X)HTML docs, transforming it for edits. Each page has associated RDF metadata. Should be very web-friendly. For something like FOAF data, a few extensions to the Wiki syntax and/or a form could provide the editing capability. The big benefit should come when you want to do structured browsing, an RDF query language allowing smart cataloguing etc.

forget me PIM info --2003/10/20 11:59 GMT
Danny Ayers

Row and column based access controls in wiki tables --BillSeitz, 2003/10/20 14:38 GMT
semi-related idea on structured editing by Vinod Kulkarni

Edited:    |       |    Search Twitter for discussion

Made with flux.garden