Oracle8 ConText Cartridge Application Developer's Guide Release 2.3 A58164-01 |
Library | Product | Contents | Index

# A
Result Tables

This appendix describes the database schema of the result tables utilized by ConText. Result tables are database tables that store results from the CTX_QUERY.CONTAINS and CTX_QUERY.HIGHLIGHT procedures as well as the output from linguistic procedures, CTX_LING.REQUEST_THEMES and CTX_LING.REQUEST_GIST.

The topics described in this chapter are:

- Hitlist Table Structure
- Highlight Table Structures
- Display Table Structures
- Linguistic Output Table Structures

## Hitlist Table Structure

The hitlist result table stores the results returned by the CTX_QUERY.CONTAINS procedure in the first step of a two-step query. The results can be queried directly to produce a hitlist for the query or combined with the base table to produce more detailed hitlists.

A hitlist result table must be created before executing a two-step query. It can be created manually or using CTX_QUERY.GETTAB.

If the hitlist table is created manually, it can be given any name; however, the table must have the following columns (with names and datatypes as specified).

Column Name | Type | Description
--- | --- | ---
TEXTKEY | VARCHAR2(64) | Unique identifier (usually the primary key for the table) for documents that satisfy the two-step query.
SCORE | NUMBER | Score generated by CONTAINS function for each document.
CONID | NUMBER | ID for results returned by CONTAINS function when multiple CONTAINS use the same hitlist result table.

### Composite Textkey Hitlist Tables

When you perform a two-step query on a text table that has a composite textkey, the schema of the resulting hitlist table is the same as for when you issue a query on a table with a single column textkey, except that a composite textkey result table has additional TEXTKEY columns.

The number of TEXTKEY columns in the hitlist table match the number of columns in the textkey for the original text table. The TEXTKEY columns in the hitlist table are named TEXTKEY, TEXTKEY2, TEXTKEY3,..., TEXTKEYN, where N is the number of columns in the textkey in the original text table. N is always less than or equal to 16.

For example, if you do a query on a text table that has a four-column composite textkey, the schema of the resulting hitlist table is: TEXTKEY, TEXTKEY2, TEXTKEY3, TEXTKEY4, SCORE, CONID.

The resulting TEXTKEY columns in the hitlist table are populated in the same order as they were registered in the column policy.

## Highlight Table Structures

The highlight result tables store the highlighting results returned by the CTX_QUERY.HIGHLIGHT procedure.

Highlight tables must be created before calling HIGHLIGHT to generate highlighting results. They can be created manually or using CTX_QUERY.GETTAB.

If a highlight table is created manually, it can be assigned any name; however, the table must have the columns (with names and datatypes) as specified.

### HIGHTAB Highlight Table

The HIGHTAB highlight table stores query term offset and length information for query terms in documents.

If a document is formatted, the text is filtered by CTX_QUERY.HIGHLIGHT into plain text and the offset information is generated for the filtered text. The offset information can be used to highlight query terms in a document.

The table must have the following columns:

Column Name | Type | Description
--- | --- | ---
ID | NUMBER | The identifier for the results generated by a particular call to CTX_QUERY.HIGHLIGHT. Only used when table is used to store results from multiple HIGHLIGHTS.
OFFSET | NUMBER | The position of the query terms in the document, relative to the rest of the terms in the documents. Measured from a base of 1.
LENGTH | NUMBER | The length of the query term.
STRENGTH | NUMBER | The strength of the highlight table.

### MUTAB Highlight Table

The MUTAB display table stores documents in plain text (ASCII) format with the query terms in the documents highlighted by mark-up tags generated by CTX_QUERY.HIGHLIGHT. This mark-up can be used to provide an ASCII version of the document with query terms highlighted.

The highlighting mark-up tags can be specified when HIGHLIGHT is called or the default mark-up tags can be used.

Note: For HTML documents filtered through the internal HTML filter, the MUTAB stores the document with the original HTML tags.

The table must have the following columns:

Column Name | Type | Description
--- | --- | ---
ID | NUMBER | The identifier for the results generated by a particular call to CTX_QUERY.HIGHLIGHT (only used when table is used to store results from multiple HIGHLIGHTS)
DOCUMENT | LONG | Marked-up text of the document, stored in ASCII format

### ICFTAB Highlight Table

The ICFTAB highlight table stores the ICF output generated by CTX_QUERY.HIGHLIGHT.

Note: ICF output is used primarily by the Windows viewer control to provide WYSIWIG viewing of documents in the supported formats. As such, it is stored as binary data in a LONG RAW column and is generally inaccessible to users.

The table must have the following columns:

Column Name | Type | Description
--- | --- | ---
ID | NUMBER | The identifier for the results generated by a particular call to CTX_QUERY.HIGHLIGHT (only used when table is used to store results from multiple HIGHLIGHTS)
DOCUMENT | LONG RAW | Text of the document, stored in ICF format

