Garo Garabedyan- a private blog

Creating a common language for describing in machine-readable form citations in web is the goal of the Protocol for Web Description Resources (POWDER), released by World Wide Web Consortium. By using Powder’s specifications, a Web site can make claims about where information came from and how it can be used. [http://www.technologyreview.com/web/23355/page2/]

Similar approach can be implemented in Content management systems (CMS) and document revision (sub-)systems.

I have red and I have tested a new tool called WikiDashboard (WikiDashboard.Parc.com) which uses the live feed of English Wikipedia and presents a summary about the editors and what amount of information in percents they have wrote in a particular English Wikipedia article. The tool and the idea based on how people collaborate is awesome.

I have a single appeal to add the functionality enabling to mark a piece of a wiki page and query who is the author of it and since when is the current revision of the marked content. I was always dreaming for a tool to synthesize the revision history of a marked piece of a document, but this is still a complicated task in general. Wikipedia content is filled not only with characters in general, but with tags (i.e. <ref></ref> for citing Internet or other resource as a used source) and other special formatting markers, examining their behavior through the revisions is an important base of determining how to present the changes (differences) in the revisions.

While working on different documents and using many sources of information the user sometimes forgets what he was doing or even worste he loses his focus over the work without realizing this lost. I think that the best way to keep focused is do know what are you doing and in this way of thinking using Documents revisions is a very powerful way to do so.

Imagine GDocs to present you not the latest edited documents, but the concrete revisions of every document and this way to let the user to track his work.

In a relation with: Event Based Content Editor.

Wikis are even so powerful because it mimics the way we work in real life in order to produce content. When we work in collaboration the aim is the same. Wikis help to keep the aim and to avoid any other misunderstandings and waste of time in communication between the team members.

http://www.commoncraft.com/video-wikis-plain-english
Common Craft Show about wiki as a coordination mechanism between people.

Saving the data in one lace is not a revolution of Wikis. This is a known technique, which wikis share.

Data Immunity (opposite of Data integrity)
Free to make a change which will be applied until someone changes it
While editing wiki page there is no any conversation between you and the other collaborators. This is a good characteristic in order to do what you really want, to reach the main goal of the project. If the collaborators are many it is hard to get into a some consensus about something, sometimes the other collaborators have no opinion about your change. But when you apply your change directly, only people who have arguments against this change will talk to you (or just erase your change).

People were scared at first look at wiki. They all have been thinking that people will be like vandals and will mass delete and change whatever they see. They think that collaboration between unknown people have to be first in talks and later when everything is set down, it to be applied in homogeneous final work.

This process as described above is only in real life. By IT we can save all the revisions which in real life is too heavy to be done (revisions are sometimes so much and so small in their change). We can provide a continuously edit and update of wiki article which is too hard in real life process of collaboration.

Express your opinion independant
Blogs and Forums are competitors of Wiki only when there is a discrete topic on which all members want to express their independent opinions. At this case blogs and forum present editing capability only to the author of the concrete post. At this case the saving all the revisions is not needed.

Wiki is useful in Enterprise
Wiki enables full and dynamic collaboration on the topic of the job and lets executives to see who and how much work have done.

Commenting (or expressing independant (not mass editable) view)
Because of the mass editing nature, expressing independant opinion should be protected by the revision history engine in the wiki. In other words to inherit the motionless nature of the pure revision and this way ignore the dynamic behaviour of the wiki content at all in order to save the independent view not changed.
Making comment like a chronologically presented opinions is too motionless technique for the virtual enterprise collaboration. Everything in virtual world is dynamic, especially about the enterprise where things must be dynamic. So making comments have to be tied with something static (the revision itself is a good candidate in example).

Making comments in Wiki articles have to be tied to a concrete piece(s) from the last current revision. This means that a comment is related to the revision and to a piece from the document. This comment must not be presented to revisions older than the current. This comment have to be presented to newer revisions until the linked piece of the document is not changed, at such a case the author of the comment is alerted and he or she has the right to republish the same comment if he/she things it is needed.

New Office Packets with Wikis
When we collaborate in real life in order to finish a particular job we behave like we are in an on-line forum. Usually our colleagues calls us with some request about some work, if we thought that we need some additional information in order to finish the job, we call our colleagues and ask them about the needed information.

We all use paper folders in our real life jobs. We trust our colleagues that they will not replace of steal some document from this folders.

Now, let me describe you the future Office Pack which will have this capability in itself.

You will be working not with a single document, but with a hole bunch of many documents stored into one secure archived Office file. This file will be secure and nobody can replace a document from it. To this archive wil be added a default wiki which will coordinate the editors about the TODO list and so on. Every piece from the content of every document can be addressed and referenced from the wiki article.

Document revisions would be a statutory to the new way documents are going to be edited
In future bosses will use document revisions in order to review the work of every editor (worker) in collaborative on-line jobs. No matter is the document a Solid Works model of an engine or a brochure for a piano concert. This will be all inspired from the mass usage of document revisions within Wikis.

http://garabedyan.wordpress.com/2007/11/18/ajax-wiki-editing/
Ajax is useful to wikis because it can make fast editing and with a special JS code Document Revision recognition can be done while the article is editing.

This kind of editing would be a little bit advanced.

Editors will be able to mark with special tags the content (piece of the document) which they are not sure about while they edit content relative to the first one. We talk about a parallel work on one document and in usual people who work on it are not specialist in what the other person is doing. It is something important because in default people thing that when you edit (fix) something you try to make it true, but if something on which the last thing is based on is not true (I have written a post about how to technologically present such relations), you are responsible only for your work. When your work is closely related to something which you can’t predict, something that you don’t know, you need to claim that you don’t want to be responsible for it while doing your job.

Idea: Document revision for a concrete piece from a document
Imagine you want to trace all changes of a piece of document, not the whole document. How a piece of document is firstly too small, then is getting bigger with a lot of information in it. In this period of grow it is sometimes deleted without any pieces left.