Attribute portion based document retrieval system with system query language interface

Description Submit all comments and votes

FIELD OF THE INVENTION

The invention relates generally to retrieval of documents in a client-server environment, and more specifically to compatibility between an attribute based document display system and diverse query languages within remote document repositories.

BACKGROUND

Retrieval of documents from many incompatible repositories is a difficult problem. In the event that documents are searched in many servers on a network using a single FIND command, the possibility that the servers, and the repositories running on the servers, are incompatible has a high probability.

There is needed a system for searching, and retrieving, documents from a heterogenous collection of diverse servers. Even servers implemented on the same model of computer may have incompatible data base programs running on each server. And modern networks connect many computers made by different manufacturers, each running database software which is incompatible with the data base software running on the other servers.

There is needed a solution to the complex problem of retrieving documents from many mutually incompatible computers. The retrieval, ideally, operates efficiently and seamlessly for a large number of servers coupled to a large network.

SUMMARY

The invention has a local process running on a client module, and a remote process running within each document repository. Each remote process is designed for the particular model of computer used for the server. Also, each remote process executes the System Query Language (SQL) used by a particular database program running on the server. As a further example, a particular server may have several database programs implemented thereon, and each database program has a dedicated remote process, where the remote process is matched to the particular database program.

The local process on the user's workstation launches inquiries in a first format on the network. Each remote process which receives an inquiry translates the recieved inquiry into the System Query Language required by its server and its database program. When the database program returns a response to the System Query language inquiry, the remote process translates the response into the first format, and returns the response to the local process by transmitting a reply over the network.

A further improvement of the invention is that the data transfer of a document over a network is accomplished by transfer of attributes. Each document consists of one or more attributes, each attribute consisting of a name and a value. The documents stored in the repositories are stored in whatever format is required by the server and by the database program. The remote process receives documents from the local process over the network as attributes. The remote process then stores the documents to the database program using the format required by the database program.

In the event that the remote process receives an inquiry over the network from the local process on a user's workstation, the inquiry is in the form of requested attributes. The remote process converts the requested attributes into Query Language requests understood by the database program, and then translates the response from the database program into attributes. The remote process then transmits a response over the network to the local process as attribute value pairs.

The local process on the user's workstation may request a subset of the attributes making up an entire document. Only the requested attribute value pairs will be contained in the request launched on the network by the user's local process, and directed to the remote process. Accordingly, partial document retrieval operates efficiently and conveniently based on the document structure and retrieval mechanism where documents include one or more attributes.

These and other features and advantages of the present invention will become apparent from a reading of the detailed description in conjunction with the attached drawings in which like reference numerals refer to like elements in the several views.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a drawing of a strand;

FIG. 2 is a drawing of a strand that has been selected by a user;

FIG. 3 is a drawing of a pile and scroll tool with a strand;

FIG. 4 is a drawing of a tile strand of documents;

FIG. 5 is a drawing of a corkscrew strand of documents;

FIG. 6 is a drawing of an embodiment the system;

FIG. 7 is a drawing of a second embodiment of the system;

FIGS. 8A, 8B, and 8C are drawings showing a repository interface in different schematics;

FIG. 9 is a drawing of a find tool with an output strand having a knot;

FIG. 10 is a block diagram of the architecture of a document display system using strands;

FIG. 11 is a flow chart showing the steps of a method for scheduling using a blocked queue and an execution queue;

FIGS. 12A and 12B are diagrams showing two embodiments of the attribute format;

FIG. 13 is a diagram of showing a system having asynchronous remote repository access;

FIG. 14 is a diagram showing the steps of a find tool method for retrieving documents from repositories;

FIG. 15 is a diagram of an apparatus for sharing a document between two users;

FIG. 16 is a diagram of an apparatus for merging multiple documents based on their visual display attributes; and

FIG. 17 is a diagram of an apparatus for retrieving documents from repositories and having no busy curser.

DETAILED DESCRIPTION

Documents

A document is the primary object in the system. All data are contained in documents. A document contains some number of attributes, each attribute having a name and a value. The set of attributes for any given document is arbitrary, and no particular attributes are required of all documents.

A screen object is the visual representation of a document. It may be visible or hidden at any given time. Screen objects are generally rectangular.

