WissDB . since Jun 15 . Index . DOCs TOP TOC
Definition owner is C_WissDB_API
Value Specification:
An object of type B_Query_Specification is
§ the root SR of the folder that shall represent the knowledge package you expect to get as a search result
§ and directly under this root an ASCII text file SR/Selector in which you specify the query to select knowledge from the WissDB B_Knowledge_Base.
The content of SR/Selector has to match the following pattern und is to be understood as a pair of filters such that the first one is specifiying items to be included into a preliminary search result from which then the final search result is derived by excluding items the user is not interested in:
WissDB Knowledge Selector
The first column of this file is - on a graphical user interface - presented in
form of check boxes. A box is checked if and only if the corresponding line in this
file here contains the minus sign in column 1.
Lines not starting with a minus sign in column 1 are treated as being comment.
- The Include Filter:
Not checking the include filter is asking for all knowledge.
- Type
Not checking Type is the same as checking all these Type identifiers:
- . Process
. Description of Process
. Description of Role
- . Description of Result
- . Description of Practice Candidate
- . Solution Requirement
- . Solution Concept
- . Solution Code
- . Business
- . Technology
- . Advice
- . Information
- . Aspects
Scope
Not checking Scope is the same as checking all these Scope identifiers:
- . Result
- . Best Practice
- . Lesson Learned
View
Not checking View is the same as checking all these View identifiers:
- . Conceptual
- . Logical
- . Physical
- . Transferential
- Abstraction
Not checking Abstraction is the same as checking all these Abstraction identifiers:
. Solution
- . Template
- . Pattern
. Strategy
- Aspects
Not checking Aspects is the same as checking all these aspects (which will in the
WissDB Default Search Descriptor - be all aspects that are not part of any other aspect):
. Bid Proposal Management
. Project Management
- . Software Development
. Software Support
- . Software Maintenance
Note: As far as aspect locators L are shown here not starting with a number, they have
to be understood as 1/Aspect/L (1/Aspect being the default classification schema).
There may be project specific classification schemata as well.
- Projects
Not checking Projects is the same as checking all projects (which will in the WissDB
Default Search Descriptor - be all projects that are not part of some larger project).
. 1=Default
. 2=Kogito
Role Specification
Not checking Role Specification is the same as listing all activities.
{
A Role is seen as a set of activities (= processes or subprocesses):
The definitions here will restrict the search results to items that are part
of Results produced by one of the following processes (resp. subprocesses
thereof):
- 2/Process/Software Development/Test
- 2/Process/Software Maintenance/Test
1/Software Development/Test
1/Software Maintenance/Test
}
Note: Locators L shown her not starting with a number are to be understood as 1/L (for
Results), 1/Aspect/L (for aspects), 1/Process/L (for processes).
- The Exclude Filter:
{
Not checking The Exclude Filter is asking the system to ignore this section.
Excluding Aspects is reducing the set of keywords.
- Aspect/Bid Proposal Management/Tender Preparation
Excluding a Process will exclude all Results produced via this process.
- Customer A/Process/Software Support
- Customer B/Process/Software Support
Excluding a Result will exclude all parts of it:
- WissDB/Result/Test
}
The Search Result: Included and excluded objects
This section is read only it will be generated by S_Search_for_Knowledge. text=#000000 link="#FF3333" vlink="#FF3333" alink="#FF0000">
Items checked via a minus sign in the first column of this section are items not excluded
from the search result. If too many items are shown to be excluded, the user can edit the
Exclude section and then again submit this selector to the S_Search_for_Knowledge service.
For excluded objects no structure is shown.
{
}
Rationale for this design:
Users need to get a good feeling what effect it will have
§ when they augment the exclude section by adding specific locators
§ or when they re-scope a tentative search result by
changing the role specification or
or by removing or restoring minus signs in column 1 of the search specification file.
Furthermore, given any knowledge package that came into life as a search result, users can always see what the query actually was.