Help! more questions...

[Bruce Frederiksen]

Hi Everybody,

I'm back to needing more questions answered.  These are probably most for James, but there are questions at the end for you HTML experts!  (And don't be shy if you've got ideas for anything here)!

Versioning/Sandboxing

In playing around with this so far, I think that way that versioning and sandboxing works needs more thinking.

Right now, the idea is that there is a single linear sequence of production versions (in the "history" folder), and then any number of sandbox versions which would be based on the last history version.  There are two problems with this:

1. There is no provision to delete a production version, or even to side-step it and go back to a previous version to make a new sandbox from.
2. This requires merging sandboxes, and resolving merge conflicts is messy.

So first question!

Q1: When the expert goes "oops, shouldn't have promoted that!".  What does he do to fix this problem?

1. Delete the version.  All of those changes are gone forever.
2. Convert the version back to a sandbox to play more with it and fix the problems.
3. Sideline the version.  The version is kept in the history, but won't be used for production and will not be the default version to create new sandboxes from.  (Maybe there would be a facility to create a sandbox from this sidelined version to fix the problems rather than discarding all of the changes made in that version).

Now on to the merge problem resolution...

There are basically three possible ways (that I know of) to deal with changing the knowledge:

1. Allow many different changes (sandboxes) and merge the results (current approach).
2. Only allow one set of changes (one sandbox) at a time.
3. Allow many different changes (sandboxes), but require each sandbox to lock the objects that they change.  Only one sandbox can have any particular object locked, so there is no need to merge changes.

The problem with the first approach is that it can lead to occasional merge conflicts; and so we'd need some way for the knowledge engineers to resolve these conflicts.  And this merge conflict resolution is messy, and I think that it would be hard to teach to non-computer savy knowledge engineers.

The third approach leads to the problem where you really need to change object X, but some other sandbox has it locked.  So you'd have to have a way to report which sandbox has it locked (not too difficult), and then probably have a way to unlock that object in the other sandbox.  This would mean either discarding the changes made to that object in the other sandbox, or bringing those changes along with the lock into the new sandbox.

The second approach is simple conceptually, but doesn't allow different groups of knowledge engineers to work independently of each other.  If they are all working in the same sandbox (since only one is allowed), then one group will have their changes ready for production, but not the other group; and so the sandbox can't be promoted.  Then the first group can't continue working (which would make their stuff no longer fit for production) until the second group finishes, the whole sandbox is promoted, and a new sandbox is started.  I would expect that it might take some time to get the knowledge ready and so the first group could have to wait quite awhile...  One way to somewhat avoid this would be to partition the whole knowledge base into several units, one per branch of medicine.  Then each branch of medicine could have its own sandbox.  I don't know how independent the rules in one branch are from the rules in another branch.  For example, what happens if a pulmonary test case shows an error because a cardio diagnosis is showing up erroneously?

Q2: How do we solve this merge conflict problem?

Directory Structure

Right now, the directory structure for the knowledge base looks like:

• diagnosis
• symptom
• sign
• investigation
• rule
• case

Q3: Is this the right directory structure?  (for example, should "symptom", "sign" and "investigation" be subdirectories under a "question" directory)?

Q4: Is this the right order?

Q5: Which of these directories should allow the users to reorder the objects in them (vs just keeping them in sorted order)?

Q6: Should the whole knowledge base be divided into branches of medicine, with the directory for each branch having the directories above as subdirectories?

• pulmonary
• diagnosis
• symptom
• sign
• investigation
• rule
• case
• cardiovascular
• ...
  
• ...

Q7: If so, then should each of these branches also have it's own history?  Own sandbox(es)?  (But how do we handle cross-dependency between the rules from different branches)?

UI Pages

These questions are directed to the HTML experts in the group!

I've been thinking also about the UI stuff.  It seems like there are generally 4 screens with each object:

• list (shows a list of all of that kind of object)
• view (shows one object in detail, with add/edit/delete buttons)
• add (add one object)
• edit (edit one object)

It seems like these would all be based on HTML tables, and the last three would have the same structure and could use the same template.  What I'm wondering is whether we can use the same list template and view/add/edit template for all (or nearly all) of the objects and not have to create many copies of nearly the same thing.

Q8: Am I on the right track here, or am I barking up the wrong tree?

Q9: Do we need any buttons or checkboxes on the list view?  Or is there just a link to the view page, and then you do the add/edit/delete there?  I guess if the list is user orderable (rather than simply sorted) than you'd need move-up/move-down and add-here capabilities.

Q10: Are any of these lists so large that we need to something besides a scroll bar to help the user manage the numbers?  If so what?  (e.g., breaking it into sublists for names starting with each letter of the alphabet).

Getting these answers will help me to move along and make progress.

Thanks!

-Bruce