A Unique Identifier, or UID, is a string of alphanumerics that uniquely identifies a document. A UID is necessary and sufficient to refer to a specific document.

Attribute/Value Pairs

An attribute is a piece of data stored in a document. Each attribute has an attribute name and an attribute value. An attribute name uniquely identifies an attribute value within a document.

The Script Interpreter

Script consists of a scripting language that can be executed to perform some action. It is stored in attribute values. Scripting language is a language used to specify commands to the system environment.

The script interpreters (architecturally there can be any number) interpret script which is stored in attributes of documents. Scripts can modify attributes of documents, perform basic mathematical and search operations, call other scripts, and do other basic operations such as insert or remove documents from strands. Most of the actions in the system are activated by calling scripts within documents.

Documents are the single abstraction structure in the script language. There is no persistent storage associated with the script environment other than attributes of documents. Most of the actions in the system (other than simple dragging of documents) are activated by calling scripts within documents. A document consists of attribute/value pairs; by referencing an attribute in an expression, the value is returned.

The value of any attribute, ephemeral or not, may be executable script. Script thus allows the power user to extend the functionality of the system. For example, a user may define the value of an attribute by writing his or her own script as the value of that attribute.

Whether an attribute is executable or not is typically established by convention. For example, for a given implementation, an architecturally defined set of messages may indicate that the attributes referenced by the messages are executable. Or, a button on the mouse may be architecturally defined to invoke and execute the script contained in an attribute of the document in which the curset is located when that button is clicked by the user. In addition, or as an alternative, an identifier process can be designed and used to determine whether the value of an attribute is script, and also what script interpreter is needed to interpret it. The identifier process does not test whether the script can be properly parsed, but upon determining that the value of an attribute is script, chooses which script interpreter to call to interpret the script. For example, the identifier process can select an interpreter for a dialect of the Lisp programming language by checking the first non-whitespace character to see if it is a left paren or single-quote. If the first non-whitespace character is a left paren of a single-quote, the identifier process selects the interpreter for the dialect of the Lisp programming language to interpret the script.

A goal in designing a particular script language is that the script language be easy to read. Users may not be computer scientists, but will nevertheless want to examine and modify scripts to a certain extent. Therefore the language must have few special characters, and generally use natural language words instead of symbols.