## Display Table Structures

The display result tables store the display results returned by the CTX_QUERY.HIGHLIGHT procedure. The display results can be either the document in its original format or the document filtered to plain (ASCII) text.

Display result tables must be created before calling HIGHLIGHT to generate display output. They can be created manually or using CTX_QUERY.GETTAB.

If a display table is created manually, it can be assigned any name; however, the table must have the columns (with names and datatypes) as specified.

### NOFILTAB Display Table

The NOFILTAB display table stores formatted documents in their native format (i.e. WordPerfect, Microsoft Word, HTML, ASCII). No highlighting or filtering is performed on the text of the document.

The NOFILTAB table must have the following columns:

Column Name | Type | Description
--- | --- | ---
ID | NUMBER | The identifier for the results generated by a particular call to CTX_QUERY.HIGHLIGHT (only used when table is used to store results from multiple HIGHLIGHTS)
DOCUMENT | LONG RAW | Text of the document, stored in the original format

### PLAINTAB Display Table

The PLAINTAB display table stores documents in plain text (ASCII) format. The documents are processed through the filter defined for the text column and the results are stored in the PLAINTAB table.

The PLAINTAB table must have the following columns:

Column Name | Type | Description
--- | --- | ---
ID | NUMBER | The identifier for the results generated by a particular call to CTX_QUERY.HIGHLIGHT (only used when table is used to store results from multiple HIGHLIGHTS)
DOCUMENT | LONG | Text of the document, stored in ASCII format

## Linguistic Output Table Structures

The output tables store the results returned by the ConText linguistics. The output tables serve only as temporary holding areas for the linguistic output. You modify, augment, or truncate the output into a form best suited for your application.

See Also: For more information about generating linguistic output, see "Generating Linguistic Output" in Chapter 8.

### Theme Table

The theme results table stores one row for each theme generated by CTX_LING.REQUEST_THEMES. The value stored in the THEME column is either a theme phrase or a colon separated list of parent themes.

The table can be named anything, but must include the following columns with names and datatypes as specified:

Column Name | Type | Description
--- | --- | ---
CID | NUMBER | Policy ID.
PK | VARCHAR2(64) | Primary key (textkey) for the text table.
THEME | VARCHAR2(2000) | Theme phrase or hierarchical list of parent themes separated by colons (:).
WEIGHT | NUMBER | Weight of theme phrase, relative to other theme phrases for the document.

#### Composite Textkey Theme Tables

You can use CTX_LING.REQUEST_THEMES to generate themes for a document contained in a composite textkey table. When you do so, the schema of the resulting theme table is the same as for when you request a theme on a single column textkey table, except that the composite textkey result table has additional PK columns.

The number of textkey columns in the theme table match the number of textkey columns in the original text table. The textkey columns in the theme table are named PK1, PK2, PK3,..., PKN, where N is the number of textkeys in the original text table. N is always less than or equal to 16.

For example, if you request a theme on a text table that has four textkeys, the schema of the output table would be (CID, PK1, PK2, PK3, PK4, THEME, WEIGHT).

The resulting textkey columns in the theme table are populated in the same order as they were registered.

### Gist Table

The Gist result table stores one row for each Gist generated by CTX_LING.REQUEST_GIST.

The table can be named anything, but must include the following columns (with names and datatypes as specified):

Column Name | Type | Description
--- | --- | ---
CID | NUMBER | Policy ID.
PK | VARCHAR2(64) | Primary key (textkey) for the text table.
POV | VARCHAR2(80) | Document theme.
GIST | LONG | ASCII text of Gist or theme summary.

The value in the POV column for a theme summary is a string which identifies the theme in the document.

The value in the POV column for a Gist is the term GENERIC.

Note: GENERIC is the only value that is consistently in all-uppercase. For all other themes in the POV column, the case depends on how the themes were used in the document.

#### Composite Textkey Gist Tables

You can use CTX_LING.REQUEST_GIST to generate Gists for a document contained in a composite textkey table. When you do so, the schema of the resulting Gist table is the same as for when you request a Gist on a single column textkey table, except that the composite textkey result table has additional PK columns.

The number of textkey columns in the Gist table match the number of textkey columns in the original text table. The textkey columns in the Gist table are named PK1, PK2, PK3,..., PKN, where N is the number of textkeys in the original text table. N is always less than or equal to 16.

For example, if you request a Gist on a text table that has four textkeys, the schema of the resulting hitlist table is (CID, PK1, PK2, PK3, PK4, POV, GIST).

The resulting textkey columns in the Gist table are populated in the same order as they were registered.

Prev | Next
| Copyright © 1997 Oracle Corporation. All Rights Reserved. |
Library | Product | Contents | Index