User:Micenmen/sandbox
SolveIt Wiki is intended to be a revolutionary new tool for problem solving, debate resolution and goal management. The hope is to develop a structured procedure for building various knowledge bases which depends on problem solving. The founder of this wiki had been engaging in debates online, about one of the more prevalent and controversial topics, and had noticed that the same well refuted points were regurgitated time and time again, An earnest desire to get to the bottom of the issue and re-solveit. led to contemplation of a knowledge base in which the standard (un-refuted) response could be presented once and for all, to refute the repetitive canard.
Such knowledge bases may exist in various areas of interest, but the problem here is that they are closed /private volumes and may be protected by strict copyright laws. In this day and age it is become quite evident that an open and cooperative approach to information processing, is producing unsurpassed results. Rather than begin any specific topical wiki, with a view to collecting knowledge and answering questions about any specific subject matter, we may observe that there are general principals, methods and modalities which are common to any such pursuit. The process always looks like a problem with an objective that can be re-solved to produce a conclusion. If not then we must be content to produce something else. It may be just a report on the intermediate questions which cant be resolved and why they are lacking answers. Whether we are looking at an article of contentious debate, an interesting research proposition, or an action plan for a corporate launch presentation for instance, all affirmative actions have objectives they attempt to accomplish. They all begin life as a problem seeking a solution.
Whenever you 'SolveIt', you are clearly doing something universal and goal orientated. Moreover there are common patterns and properties in the process and problem to be solved, Properties of the problem (by which I mean any charachteristic they may have) that are typical of other problems, will give us clues to make clearer pathways in the process of devising solutions for the problem in hand. To get a general sense of the truth in this, consider how metaphores and anallogioes work. The more unrelated they are by subject matter, the more impact they have on our sense of the conectedness of ideas. The more profoundly we feel, the underlying patterns of interrelationships between disparate ideas, the better we are enabled to generalize on solutions, and find them without reinventing the wheel. While each problem has particular properties, they also have modes and methods. A metaphor of note (you will see it used again in this site), can be drawn with the analogy made between SolveIt and the structure and general strategies of an object oriented programming language. The founder is not any more than an amaturish dabbler in computer programming, so there is no risk (as yet) of a convoluted technical discourse, but I will kick off an article, that presents this object oriented programming analogy, and gives a very non-technical laypersons explaination of Object Oriented computer programming.
In contemplating how to categorize items information of unresolved outcomes such as articles of knowledge in question, plans or goals or any idea wanting for a solution, we may notice they each have particular properties, but also that many of those properties are common to a range of other problems. Solveit wiki begins with the observation of these properties, of which there are four types. I have briefly considered other types of grouping including a five column model, but These four seemed to emerge as something like natural property sets that all task oriented ideas have. Be that as it may, I am promiscuously willing to conspire with any design modifications that might lead to any improvement. See the caveat in 'How to Become involved and why'
'NB (a note from the founder)': I can't state this emphaticlly enough. I do not wish to be a lone wolf PLEASE UNDERSTAND: This is the first estimate of a problem solving tool bassed as it is on, my ideas and assimilated knowlege of information techcnology and information theory (IT&T you might say). I have also incoporated other general planning and pondering experience of PIMs (personal information managers) including my struggles with making them do what I want. My layman postulation (from reading popular science) in physics / cosmology / natural history and genetics, has revealed to me some appreciation of thermodynamics that may give some background reflections. I am a diverse dabbler in many feilds. I have no formal qualifications in any field and I do not presume to even know the best way to do anything, not even tie my own shoe lace. It should go without saying that in the best spirit of colaborative development, That the most important part of the ideas is that it is planned from scratch to be the product of a community; the collaborative triumph of a community who may together accomplish far greater things than a multitude of solitary people working at personal gains. Being that as it is, I would (as each of us should) expect anybody with any idea / suggestion to come forward not just 'even' if it contradicts the present description, but especially if it does. The defining feature of a viable improvement, is likely going to be a definite change in some existing characteristics of the system. You can't expect major improvements without change. Let's not miss the opportunity to make SolveIt work better by avoiding the mention of a good idea, just because somebody might be offended if it challenges some parts they devised. Conversely we must all give latitude to design modifications that may even undo some contribution(s) we made earlier. We should all at least try to consider the consensus. If we do that and remember nobody wants to deliberately make changes that deteriorate the end result, then It should be easy to keep cooperation above ego.
Firstly we need to define some Identification / definition information, in which the item is named and defined this might be known as the declarative properties. The next type of property is the purpose or objective, which could be known as intentive. The next type of property involves identifying a method of solution or qualification, lets call it the transitive. Finally we meet the imperative properties which prompt us with actions to be used in the problem solving task. The left most column is for any information which might be used to declare information about each particular subject that is for identifying it uniquely and any other information input that might be neccecary to find resolutions. Not all subjects /tasks, must resolve to definitive answers of course, or even to definite goals. The objective may simply be to state an opinion . That is still a useful objective as it puts a defined conclusion on record.
The Declarative fields may have numerous properties and sub properties. The more the better the definition of the Subject in question SIQ is unlimited and any potentially useful information may be included for good measure, even if it is not used at first, or at all for that matter, anywhere in the problem solving procces and/or outcome, it is still very useful, it it is a real property of the SIQ. The benifit of as much detail in declarative data, is the ability to facilitate data search, aquisition and to generaly make your knowledge/database more adaptable and useful to unspecified third parties. The extra detail, might also help if you decide to adapt the same knowledge base for a wider context, that could make use of the extra data. The other point I would make about the Declarative column is that it may contain a nested hierachy of subjects and this reflects their relationship of subordination and inheritance, as each item may be a property of a parent item. The declarative should also contain a summary of the subject item and description of the objective/problem to achieve/solve. This nested hierachy with inheritance of properties, allows for powerful data structures to be made. Meanwhile, all of the items in the table must have the properties which span horizontally and inherit according to independent rules laid out in the data structure of the knowledge base.
The convention of defining properties to fit these horizontal classifications allows us to use universal rules for data-handling-casting and processing a search query for instance can anticipate the existance of some informtion to define the transative so it might search for marketing terms that would be
| Declarative | Intentive | Transitive | Imperative |
|---|---|---|---|
| This includes the name of the item it's deffinition date of submission and any other information belonging uniquely to this problem. | These proprtities reflect anything that can be used to specify purpouse or intention in the resolution of the problem | These are properties of the problem reflected in the nature of the solution. | Specific methods and actions that can be taken to resolve the problem. |
EXAMPLE:
| Declarative | Intentive | Transitive | Imperative |
|---|---|---|---|
|
NAME: No true Scotsman Fallacy (other declared data must also be provided) |
MODE: Evaluation | Delineation: Principal (in what terms sucess is defined) | Outcomes: Premises Reason, Conclusion, flowchart, Fallacy Flag. Derive Identifiers. |
| Alternatives/Options: | |||
| If the above informal fallacy were to be presented as an actual instance, then you would expect to give a name to the specific instance as well as the appropriate properties. | goal, delegate, dispute, meeting, revision, statement | opinion, factual, probability / speculation, completion. presentation. pleasure, self validation, publicity, Re-definition |
resolve, example, negotiation, flowchart, experiments, debate surveys, identify deeper question. Venn diagrams. various charts, reports & forms. Budget Items, PIM Objects like Contacts, TO-Do's & adjenda items. Request for help, 'Reformulate New Subject' (must have all ) Hash tables, variable definitions, databases. |
| Bush Explains the Justification for Expecting WMD | Dispute | Factual | Debate / resolve / deeper questions. |
Some processes will require back propegation and retrospective definition of new properties. or assignment of old. Methods should be developed from one general template to allow users to check that their subject (Input Item) is fleshed out to satisfy it's intentive and transitive properties. There will be very stringent criteria for some (Input Object Nodes) if they elect to establish empirically and/or practical task laden properties of their Outcomes. This is because some processes will require particular information just to be useful. If a subjinQu or SIQ (Subject In Question) is specified as aiming to resolve a query requiring some formal logic, it absolutely must have some starting premises. By nominating an intentive mode we are setting up a single choice, that sums up what kind of dynamic property (action) we expect to perform. This has entirely separate intentions / objectives, methods and kinds of outcome, from each of the other modes. From the intenitive choice, it is invisaged that collections or families of transitive properties may be presented these are not exclusively dependent on which intentive choice was made, but rather appear if they are relevant to the intentive. So one such property, say 'factual' may be common to a number of groups, but if the intentive were 'goal' for instance, you wouldn't expect the property 'factual' to be available in the
Another way of looking at the SolveIt model, is that it sets out a specific problem, and leads you to the general solution. The declarative is all arbitrary user information, but users will narrow down the classification by nominating a purpose in the intentive. The intentive is a multiple choice list of properties that focus on outcomes. So you start of by naming / nominating and describing a problem, then the next thing you must do is decide what can be done about it. The choices may be such things as Dispute, Goal, Query, Delegate etc. If there is nothing suitable in the list of available choices, then you would have to define your own. The properties which are available in the imperative type will depend on the properties selected in the transitive type. Likewise the properties in the transitive will depend upon the choice made in the intentive. A problem may be ascribed unique new properties although it can also co-opt existing properties. It might help to imagine those old adventure games in which you could only perform certain actions on certain things. Each object is a self contained nested hierarchy of properties inherited and/or uniquely defined. Each property itself, may also have a number of sub properties.
Another analogy is that of object oriented computer programming. Each of the problems to solve, have properties in a manner rather similar to the object oriented programming idea of a 'class'. A class is an encapsulated chunk of instructions called a method, along with some properties, which are called just that, 'properties'. The methods of human problem solving are usually performed by the human managing them. If you do have a means of generalising though, then functional similarities may be tackled with more general procedures. You may notice that of all of the things I have called 'properties', it includes the items in the imperative category. If you look at those items, you may notice that they are all rather action related. They are all 'doing' things. In a sense you could regard these items each as 'methods' of imperative action. Unlike a computer program we don't have a general procedure which begins an crunches through a series of well anticipated decisions that account for every contingency. It would be asking to much for a problem solving algorithm to anticipate every contingent problem possible and present a method of logical troubleshooting.
General problem solving must still rely on human intellect, if not forever, then for the time being at least. Having said that, there are a surprising number of analogous problems and many are based on variations of common fallacies and similar causes, however disparate their actual instances may be. That intention is to provide a problem solving tool, that does what is possible to connect the generalities of all our problems and also develop and present a knowledge base that can strive for power and flexibility, without re-inventing the wheel. Among the Imperative properties (where SolveIt gets down to practical actions), is an option to create a flow chart, now this item is altogether a potential property of the whole task (the particular problem being solved) as well as a tangible resource that can be used as a practical tool like a screwdriver, and even given to others as a copyable resource. Other qualities in the first three coloums are not tangable in this way. All of the imperative items are tangible in that they provide hands on outcomes. The flow chart is especialy interesting because it is the one which allows us to describe any process. Solveit is intended to not only help you fix the hole in your bucket, but to describe the process that led to that solution. The process of anaysing your problem, should lead to general trouble shooting procedures. If your problem is anything like other problems (and it is), there will be a way to draw a flow chart that describes the procees of troubleshooting that will have a wealth of possible similarities with other solutions. Even without the menacing sounding rhetoric of problems' and trouble-shooting, you can use flowcharts to describe solutions that are not problems in the negative sense. Opportunity is an as yet unsatisfied goal you may strive for if you care to Solveit. Any problem (in any sense of the word), is just an opportunity if you make plans to SolveIt'.
There are many knowledge bases out there but those that have specialized in one area of knowledge, are typically still on websites which are read only to the public. That may be a good thing in some cases, but the open accountability of the wiki model is becoming the standard par excellence. The other limitation they usually present is a static model of enquiry that only allows users to investigate the content as a slab of formated information. The facts, decisions, opinions or ideas presented, can only be taken at face value, because the knowledge base is not designed from scratch to embed conceptual relationships between the ideas and how they were founded. SolveIt will be a unique approach that will allow the strengths of intuative human planning and understanding to be combined with powerful programming principals while software is employed only in tasks and process that can benefit from the software in whatever task it is employed for to satisfy the final outcome. An important point is that the dedicated software approach to any problem, may be prone to limit what tasks the solution can be applied to. If the computer program is expected to define and process the whole task, it can only do so by prompting a human user for objective input and make what ever logical choices were anticipated and allowed by the programmer. It will be a narrow determanistic process. Using the computer rather as a tool, to coallate solve and formalize the wide range of subjectivity ladened tasks addressed by SolveIt, is a boon, just as well as the data-mining / data-casting and colaborative aspects would not be possible without the internet.
Please feel free to join in the development of this exciting project. Check out: How to Become involved and why, Thanks for your interest in reading this and for dropping by. Bookmark this site, and look out to download our tool-bar meta bookmark & problem solving tools