The script language should be uniformly structured, in that the only storage entity (object) in the language is a document consisting of attribute/value pairs. Values may be atomic, such as strings, numbers, dates, or images, or they may be pointers (UID's) to other documents. Global objects may be stored as attributes in a universal "global" document which is visible to all scripts.

Attributes are generally not typed, but values are generally typed. The types of values are used to determine what operations are permissible. A script is executed within a document by evaluating an attribute whose value is a script, and whose type is executable.

Inputs to the System

An example embodiment of the system includes an input device, for example a mouse, to obtain information from the user regarding selecting and moving documents within the display. It will be clear to one skilled in the art of user interfaces that devices other than a mouse, such as a light pen, a voice controlled display, or a touch sensitive screen, are potential alternatives to the mouse.

The locations of mouse events, for example the pressing and or releasing of a mouse button, are recorded as the UID of the document in which the cursor is located when the mouse event occurs. The x, y or z position of the cursor at the time the mouse event occurred is recorded. The results of user actions to select or deselect one or more documents are similarly recorded.

Scanning Documents

Any paper document can be entered into the system by scanning. When scanning a document into the system, a cover sheet should be used. Each cover sheet is encoded with the identification of the owner of the document. Such identification would, for example, consist of the unique user name defined within the system used to log-on or gain access to system.

In an example embodiment, when a document is scanned into the system, the scanned document is automatically placed in an IN BOX pile of the owner of the document. Each scanned document has an information sticker across its top displaying the name of the owner and the date it was scanned. The cover sheet is not included.

Scanned documents without cover sheets, or that have cover sheets that do not name valid users, cannot be delivered to the true owner of the document by the system. The system may be configured to deliver such scanned documents to a designated user, who is responsible for determining the owner of the scanned documents.

The Visual Presentation: The Workspace

A workspace is a virtual three dimensional space in which a set of documents are arranged. In this way a workspace contains a set of documents. Within a workspace, there is a list of the documents contained within the workspace, consisting of combinations of repository identifiers (RIDs) and unique identifiers (UIDs). Also, for each document within the workspace there exist ephemeral attributes, which describe the current visual display of that document within the workspace. Examples of ephemeral attributes include the X, Y, and Z positions of the document within the workspace.

A workspace is stored in a workspace document and displayed in a workspace window. A workspace document is a document that contains all of the state information of a workspace. A workspace document may be contained within other workspaces.

The display of a workspace on the display device is the "screen space" representation of the three dimensional workspace on the two dimensional display device. In an embodiment of the system, the screen space display of a workspace is implemented through a window in the host computer's windowing system, within which the two dimensional screen space rendering of the three dimensional workspace is displayed.

The system uses a three dimensional workspace to provide a useful display of potentially thousands of documents. A workspace may display thousands of documents. In a preferred embodiment of a workspace, the workspace is wrapped at the edges, giving a fish-eye lens effect, so that every screen object that is not invisible has at least some portion of its rectangle within the screen display no matter what its position in the three dimensional workspace.

Workspaces may be shared, such that multiple users have the same workspace open. For example, user one and user two could simultaneously have the same workspace open. In one embodiment, when user one drags a document within the workspace, user two sees it moving as well. The ephemeral attributes defining the visual representation of the documents within the workspace can be mediated via repository connections from user one to user two to support this feature. For example, both user one and user two could simultaneously read and write to a shared copy of the workspace document within a mutually accessible repository. Alternatively, user one and user two could maintain separate copies of the workspace document in their respective client modules, establish a direct network connection between them, and exchange ephemeral attribute updates via the direct network connection.

The Renderer Process

A renderer process is an element of the system that maintains the virtual three dimensional workspace. The renderer process is performed by various specific renderers.

A document renderer is that portion of the system that draws inside the rectangle of the screen object associated with each document in a workspace. The system supports multiple renderers, and which renderer is used for a particular document is determined by an attribute of that document.

A workspace viewer is a process in the system responsible for outlining the screen objects of documents within the workspace and managing the display of selection indication. The interior of each screen object is rendered by its associated renderer, and the workspace viewer completes the view. The workspace viewer is also that part of the system which is responsible for maintaining the view of a workspace. That is, the workspace viewer contains the means for arranging documents in three-space.

Ephemeral Attributes

Ephemeral attributes are attributes associated with a document in the context of a workspace. Ephemeral attributes are stored within a workspace document of the workspace containing the screen object of the specific document which the ephemeral attributes are associated with. Ephemeral attributes define the display characteristics of the associated document, such as position and size. Ephemeral attributes reflect the actions of the user in manipulating the screen object of a document within a workspace, typically through using an interface device such as a mouse.

Ephemeral attributes are stored in workspace documents, which in turn are stored in repositories. All the state of the last image of a workspace, including ephemeral attributes associated with each document in the display, is stored in the permanent attributes of a workspace document when that document is stored into a repository. Thus a document may have different ephemeral attributes and values when that document is associated with different workspaces.

An ephemeral document is a document that has existence only in a workspace. It has no permanent attributes, only ephemeral ones. In an alternative embodiment, ephemeral documents may be stored in a virtual "workspace repository", accessible only from its workspace, and may have permanent attributes in this context. In such an alternative embodiment, the state of the workspace repository is stored as an attribute of the workspace document.

An intrinsic ephemeral attribute, or intrinsic attribute, is a special ephemeral attribute that every document must have, which directly effects the display of the screen object. Examples include x position (xpos), y position (ypos) and z position (zpos). Many intrinsic attributes are available for direct manipulation through the user interface device.

The Perspective Function

A perspective function maps objects on the screen by taking the three dimensional workspace coordinates, or "world space coordinates", maintained by the workspace viewer, and mapping them into two-dimensional screen space positions.

For example, every document has a position in world space defined along the x, y, and z axis, and every document has a width and a height. When an image of the document is drawn on the display device, the perspective function takes those world space coordinates and size variables as input parameters, and determines the actual size and location on the display device, in "screen space coordinates", where the document is actually going to be drawn. The perspective function is instantiated by the workspace viewer process.

Dragging Along the X, Y or Z Axis

To move a document around a workspace, there are three basic actions: dragging around, pushing back/pulling forward, and clipping. Dragging a document is the act of moving the corresponding screen object for that document with respect to one or more of the x, y, and z axis of the workspace by manipulation of the user interface device.

To move a document within the workspace, the user uses the user interface device to place the mouse cursor near the center of screen object of the document. The user next presses and holds the mouse button while moving the mouse. As a result, the screen object disappears and is replaced by an outline of its shape (called a drag box). As the mouse is moved, the drag box follows. This is known as dragging. When the mouse button is released, the screen object reappears in its new position.

Documents are pushed back and pulled forward via a modified drag action, e.g. using a separate mouse button, or by first moving the mouse cursor close to a corner of the screen object of the document, and then pressing and holding a mouse button. As an alternative a track ball device may be used to manipulate the position of the mouse curser. As the mouse cursor is moved toward the bottom of the screen, the screen object is dragged forward (towards the user) within the workspace. As the mouse cursor is moved toward the upper left corner of the screen instead of forward, the screen object is pushed back within the workspace. Note that as the screen object on the display device is being moved, the virtual location of the corresponding document maintained in the world space of the workspace viewer is being changed accordingly. Thus one can either say that the screen object is being moved, or that the document is being moved, and have the same meaning.

As a document is pulled forward, the document is moved towards the user along the z axis of the three dimensional workspace. The perspective process translates this movement of the object towards the user into a screen representation of the screen object for the document. As a result, the screen object for the document grows in size in its two dimensional screen space representation. Conversely, when a document is pushed back, the screen object for the document is made smaller.

A document can only be moved forward a certain distance. When it is as big as it will get, it is plastered against the workspace window and cannot be moved any closer.

The world space size of a screen object is the size of the screen object in the three dimensional space of the workspace. This is the object's real size opposed to the screen space size at which it appears on the screen display surface. Documents and elements of documents (e.g. buttons, text fields, etc.) all have world space sizes. Although dragging along the Z axis can make the world space size of documents very small, they will never be rendered at a size that is invisible to the user.

In the case of "corner dragging" in the Z dimension, any of the four corners of a document may be used to push or pull it. However, the document will move along somewhat different paths depending on which corner is used.

Repositories

A repository is a data store that contains documents. A workspace is generally used for short term storage of documents. For long-term storage, documents are kept in repositories. When a system tool brings documents into a workspace, it gets them from repositories. A Repository Identifier, or RID, is a string of alphanumerics that uniquely identifies a repository. RIDs are unique on the network. An RID is necessary and sufficient to refer to a repository. In an alternative embodiment RIDs are universally unique, and therefore permanently stable in a global environment where mobile computing is increasing significant. For purposes of example, such universally unique RIDs may be assigned through a central RID allocation system, similar to how 48 bit Ethernet physical layer addresses are centrally assigned to specific network controllers, to guarantee that there are no duplicates.

The computer network that the system is connected to may have one repository available or it may have many. Some repositories are generic places to put documents, while others may be specialized. For example, a machine that sends and receives documents as faxes over telephone lines can be a repository. The user may choose to maintain a private repository on the local computer. Most repositories are on remote machines and the system gets documents from them over the network. A repository may exist on the local file system. An embodiment of the system may run on a system with no disks. In that case, all repositories exist within remote network nodes.

The user may retrieve documents from many different repositories at the same time. Similarly, multiple users can connect to the same repository at once. A user of a document may put a document into a shared repository marked to the attention of other specified users. Each user may configure a special FIND tool (which serves as their IN BOX) that constantly watches the repositories for documents marked for their attention and brings them into their workspace. In this way, documents may be shared between users.

Repositories are visually represented in a workspace by a document called a repository portal. The user accesses a repository through the repository portal for that repository. A repository may be password protected, such that the user may have to enter a password into the portal document before using the repository.

Repositories may have special characteristics (unusual connection requirements, limited hours of availability, etc.) These are represented to the user on the portal document. Repository portals also have a visual indication of whether their repositories are currently available for use.

A repository server is a server that serves documents from a repository to a client and provides a search engine, and repository interface to process search requests described by attribute value pairs from the client system, and to search the repository using the search protocol specific to that repository.

Strands

Strands are a system for positioning screen objects in a three-dimensional workspace. Strands allow grouping of documents, so that they can be manipulated as groups. Strands are a method of applying constraints to the organization of screen objects in three dimensions.

A strand is associated with a first document (the "strand parent"), and constrains the location of a set of documents not containing the strand parent. A strand is a process that maps a (possibly discontinuous) line into 3 space. Each strand child has a position on the strand relative to the strand origin. A strand also has minimum and maximum constraints for the spacing of its children.

Strands are not containers, but rather are a mechanism for arranging screen objects without hiding them. A strand constrains the position of screen objects attached to the strand into a certain shape. The certain shape is indicated by a strand function. When the strand function is evaluated, its output defines a strand path. A pile is an example of a strand where all the documents attached to a strand are constrained to be next to each other in the shape of a pile.

The strand path is mathematically defined as a one-dimensional path through three dimensions, along which are displayed the screen objects of the child documents of the strand. Objects attached to a strand path appear to be indirectly connected, as do pearls on a strand of string. The strand function can be arbitrarily set so that it is oriented in any direction or is any complex line. It can be a complicated function like a bunch of line segments joined together, or it could be U-shaped or zigzag-shaped.

A pile of documents is a strand having a strand path defined by a function causing the strand to be oriented substantially parallel to the Z access of the display, that is, going straight back from the surface of the display device that is closest to the user. A "tile" of documents is a set of documents placed next to each other so that the complete contents of their current screen objects are showing. A tile is defined as a strand having a strand path substantially parallel to the glass of the screen. The strand mechanism itself is completely general. The user may define a corkscrew strand path to have documents spiraling back into infinity if so desired.

An example of a system tool having a strand is as follows. The FIND operation may be a tool having a pile for its output. The FIND command locates documents, and puts them into a pile below itself. The output pile is attached to the FIND tool. When the FIND tool is moved, the pile follows. The FIND tool will "let go" of a document if the document is clicked and dragged away from the pile.

A strand parent is a document to which a strand is attached. The strand path for that strand is defined relative to an origin point defined with respect to the strand parent. For example, the strand path could be relative to an origin in the upper left corner of the screen object for the strand parent. Minimum and maximum separation constraints, associated with the strand parent, define the spacing between any two child documents on the strand to be greater than the separation minimum and less than the separation maximum. The minimum and maximum separation constraints may for example be stored in the strand parent.

FIG. 1 shows a display device 10, including an example of a strand 15. The strand 15 is shown having child document screen objects 19a, 19b . . . 19e, and parent document screen object 17. The strand path is shown by line 20, and the mouse curser is shown by element 21. The separation of the child document screen objects 19 is shown at 24.

During operation of the system, with reference to the elements in FIG. 1, the strand path 20 is calculated by evaluating a strand function associated with strand parent represented by screen object 17. The exact orientation of the strand path 20 is determined with reference to an origin constraint associated with the strand parent screen object 17, for example, the upper left hand corner of the strand parent screen object 17 at point 26. The outputs of this evaluation are three dimensional coordinates that define the strand path 20 in the virtual representation maintained by the workspace viewer.

The child documents of the strand (corresponding to screen objects 19) are determined from a list of unique identifiers of the child documents associated with a strand parent document corresponding to screen object 17. The separation constraints associated with the strand parent document, indicating the minimum and maximum separation of child documents displayed along the strand path 20, are also evaluated. The output of these evaluations provides three dimensional coordinates defining the appearance and location of the child document screen objects 19 along the strand path 20.

The three dimensional coordinates are passed to a perspective process for translation into two dimensional screen space coordinates. The two dimensional screen space coordinates are used to display screen objects 19, representing child documents along the strand path 20, on the display device 10. The strand path 20 itself is not typically, but may be displayed on the display device. The separation 24 between the child documents cannot exceed the maximum separation constraint, and is not less than the minimum separation constraint associated with the strand parent document corresponding to screen object 17.

Strand parents may further include a knot constraint, defining points in the strand that divide the strand into sub-strands. Knot constraints may be arbitrarily defined, and are generally invisible to the user. For example, knot constraints may be used to subdivide the strand into two sub-parts so that the user has a pile of mail that has been read, and a pile of new mail, both within a single strand. Knots are used to keep those sub-s