WikiObjectComments
Questions: How do you suggest others participate? Could you please write a user story or two? (How WikiObjects could be used?)
-- BobHaugen
I'd suggest participation in whatever way you can. Your questions are a good start. I guess we need to identify the roles that need to be filled and look for volunteers? coordinator, editor, designer, programmer, etc?
I'll start WikiObjectUses.
-- JimScarver
I think almost everything below "operations", especially "submission and delivery", "roles and permissions" and "language ..." to be delegated elsewhere, possibly to an agent based computing model. i don't think wikis should be overfeatured with things other software is designed to do, and it isn't neccessary.
I am happy you go as far as operations==== They include all the things one ordinarily do on a Wiki allowing them to automate the human processes that are repetative and error prone. Ward was also very receptive, though I haven't got his comments yet, I anticipated he would be a purist and not want to extend Wiki at all. Instead he also longs to find a way to make ObjectWiki a reality. I think WikiObjects is the right direction.
==
"submission and delivery" - Collaborative knowlege management requires communication. Wiki today is the antifisis of email, it is passive communication, you have to go in and search for what is new of interest. Notification on new pages and selected updates can help, but, the day may come sooner than you think when "You have 500 emails waiting====" There is a better way. I want to be able to program my notifications get a one page daily summary email with links. I'd like to be able to share my program with others. Given the basic operations I propose plus some basic looping and alternative constructs, I could do that on my wikis. If other people don't like it, they don't have to use it.
==
"roles and permissions", Wiki has always been open, and I recommend open communication systems and prefer them myself. But the real world is not that open and the lack of support for roles and permissions in Wiki severly limits its application. EIES research has shown that people will not collaborate unless their privacy and ownership is protected. I want to use one environment for all my group activities and that requires "roles and permissions". In addition, as soon as you add programming capability. You need controls to prevent accidental or deliberate screwups like rm -rf /
"language support" - the programs I write are also text. Why not manage them and share them in the same way as other texts? Common data and program storage is the heart of the Von Newman computer archetechure that give us general purpose computing. I am not proposing that the language support be added to Wiki, just that there is a gateway from Wiki to the laguage processing environemnt and that both information and proceedures are sharable.
More is addressed in the respose below. Let me add that it is much easier to provide general purpose user programmability than meet all the needs of collaborative knowledge management and group processes. The EIES experience suggests that if you give users the power they will tailor the system to better meet their own needs and the needs of their group.
I copied the following from the meatball list -- JimScarver clemens fischer wrote:
%%%>i see serious issues with the execution of code in your proposal. not only %%%>for security reasons (see the vi$ual ba$ic worms destroying what's left of %%%>micro$ofts bad reputation),
Indeed, there are serious security issues, but their are also solutions, my aim here is user programming first, application programing second. It is prudent to not use IE or serve MS to avoid many of the problems. Wiki cannot solve or avoid many them.
There are two types of execution at issue, active text excution at display time and explicite execution of objects. One could disable the active text and only be denied dynamic content. Support for dynamic text simply extends the potential application areas and can give us a common simple inferface to most all our applications. Explicite execution is not subject to some types of misuse and is where most of the community programmability benifits come from. One must still trust the owner of a proceedure before allowing it to run with their priveleges. A longer term objective of ObjectWiki should be that proccedures be simple and human readable (natural language like) with self evident effects.
The only execution I am proposing here is on the server side.
And my emphasis at this time is defining the declarative methodology, as far as execution goes the last thing I want is another monolythic system, execution will be using other peoples software and the security that it can provide. Note that I failed to mention visual basic as a desired or probable language but we can bet people will want it, oh well.
%%%>but also because people will use it for
%%%>commercials. close to 100% of all javacsript today isn't used for the
%%%>benefit of the user, but for simply pushing home the extra buck.
You can do more damage with a bulldozer than a shovel, but restricting user programmability is not a solution, it just means those with power to do good or evil with the technology will be a more elite group.
%%%>since i'm alynx user re. wiki's, i'm opposed to superfluous and risky %%%>things like that.
The way to control it is with group norms, not enforsement in the software. It is important that we only consider features that will facilitate collaborative knowlwdge base development and maximize the synergies in turning text to information. Safety, security and privacy are of the upmost concern for many group processes and I would oppose anything risky in that reguard.
%%%>also, i think we should define what we need first, then do a series of %%%>prototypes until we know what goes wrong.
I could not agree more. We should start with objectives, and take an Extreme Programming approach to realize them.
%%%>first thing i want to see in current wiki's is: %%%> %%%>1. notification lists for each page and every user, so that one can %%%> subscribe to single pages on an individual basis.
Page updates are one important event we would want to watch. We need to identify events and be able to queue actions for those events on a per page/activity and per user bases bases. Different group activities can have different states and events. We are most interested in basic collaborative authoring initially-- new page, and page update would be the primary events of interest but a general capability to watch and trigger events is most usefull in collaorative applications.
In addition to event processing, a collaborative environment needs communication capability. Emailing wiki pages can provide the necessary interactivity. It is sufficient for notifications and with some basic work flow support can neet most needs.
Finally, handling lists and adding attributes to pages have application far beyond update notifications, rather than adding specific features, what I am proposing is the ability for anyone to add features to their pages and share those features with others. This is what EIES did and everyone was sure there would be systems on the web that work the same way. But so far their aren't any I have seen, it seems that if we really want to share proceedures and information in a simple manner we will need to do it here.
%%%>2. a voting feature. it is very hard to get people to collaborate.
tell me about it....
%%%> ... what i need the most for my wikis is
%%%> this voting feature to make the folks arrive at decisions by vote.
Voting is one important group coordination tool. Yes/No votes, however, depending on the communication structure it is used in may not be any better than a coin toss in developing quality group decision. In EIES we had standard scales for agreement, desirablitity, feasability, etc., as well as custom scales and rank ordering.
The most usefull feedback tool, I think, used properly, is rank ordering, since it allows "virtual" runoffs between all the alternatives given the individual rank orderings without further action from the individual voters.
Votes should allow (encourage) comment. An unsupported opinion does not really aid the group process. It becomes mob rule. Why people feel the way they do is as important as what they support. The group process should automatically capture the issues, pros, cons, and dependencies to the greatest extent possible at least in important questions where we have a stake in the quality of the solution. -- JimScarver
I'm really interested in the project, but don't know yet what role I want to play.
I'm most immediately interested in arriving at agreement in threadmode Wiki conversations, which I think could be modeled as speech acts. I'll be scratching my head about how to do it as I read other contributions to the discussion.
I'm also skeptical about SOAP as a way to implement this stuff. I suspect REST (the HTTP architectural style) is the simplest thing that could possibly work, is native to the Web rather than being native to internal systems, and the REST gang might be interested in this project. I know I am. Check out [1]. -- BobHaugen
I include http queries and posts, that's REST no? The future stuff in REST will be cool for ObjectWiki when is becomes mainstream. For now we don't care about anything that does not run on an HTTP1.1 server. We are creating a ubiquidous collaborative object environment and it better work on anybody's server.
I'm not as up on REST as I ought to be, I expect it will be the next wave in web services. I don't get the hollaballoo on URL syntax, URLs are locations, and should be arbitrary. Objects can have many URLs, one for each copy. I'm not sure we can easily control urls. My main concern is URNs, resource names are important, locations are not. What did I miss?
SOAP is supported in every language, even Javascript, we can talk to anything with SOAP. There are thousands of public services using it and business is adopting it for middleware in a big way. SOAP gives us a lot of power right away.
SOAP is clumky and has a lot of bells and whistles we generally don't need. It's a syntactic nightmare in some respects and it takes a lot wrapper for a little content. Rest assure that when REST is ready we will use it. If the rest group wants it now, we welcome them with open arms to make WikiRestClass work for us :) Feel free to insert some links and samples to get it started.
REST is just HTTP plain and simple. Nothing new required. Don't worry about it, I'll keep reading and when I think I have grokked your intent, I will attempt a RESTificiation. (Or maybe it will be RESTful already, we'll see.) -- Bob Haugen
In thinking about discussions, start simple, don't test your personal theory of solial interaction just yet. Think about a heirarchy of classified communications. Classification I suggest, implying the object model over catagorization which only implies structure. Classification, in the object sence implies behavior or action in addition to meaning.
A key thing we did in EIES that works well is archiving by the reply heirarchy (outline numbered) but offering delivery of new (unseen) items only and summarize all new item counts by discussion. EIES allowed viewing items in any order keeping track of what you missed. Modified items were redelivered. Replies were controlled by the Activity class of the root item. We found that most activities could be derived from a basic List activity (let's make a list) which provided much of the basic functionality. These included sub discussions, Question or Brainstorimg activities (encourage independent thinking by not showing you other replies until you reply), outlining, ranking, selection, voting, exams, etc.
Once we get the basics in place, modeling and testing the utility of your social interaction model should be easy :)
In the mean time, keep up what you are doing, it's geatly appreciated, I have poor organizational skills and need all the direction I can get. You can see I'm obsecced by this project, too bad it doesn't pay the bills :) -- JimScarver
"heirarchy of classified communications" probably works for me. --BobHaugen