At 01:34 PM 07-02-01 +0200, you wrote:

>Hi
>I have had an idea for a while now which I think will help to address
>the internal information system "problem". The basic idea is to create a
>knowledgebase but with a difference.
>
>Each entry in the knowledge base should have a categories field. THis
>field would work like this. The category entry would be percentage
>dependant. In other words if it fits a particullar subject well it gets
>a 90% fit. With the ability for one entry to have multiple categories.
>The result would look like this
>Entry1
> Category1 90%
> Category2 45%
> Category9 85%
>
>Each entry should also have a keywords entry. This would work on the
>same principle as the categories where a keyword could have 100% to 10%
>relevance.

We have categories, sub-categories and keywords. Personally I don't see
how the percentages idea would work, I think "AND"ing and "OR"ing the
keywords will get a more useful set for an individual. After all, who can
estimate "fit" to a particular inquirer's needs? I have these
relationships set up many:many so you can grab all the entries for a
keyword, or all the keywords for an entry, or anything in between, e.g.
you'll be able to drill into just the items you want to see.

The nature of a problem very often is that the inquirer doesn't KNOW the
nature of the problem. Seeing all the keywords associated with an item
(these can be unlimited but typical there are 2-5 for each item) will
provide clues to more clues for this kind of inquirer.

>The third aspect of the knowlegebase would be a "links" field also with
>a percentage attached. The linksfield will have a additional property
>called direction which would have 3 value -> or <- or <-->.
>The purpose of the linksfield is the following. When I do a search on a
>specific subject I would specify: find me all the categories that is 90%
>to keyword X and search for all the links 50% strong 3 levels deep.
>
>The result would be that I would get N results that is related to each other

That's doing it the hard way by numbers instead of the easy, intuitive way
by relationships.

>Result1
> Result1.1
> Result1.2
> Result1.3
> Result1.3.1
> Result1.3.2
>Result2
>Result3
> Result3.1
> Result3.2
> Result3.2.1
> Result3.3
> Result3.3.1
>
>The power of this is that result 1,2,3 would give me a immediate answer
>to my question where the subresults would give related answers and help
>to solve other problems that might arrise.

Maybe, maybe not. This approach also rules out the possibility that the
inquirer will find his answer via a keyword in a related item. And I still
see NO way to quantify the relevance of an item to an unknown problem.

>The proposal is that a web-page with subscription option should be
>created where this database resideds and where members may add contents
>links etc to the database.

It's intended that some members may add contents when we get it to the
stage where it can be done. We have plenty of people both knowledgable and
responsible who could do this. However, we don't want the FAQ to end up
like the bugtraq on Sourceforge - full of "idiot" bug reports from people
who don't know the basics of the subject. Transferring this to the IBO
situation, consider how frequently list members post a message saying "Bug
in IBO" and this "bug" goes away when an SQL statement or a KeyLink gets
corrected...


My late-night thoughts, FWIW.

Helen

All for Open and Open for All
InterBase Developer Initiative · http://www.interbase2000.org
_______________________________________________________