WikiParts
Whats this about?
Ever wanted to show on a wiki page the information that you've collaborated on as well as some structured data from a corporate data source, external web service or some other system of truth? Well read on...
Genesis
Recently I was working on an prototype Enterprise Architecture Wiki. Basically it contained information about applications, installations, infrastructure (software and hardware) and pretty much most of the IT capabilities of an organisation. Someone pointed out that some of this knowledge was already in another structured datasource, which was backed by a traditional database. This informaiton was reliable and pretty much the record of truth and what they thought would be good would be a fusion of that information with the power and function of a wiki.
So the basic idea was born. Fuse the knowledge reliability of traditional data sources with the power and function of a wiki. Note that I say data sources and not database. A data source could be a database, a web service or an external application, all positioned behind a web service. Think of a mashup between a wiki and, well, anything!
What it may look like in practice...
Imagine a wiki that has some details about high value customers that your elite sales team targets. We are talking an Enterprise 2.0 (thats Web 2.0 inside an organisation on an intranet) wiki here, where we have multiple pages, one per high value customer.
On these pages we put information about the customer, sales people add notes, ideas on strategies for up-selling, their known preferences, links to other customers who are know acquaintances, etc. The problem is we already have a customer database sitting on a corporate server.
Its the system of record for the customer, their contact details, basic sales history, etc. We dont want to duplicate that information in the wiki and have to update details in two places, or worse still let them get out of sync. Likewise our existing Line-Of-Business sales system is too inflexible to allow for collaboration on customer information or easy navigation.
Enter the WikiPart. On the wiki page we have some information that comes from standard wiki page editing. But also we have other information that comes via WikiParts from external data sources, external to the wiki that is. For example, the sections that have the customer name, DOB, contact details, current total sales worth etc, are brought in via WikiParts from our existing sales system database.
The rest of the page is strictly wiki. Users can create and edit, notes, informaiton, strategies and add wiki links as required.
This is just one example. But think about it. Theres probably a million others just waiting out there just waiting to be fused together...
Actual Implementation...
Im trying to run over how this might be implemented at a high level in MediaWiki, mainly because its widely used and also already has an existing rich syntax that could be extended.
In MediaWiki I see basically two items that wiki users would add to a page. The first is the WikiPart which provides the linkage to the web service that accesses the data source.
The second is the parameter substitution that allows the use of this data in the Wikis page. So at the top of the wiki page there may be something like:
This would cause the wiki server to call the web service "salesdata" with a message containing a parameter called "customerId with a value of 13266. The service would then query the sales system (or its database direct) and return a variety of values as part of the web service return message (such as the customers name and address contact details).
These values could then be parameter substituted into the wiki page. A typical wiki page that utilises this web service output may be as follows:
As you can see I've glossed over the web service details and message syntax. For now I've tried to keep it high level to get feedback. In reality, most of what has been shown in the example above would be done on page templates.
You would probably set up a "Customer" page template with all the substitutions and initial wiki part in place. In the actual wiki page that utilises the template, the value for the customerId would need to be specified and utilised when the template is evaluated on the wiki server. Again i'll leave details till another time.
Other wiki products would have similar approaches. However some like the Wiki offering in Microsoft's Sharepoint 2007 may need a slightly different approach. It relies on an advanced page editor (think a very simple web version of MS-Word) and supports no other mark up other than wiki links.
It does however allow the Wiki page to be Web Part "edited" which allows you do put web parts around the wiki page (but not really in it), so there is scope for developing a .Net WebPart that does the job I described above, though the current look and feel may not be particularly integrated.
And for extra merit points....
The true pleasure and pain of WikiParts is when they become a two way street. Thats where wiki pages retrieve information from the web service, and also update it. When a page is edited, or maybe even created, the wiki server could place dialog boxes on the page for editing (or input) of values that are linked to WikiParts. On submission, the values would be sent via the WikiPart and web service to the datasource, whilst the standard wiki text would also be updated. The input fields would default to their current values on an edit.
Of course the pain here is the input validation. The data consistency of the underlying datasource must be preserved. It needs to enforce such rules as does the web service implementation operating over it and reflect any violations back to the wiki server in a reasonable manner. In addition, some level of client side data editing functionality (i.e. list boxes of possible values, range and field length checking) would have to be specifiable to provide users with a reasonable experience.
Again this is far in the future, and there are probably many WikiPart based wikis that would simply be read only from the external data source. But again the posibilities for merging structured and semi-strucutured data in enterprise wikis are enticing.
Wrapping Up
So there you have it, WikiParts. Merging information and data. Combining what previously was lost in Word documents in a file share and what was locked up in corporate databases, into one collaborative envrionment. And being web service based, almost any data external to the wiki can be accessed and merged into the displayed page.
Maybe a wiki product out there is doing this already, or something similar. There are literally hundreds of wiki products on the market or available as opensource or freeware. I havent surveyed that many and it wouldnt surprise me. I suspect someone may have also already hand hacked an opensource wiki to incorporate such a feature.
But I suspect this hasn't appeared in the mainstream products yet and it needs to soon, to completely unlock the power of wikis, collaboration and structured data combined for the first time.
Ever wanted to show on a wiki page the information that you've collaborated on as well as some structured data from a corporate data source, external web service or some other system of truth? Well read on...
Genesis
Recently I was working on an prototype Enterprise Architecture Wiki. Basically it contained information about applications, installations, infrastructure (software and hardware) and pretty much most of the IT capabilities of an organisation. Someone pointed out that some of this knowledge was already in another structured datasource, which was backed by a traditional database. This informaiton was reliable and pretty much the record of truth and what they thought would be good would be a fusion of that information with the power and function of a wiki.
So the basic idea was born. Fuse the knowledge reliability of traditional data sources with the power and function of a wiki. Note that I say data sources and not database. A data source could be a database, a web service or an external application, all positioned behind a web service. Think of a mashup between a wiki and, well, anything!
What it may look like in practice...
Imagine a wiki that has some details about high value customers that your elite sales team targets. We are talking an Enterprise 2.0 (thats Web 2.0 inside an organisation on an intranet) wiki here, where we have multiple pages, one per high value customer.
On these pages we put information about the customer, sales people add notes, ideas on strategies for up-selling, their known preferences, links to other customers who are know acquaintances, etc. The problem is we already have a customer database sitting on a corporate server.
Its the system of record for the customer, their contact details, basic sales history, etc. We dont want to duplicate that information in the wiki and have to update details in two places, or worse still let them get out of sync. Likewise our existing Line-Of-Business sales system is too inflexible to allow for collaboration on customer information or easy navigation.
Enter the WikiPart. On the wiki page we have some information that comes from standard wiki page editing. But also we have other information that comes via WikiParts from external data sources, external to the wiki that is. For example, the sections that have the customer name, DOB, contact details, current total sales worth etc, are brought in via WikiParts from our existing sales system database.
The rest of the page is strictly wiki. Users can create and edit, notes, informaiton, strategies and add wiki links as required.
This is just one example. But think about it. Theres probably a million others just waiting out there just waiting to be fused together...
Actual Implementation...
Im trying to run over how this might be implemented at a high level in MediaWiki, mainly because its widely used and also already has an existing rich syntax that could be extended.
In MediaWiki I see basically two items that wiki users would add to a page. The first is the WikiPart which provides the linkage to the web service that accesses the data source.
The second is the parameter substitution that allows the use of this data in the Wikis page. So at the top of the wiki page there may be something like:
{{
WikiPart
id="CustomerWikiPart"
service="http://corporatesystems/salesdata"
parameters={customerId=13266}
}}
This would cause the wiki server to call the web service "salesdata" with a message containing a parameter called "customerId with a value of 13266. The service would then query the sales system (or its database direct) and return a variety of values as part of the web service return message (such as the customers name and address contact details).
These values could then be parameter substituted into the wiki page. A typical wiki page that utilises this web service output may be as follows:
==Customer
ID==
{{{CustomerWikiPart.customerId}}}
==Name==
{{{CustomerWikiPart.customerName}}}
==Contact
Address==
{{{CustomerWikiPart.streetAddress}}}
==Mobile==
{{{CustomerWikiPart.mobile}}}
==Notes==
This customer has said previously he is interested in our [[super widget]] and [[wonder widget]] products but that the price was too high at that time. He is known to like golf and drives and old Jaguar.
As you can see I've glossed over the web service details and message syntax. For now I've tried to keep it high level to get feedback. In reality, most of what has been shown in the example above would be done on page templates.
You would probably set up a "Customer" page template with all the substitutions and initial wiki part in place. In the actual wiki page that utilises the template, the value for the customerId would need to be specified and utilised when the template is evaluated on the wiki server. Again i'll leave details till another time.
Other wiki products would have similar approaches. However some like the Wiki offering in Microsoft's Sharepoint 2007 may need a slightly different approach. It relies on an advanced page editor (think a very simple web version of MS-Word) and supports no other mark up other than wiki links.
It does however allow the Wiki page to be Web Part "edited" which allows you do put web parts around the wiki page (but not really in it), so there is scope for developing a .Net WebPart that does the job I described above, though the current look and feel may not be particularly integrated.
And for extra merit points....
The true pleasure and pain of WikiParts is when they become a two way street. Thats where wiki pages retrieve information from the web service, and also update it. When a page is edited, or maybe even created, the wiki server could place dialog boxes on the page for editing (or input) of values that are linked to WikiParts. On submission, the values would be sent via the WikiPart and web service to the datasource, whilst the standard wiki text would also be updated. The input fields would default to their current values on an edit.
Of course the pain here is the input validation. The data consistency of the underlying datasource must be preserved. It needs to enforce such rules as does the web service implementation operating over it and reflect any violations back to the wiki server in a reasonable manner. In addition, some level of client side data editing functionality (i.e. list boxes of possible values, range and field length checking) would have to be specifiable to provide users with a reasonable experience.
Again this is far in the future, and there are probably many WikiPart based wikis that would simply be read only from the external data source. But again the posibilities for merging structured and semi-strucutured data in enterprise wikis are enticing.
Wrapping Up
So there you have it, WikiParts. Merging information and data. Combining what previously was lost in Word documents in a file share and what was locked up in corporate databases, into one collaborative envrionment. And being web service based, almost any data external to the wiki can be accessed and merged into the displayed page.
Maybe a wiki product out there is doing this already, or something similar. There are literally hundreds of wiki products on the market or available as opensource or freeware. I havent surveyed that many and it wouldnt surprise me. I suspect someone may have also already hand hacked an opensource wiki to incorporate such a feature.
But I suspect this hasn't appeared in the mainstream products yet and it needs to soon, to completely unlock the power of wikis, collaboration and structured data combined for the first time.
posted by Ross W Nelson at 8:23 AM
0 Comments:
Post a Comment
<< Home