WO2001004812A2 - Representation, management, filtering and systhesis of technical content - Google Patents
Representation, management, filtering and systhesis of technical content Download PDFInfo
- Publication number
- WO2001004812A2 WO2001004812A2 PCT/US2000/018422 US0018422W WO0104812A2 WO 2001004812 A2 WO2001004812 A2 WO 2001004812A2 US 0018422 W US0018422 W US 0018422W WO 0104812 A2 WO0104812 A2 WO 0104812A2
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- information
- objects
- child
- container
- attribute
- Prior art date
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F40/00—Handling natural language data
- G06F40/30—Semantic analysis
- G06F40/35—Discourse or dialogue representation
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F40/00—Handling natural language data
- G06F40/20—Natural language analysis
- G06F40/258—Heading extraction; Automatic titling; Numbering
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F40/00—Handling natural language data
- G06F40/20—Natural language analysis
- G06F40/279—Recognition of textual entities
- G06F40/289—Phrasal analysis, e.g. finite state techniques or chunking
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F40/00—Handling natural language data
- G06F40/40—Processing or translation of natural language
- G06F40/55—Rule-based translation
- G06F40/56—Natural language generation
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/08—Logistics, e.g. warehousing, loading or distribution; Inventory or stock management
- G06Q10/087—Inventory or stock management, e.g. order filling, procurement or balancing against orders
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/10—Office automation; Time management
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/912—Applications of a database
- Y10S707/917—Text
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/953—Organization of data
- Y10S707/955—Object-oriented
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/953—Organization of data
- Y10S707/962—Entity-attribute-value
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/964—Database arrangement
- Y10S707/966—Distributed
- Y10S707/967—Peer-to-peer
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99931—Database or file accessing
- Y10S707/99933—Query processing, i.e. searching
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99931—Database or file accessing
- Y10S707/99933—Query processing, i.e. searching
- Y10S707/99935—Query augmenting and refining, e.g. inexact access
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99941—Database schema or data structure
- Y10S707/99943—Generating database or data structure, e.g. via user interface
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99941—Database schema or data structure
- Y10S707/99944—Object-oriented database structure
Definitions
- the present invention relates to control of process and material specifications of the kind used by a manufacturing company. Background of the Invention
- an individual part or order can be defined by anywhere from one to fifteen or more different specifications covering issues such as the material properties, processing methods, test acceptance limits, etc.
- Each specification can cross-reference several additional specifications.
- Specifications are basically presentations of instructions including numeric data, text and graphics serving the purpose of supporting and justifying the quantitative information. While there are multiple standards for the exchange of graphical data and purchasing data (e.g., IGES for part drawing information and EDI for purchase order and other business information), there is as yet no similar defined format for the content of specifications.
- an author of a specification can include requirements in any form. The values can appear in a textual paragraph, a graphical table, or multiple locations within the document. As a result, determining the various requirements contained in a product's specifications requires personnel to wade through different formats and approaches to content.
- Another method involves reading and manually extracting quantitative values from the specification and storing these values in a simple database management system.
- a typical specification is a dynamic document than cannot be forced into a fixed tabular structure of a relational database.
- specifications have an irregular structure with many requirements depending upon a variety of conditions, such as the dimensions of the product, the type of material, intended application, etc.
- the various quantitative values can be described in different ways. That is, in some cases a value such as a tolerance may be provided as a range of values, in other cases it may be described as a formula which depends upon a condition.
- the present invention provides an object-based, semantic representation for documents as information containers, using a controlled taxonomy, and methods for extracting meaning from such information containers to provide high-level, automated document interpretation.
- These functions include the automated filtering of an information container in accordance with the controlled taxonomy and a set of conditions, to produce a result having only those information objects that are applicable under the specified set of conditions.
- These functions further include automated combination of information objects which comprise the information containers, to build a composite information container that reflects combined meaning of the associated documents, and automated handling of references from one information container to another.
- the invention features a process of assimilating a plurality of information containers each dealing with attributes of a physical thing, system or methodology, to generate a peer information container.
- the information containers each comprise a plurality of information objects, each identifying an attribute and a value, value range or description of the attribute, using potentially different structures. These objects are parsed, and pairs of objects identifying common attributes are identified. These pairs of objects are then combined, even if they have different structures, by combining the values, value ranges and/or descriptions of the common attribute, to produce new information objects representing the combination of the original pair.
- the new peer information container is constructed of one or more combined objects and/or objects from the input containers that could not be combined. In the disclosed embodiment of this aspect of the invention, the new peer information container uses the same format as the input containers, and is utilized in generation of additional new information containers by the same process of assimilation.
- the invention features a method of filtering an information container identifying attributes of a physical thing, system or methodology.
- the input information container comprises a plurality of information objects, some of which identify an attribute and a value, value range or description of the attribute.
- other objects identify an applicability condition for objects.
- the filtering process involves evaluating the applicability condition to determine applicability of one or more information objects of the information container, and filtering out information objects evaluated to be inapplicable, so that a peer information container can be generated that comprises only information objects determined to be applicable.
- the invention features a method of evaluating a first information container identifying attributes of a physical thing, system or methodology, that includes a reference to a second information container identifying further attributes of a physical thing, system or methodology.
- a peer information container is generated from the first and second information containers by obtaining information objects of the second information container as well as information objects from the first information container, and including the information objects from the first and second information container in the peer information container.
- the objects in the first information container include context objects associated with the reference, to provide a context for the reference, used when determining which information objects of the second information container have been referenced.
- the invention features a method of storing a semantic representation of a document identifying attributes of a physical thing, system or methodology, using a controlled taxonomy.
- the semantic representation includes a plurality of information objects, at least some objects identifying an attribute and a value, value range or description for the attribute, and other objects providing a context for the attributes that are identified by objects.
- the value defined by an object may be a numeric value or a predefined text value.
- Objects may define a range, in which case additional objects are used as endpoint objects defining endpoints of the range.
- an applicability condition there are further objects that define an applicability condition, so that a value, value range or description identified by an object can be made conditional based on the success or failure of the applicability condition.
- the object representing the group has a child logic property indicating a logical relationship between the conditions that must be met for the applicability condition to be met.
- the objects include properties characterizing the object and/or an attribute represented by the object, and each object is a member of an object class, objects in a common class having common properties.
- the objects are arranged in an hierarchy, in which there are parent objects and child objects; properties of a parent object include pointers to the child objects.
- the assimilation procedure includes determining whether two or more of child objects identify a common attribute, and if so, combining values, value ranges and/or descriptions of the common attribute identified by the child objects, to produce a new information object for the attribute identified by the child object.
- the parent objects have a child logic property indicating a logical relationship between their child objects; the child logic is taken into account when assimilating two information containers by determining an appropriate combination, if any, of the child objects that is consistent with the child logic property.
- some of the objects may be meaning objects, which define meanings for other objects. In this embodiment, only objects with compatible meanings are combined.
- Fig. 1 is a block diagram of a computer system for carrying out the invention
- Fig. 2 is a data structure diagram illustrating an object structure used in accordance with the invention
- Fig. 3 is a data structure diagram illustrating a exemplary partial tree of objects capturing the meaning of a portion of a technical specification
- Fig. 4A is a data structure diagram illustrating an order object comprising criteria, specifications, procedure definitions for a product definition (as described in a customer's order)
- Fig. 4B is a data structure diagram illustrating the result of retrieval of an order having the form shown in Fig. 4A;
- Fig. 5 is a data structure diagram illustrating the use of references in specifications at the revision, procedure and characteristic level
- Fig. 6A is a flow chart of the entry point of a tail-recursive procedure for retrieving an object
- Fig. 6B is a flow chart of the process for determining whether to retrieve an object
- Fig. 6C is a flow chart of the process for retrieving an object in accordance with a processing flag associated with the object
- Fig. 6D is a flow chart of the process for determining the processing flag for an object
- Figs. 7A, 7B, 7C, 7D, 7E, 7F, 7G, 7H, 71, 7J, 7K and 7L are flow charts of retrieval processing an object having a DO NOT PROCESS
- Fig. 8 is a flow chart of processing child objects
- Fig. 9A is a flow chart of a tail-recursive procedure for combining an object
- Fig. 9B is a flow chart of combining the children of an object
- Fig. 9C is a flow chart of combining two objects
- Fig. 9D is a flow chart of processing involved in combining two objects both having CHILD DEPENDENT child logic
- Fig. 9E is a flow chart of combining the structures of two objects having combinable meanings.
- computer system 20 for carrying out principles of the present invention comprises a first or client CPU 21 and a second or server CPU 38 connected for commumcation over a computer network.
- Client CPU 21 includes typical elements found in a computer system. These elements include a microprocessor 22 for manipulating data in response to stored programs. Programs and data are stored in a hard disk drive accessible to microprocessor 22 over a system bus 25. Also connected to system bus 25 is a memory 26 utilized for rapid access storage of data and programs being used by microprocessor 22. Information produced by microprocessor 22 is output via system bus 25 to a monitor 28. Monitor 28 is controlled to implement a graphical user interface for operator input and output of data, for example, the user interface provided by the Windows operating system available from Microsoft Corporation of Redmond, Washington. Data is received by microprocessor 22 via user input devices including keyboard 30 connected to system bus 25, and a mouse 32 connected to system bus 25.
- user input devices including keyboard 30 connected to system bus 25, and a mouse 32 connected to system bus 25.
- Keyboard 30 and mouse 32 are used in a conventional manner to interact with a graphical user interface on monitor 28 to enter information and control the operation of microprocessor 22.
- a printer 34 is connected to system bus 25, enabling printed output of information from microprocessor 22.
- Client CPU 21, as well as peer client CPU's 21a, 21b, 21c, etc., are connected via a network connection 36 to one or more server CPU's such as CPU 38.
- Client CPU's 21 and the one or more server CPU's interact in a conventional client server manner, utilizing one of a variety of network protocols such as Ethernet, Token Ring or other LAN protocols or a WAN protocol.
- Server CPU 38 stores data to be utilized by client CPU's 21 in a relatively large mass storage device such as a hard drive 40.
- Server CPU 38, or a second server CPU 38 retrieves data from hard drive 40 to be used by microprocessor 22 in a server CPU 22 in performing functions of the present invention.
- Additional client CPU's 21a, 21b, 21c, which are also connection to server CPU 38 have shared access to information stored in hard drive 40, thus permitting multiple computers to utilize the same shared information in carrying out principles of the present invention.
- Server CPU 38 is outfitted with conventional elements of a computer system, including hard drive 40, a system bus 41, a memory 42 connected to system bus 41, a microprocessor 43 connection to system bus 41, and other input and output devices as are conventional.
- a second server CPU may be used, the processing functions described below may be divided between the server CPU's.
- a first server CPU may be a standard query language (SQL) database server, for providing access to data
- a second server CPU may be a powerful processing CPU for processing accessed data by, for example, performing the retrieval and combining routines described below in response to requests from client CPU's and utilizing database services of the first server CPU.
- SQL standard query language
- the client CPU's may run programs which present a graphical user interface to the system for users.
- programs which present a graphical user interface to the system for users.
- a single server could be used to provide database services as well as retrieval and combining processing.
- a single CPU could provide database services, retrieval and combining processing, and a graphical user interface, without any use of a network.
- Each and all of these applications are within the scope contemplated for the invention.
- FIG. 2 details of the structure of the arrangement of the objects in the database stored in the computer system 20 of Fig. 1 can be provided. It will be appreciated that a variety of databases may be used to store objects in accordance with principles of the present invention.
- the database stored by computer system 20 is a relational database, which stores objects that are interrelated in an object based structure, particularly suited to describe technical specifications and information relating to manufactured products.
- the database manages five tables: class definitions, which store the definitions for object classes; class fields, which identifies the additional object properties for each class of object; class children, which identifies the allowable children for each class of objects; object instances, which stores instances of each object; and object field values, which stores the property values for each object.
- the last two tables are substantially larger than the first three, as they store the actual data for each object. Objects in this database fall into one of a variety of classes, as will be explored in further detail below with reference to Fig. 3 through Fig. 5.
- the object classes are defined such that the class of an object, in most or all instances, does not provide a meaning for the object, but rather the meaning for the object is obtained from another object; in such an approach, the object's class only defines its structure, allowing ready migration to other environments where similar structures may be used for different meanings.
- object classes may be defined and used, the generalized structure of an object based database and assimilation of technical information into a structure of objects, will remain the same.
- Fig. 2 illustrates the specific structure of objects utilized in accordance with the principles of the present invention.
- the illustration of Fig. 2 is generic to the object structure without regard to the type of information stored by the object, and therefore is applicable to any of the various applications described above and elsewhere throughout this specification.
- an object comprises a data structure 50 for storing core properties for the object.
- the data structure 50 that forms the core of an object is stored in the computer system 20 at an indexed location.
- data structure 50 is located by reference to a class identifier and object identifier for the specific object that is represented by data structure 50.
- the object identifier for an object is managed so as to be unique among all objects of the same class, although potentially not unique with respect to objects of other classes.
- Class identifiers uniquely identify a class of objects that are stored in the database.
- the core properties 50 for an object may be indexed, according to class identifier and object identifier, using the five tables described above, in a commercially available database program such as the Oracle Version 7.3 Database Engine available from Oracle Corporation.
- the object and class identifiers for an object can be used to generate a pointer to the object, such as pointer 52 illustrated in Fig. 2, such that the object can be manipulated.
- Fig. 2 illustrates the fields store the core properties 50 for an object. These fields include a field 54 for storing an object identifier, and a field 56 for storing pointer to a class definition. The object and class identifiers stored in these fields correspond to the object and class identifiers used to locate the object. The class identifier 56 also links the objects to a class definition (discussed below) which defines further properties of the object.
- the core properties 50 for the object further include fields used to link the object into a hierarchical tree-like structure formed of objects. These fields include a field 62 for storing a pointer to a parent object which is at the next level above the object in the hierarchical structure, and a field 64 for storing a pointer to a list of child objects which are on the next level below the object in the hierarchical structure.
- the pointer in field 64 leads to a doubly linked list of data structures 66a, 66b, etc. which identify children of the object.
- linked list structure permits object to have an unlimited number of children.
- Each data structure 66a, 66b includes a field 70a, 70b storing 'next' and 'previous' pointers used in navigating through the doubly linked list structure.
- the 'next' and 'previous' pointers in fields 70a, 70b point to the next and previous data structures 66 in the doubly linked list.
- the 'previous' pointer in the first data structure 66a in the list points to the core properties 50 for the parent object.
- the 'next' pointer in the last data structure 66 in the doubly linked list has a NIL value indicating that it is the last data structure in the list.
- Each data structure 66 also includes a field 72 for storing a pointer to a child object.
- the pointer to the child object is in the form of a class identifier and an object identifier which uniquely identify the child object, as discussed above.
- the pointers in field 72a, 72b lead to child objects 74a, 74b having the same structure as is illustrated in Fig. 2.
- the core properties 50 for an object also include a field 76 for storing a child logic parameter for the object.
- the child logic parameter is used whenever there is a relationship among the children of an object, to define the nature of that relationship.
- the child logic parameter can identify a logical relationship between the children that must exist for a condition represented by the object to be satisfied.
- the values that are used for the child logic parameter are:
- •AND- indicates that all conditions represented by child objects must be satisfied for the parent object condition to be satisfied.
- • GROUP- indicates that absence of any relationship between the conditions or information represented by child objects and the parent object.
- •SEQUENCE - indicates that every condition represented by child objects must be satisfied, in the order in which the child objects appear in the list identified by the pointer in field 66. If the conditions represented by the child objects are not satisfied in this order, then the condition represented by the parent object has not been satisfied.
- •IMPLICATION - indicates that an IF child object in the linked list identified by a pointer in field 66, represents a condition to be tested. If the condition of the IF child object is satisfied, then a THEN child object in the linked list represents the applicable child for the parent object. If the condition represented by the IF child is not satisfied, then an ELSE child of the parent object represents the applicable child for the parent object.
- •DEPENDENCY - indicates that a FOR child object in the linked list identified by the pointer in field 66, represents a condition to be tested. If the condition of the first child object is satisfied, then a USE child object in the linked list represents the applicable child for the parent object. If the condition represented by the first child is not satisfied, then an OTHERWISE child of the parent object represents the applicable child for the parent object. Implication differs from dependency in that objects having implication child logic are handled differently during retrieval, filtering and combining operations discussed below.
- EXCLUSIVE AND - indicates that all conditions represented by child objects must be satisfied for the parent object condition to be satisfied, and that no other conditions can be combined with the specified conditions.
- EQUALITY - indicates that all children are equal (may be used to define synonyms, e.g., in the thesaurus rules discussed below with reference to Fig. 260).
- CONFLICT - indicates that the children are in conflict.
- INCOMPLETE - indicates that there is an incomplete definition. Inserted during retrieval of objects to indicate insufficiently defined information, to block the combination of a set of objects that are incompletely defined.
- the core properties 50 for an object further include a pointer in a field 78 which, if used, identifies a linked list of additional properties of the object.
- Certain classes of objects require additional properties to be completely defined.
- the additional properties are stored in an array that is identified by the pointer in field 78.
- the array includes a sequence of fields 80a, 80b, etc. each of which provides information about a particular property of the object.
- Each field 80a, 80b stores an additional property for the object.
- the field may be used to store a data value of any kind, including a pointer to an object, a textual value, or a numeric value.
- Each field is divided into two subfields as seen at 84a, 84b or 86a, 86b.
- Subfields 84a, 84b store the value itself, while, for numeric value, the subfields 86a, 86b store a pointer to a unit of measure object 88a, 88b which provides an indication the unit of measure for the value stored that is stored in field 84a, 84b.
- an additional property field 80 includes a textual value or a pointer to an object as the additional property in subfield 84, there is no unit of measure identified by subfield 86.
- the core properties 50 for an object also include a field 90 for indicating an inte ⁇ retation or meaning for the object. Where used, field 90 provides information as to how the object is to be inte ⁇ reted. Typically, field 90 stores a pointer to an object 91 which provides a meaning for the object containing the pointer thereto. Details on the use of inte ⁇ retation and meaning objects will be provided below with reference to Fig. 3.
- an object operator of 'not equal' may be inte ⁇ reted as not equal ( ⁇ ), greater than (>) (e.g., if the object represents a minimum endpoint of a range), or less than ( ⁇ ) (e.g., if the object represents a maximum endpoint of a range).
- the object operator in field 92 indicates whether a condition represented by the object is satisfied when a condition the object defines is equal, or not equal, to a current condition being evaluated.
- the core properties 50 further include a field 95 for storing control information such as the name of the user that authored or edited the object, relevant dates of creation or revision, and the status of the object, e.g., ready for approval, approved, or verified through a second approval process.
- control information such as the name of the user that authored or edited the object, relevant dates of creation or revision, and the status of the object, e.g., ready for approval, approved, or verified through a second approval process.
- the core properties 50 also include a field 97 used for identifying a priority of the object. This is a numeric value indicating the relative priority of the object when it is to be combined with other objects. For example, an object in an order override tree can be entered with a highest priority value so that it overrides any other objects during the combine process described below.
- the core properties 50 can finally include a field 98 for security controls, which can be used to control access to and revision of the object.
- the class identifier in field 56 of the core properties 50 is indicative of additional properties of the object that are associated with the class of the object. These additional properties of the object can be obtained from the definition for the class which takes the form shown in Fig. 2. As seen in Fig. 2, each class has an associated definition 100, multiple such definitions being in existence, one for each class. Within each definition is specific information for objects within that class.
- each class definition includes a field 102 for storing an identifier for the class, which is used to locate that class and retrieve the additional information in the class definition 100.
- a class definition provides a list of allowable child class identifiers. The information in field 104 limits the classes of objects that may be made children of the object. This is useful to prevent creation of nonsensical hierarchal tree structures of objects.
- a field 106 in the class definition 100 stores a minimum and a maximum number of children that be attached to an object. Where multiple classes of children are allowed, field 106 will indicate a minimum and maximum number of children from each allowed class.
- a field 110 in a class definition 100 includes definitions of additional properties of objects in that class.
- objects in particular classes may have additional properties which are stored in an array identified by a pointer in field 78 in the core properties 50.
- the definitions for these additional properties are provided in the field 110 and the class definition, so that each property may be retrieved and its definition evaluated by combining the retrieved property with the definitions in field 110.
- the definitions for additional object properties in field 110 are provided by identifiers associated with each field 80 of the array of fields.
- a final property of an object that bears discussion is identified by the object's class definition 100, and stored in field 112. This property is known as the processing flag for the object.
- the processing flag for an object indicates the manner in which the object should be handled when the object is retrieved by the routines described in the following Figs.
- the processing flag identifies the relationship between the object and its child objects, and the manner in which the object should be handled during a retrieval and evaluation process discussed below. Particular values for the processing flag are: • CHILDREN ONLY - indicates that during retrieval of the object, the object should be eliminated and in its place, the children of the object should be retrieved. •REGULAR - indicates that the object and its children should be retrieved in a standard fashion as defined by the routines shown in the following Figs.
- •DOCUMENT PROCESSING - indicates that the object should be processed in the regular 35 manner when combining, but should be processed like a CHILDREN ONLY status during retrieval - permits retrieved results to identify a document from which requirements were obtained.
- This exemplary tree structure captures the meaning of a section of text from a material specification. Specifically, text represented by the partial tree structure of objects in Fig. 3 comes from an Aerospace Materials Specification
- Bars, wire, forgings and flash welded rings shall be solution heat treated by heating in a suitable atmosphere to 1750°F ⁇ 25 (954°C ⁇ 14), holding at heat for 1-2 hours, and quenching in agitated water and aged by heating to a temperature within the range 900 to 1150°F (482-621 °C), holding at the selected temperature within ⁇ 15°F ( ⁇ 8°C) for 4 to 8 hours, and cooling in air.
- Pyrometry shall be in accordance with AMS 2750.
- Fig. 3 illustrates the hierarchy of objects that represents the AMS 4965 specification, and in particular revision G of that specification, procedures in revision G related to heat treatment, and the layers of that procedure that are represented by paragraph 3.4 of the specification as quoted above.
- Appendix A to this application provides a complete textual description of the tree structure of objects representing the entirety of AMS specification 4965, including all revisions, all procedures, and all layers of those procedures found in the specification.
- each line represents a single object, and a tab indent is inserted beneath an object to identify the children of that object.
- the complete textual description of AMS 4965 spans 58 pages, representing several thousand objects.
- the complexity of the object structure apparent from Appendix A reflects the complexity of the AMS 4965 specification, and demonstrates the amount of information that is reflected in the small portions of text that comprise specifications.
- each object represented by a circle, is associated with an object class identifier, which is an integer number in a circle inside of the circle representing the object.
- object class identifiers can be used with cross-reference to the table in Appendix B, to confirm the class of each object shown in Fig. 3.
- Appendix B tabulates a substantially number of object classes than are illustrated in Fig. 3.
- the complete list of object classes in Appendix B includes all other classes that have been defined in accordance with the current embodiment of the invention, to capture information relating to technical specifications.
- Appendix B identifies, for each object class, its numeric (integer) identifier, a descriptor or name for the class, and the value of the processing flag associated with that class.
- An index included in Appendix B identifies the processing flag values that are numerically represented in the third column.
- Further information regarding object classes may be obtained by reference to Appendix C, which is a table of the names of additional fields utilized by objects in each class. Each class that utilizes additional fields, has one or more rows in Appendix C, each row representing one of the additional fields used by objects in the class. There may be one or multiple additional fields used by a particular class of objects, therefore there are one or more rows in Appendix C for each class.
- the left hand column identifies a class using its numeric class identifier.
- the second column provides a field identifier for each additional field.
- the third column provides a descriptive name for each additional field.
- the fourth column identifies the data type of each additional field. An index in Appendix C cross-references the numeric values in the fourth column to the data types of the values.
- Appendix D identifies an object class using the numeric identifiers discussed above with reference to Appendix B.
- the second column in Appendix D identifies classes of allowable children for the parent class, again using numeric class identifiers discussed above with reference to Appendix B.
- the third and fourth columns identify a minimum and maximum number of children for the allowed child class identified in the second column. Where the minimum and maximum numbers are both zero, this indicates that no minimum or maximum values are applicable.
- the highest level object in a representation of the AMS specification 4965 is a specification class object 120, having numeric object identifier 2.
- Company objects such as object 126 store information about an originating organization, and have a object identifier with a numeric value of 10.
- object 126 stores information about an originating organization, and have a object identifier with a numeric value of 10.
- object identifier with a numeric value of 10.
- Specification object 120 has a number of children, each of which represents a revision to the AMS 4965 specification. These children are identified by data structure 66-120, which are in a doubly linked list associated with specification object 120. For the pu ⁇ ose of the present exemplary discussion, only the object representing the revision "G" is illustrated. This revision is represented by a revision class object 138, which is associated with a numeric class identifier 11. Among the properties associated with object 138 are the revision name, stored in special field 140 and having the value "G", and the revision date, stored in special field 142, and having, for this example, the date May 1996.
- the children of revision object 138 represent procedures for testing or manufacturing products in accordance with the AMS 4965, revision G specification. Each procedure relates to a specific type of testing or product manufacturing step. These procedures are identified by objects which are children of revision object 138. These children are identified by a linked list of data structures 66-138 associated with revision object 138. For the purposes of the present example, only one object 144 representing a procedure is shown. Object 144 is a procedure class object having a numeric class identifier of 16. Among the properties of procedure object 144 is a reference property, stored in field 146, for referencing a definition of the procedure represented by object 144. Specifically, field 146 stores a pointer to a procedure definition object 148 which defines the procedure represented by object 144.
- Procedure definition object 144 is a member of the procedure definition class, having numeric object identifier 33.
- Properties of procedure definition 148 provide the specific information on the manufacturing procedure. These properties include a procedure name property stored in field 150, and in the present situation having the value "Heat Treat (Mill)" — indicating that the procedure relates to heat treatment for milled products.
- An additional property stored in field 152 provides a description for the procedure, and further fields store properties related to the role of the procedure, its cost, its type, and other information useful in understanding the procedure.
- Procedure object 144 represents all heat treatment procedures referenced or described by the AMS 4965 specification. Procedure object 144 therefore has a number of children each related to particular heat treatment procedures that are or may be applicable to particular circumstances.
- One such layer of the heat treatment procedure is represented by layer object 154.
- Object 154 is a member of the layer class of objects having numeric class identifier 17.
- Layer object 154 has a number of children, each representing a part of the if-then statement that the layer represents. Because layer object 154 has IMPLICATION child logic as seen in field 76-154, its children have a particular logical relationship.
- one child of layer object 154 which is a collection object 160
- collection object 160 can be understood to represent the implication in paragraph 3.4 that the procedures for heat treatment described in that paragraph relate only to bars, wire, forging, and flash welded rings. This implication can be drawn from the initial part of paragraph 3.4 which indicates that these forms of product are to be heat treated in the described manner.
- Layer object 154 which represents the entirety of paragraph 3.4 of AMS 4965, revision G, thus includes an implied condition that the heat treatment requirements stated in paragraph 3.4 are only applicable if the product to be manufactured is a bar, wire, forging, or flash welded ring.
- Collection object 160 is a collection class object having class identifier 0.
- the important parameter of collection object 160 is its child logic parameter 76-160 which has a value of OR. This indicates that if any one of the conditions represented by the children of collection object 1 0 is met, then the condition represented by collection object 160 has been met.
- Collection object 160 represents the complete condition of the first clause of paragraph 3.4 of AMS 4965, revision G, i.e., the state that paragraph 3.4 is applicable to bars, wire, forging, or flash welded rings. The children of collection object 160 each represent one of these four product types.
- collection object 160 has four children: a first child representing the product type "bar”, a second child representing the product type "wire”, a third child representing the product type “forging”, and a fourth child representing the product type "flash welded ring". For the pu ⁇ oses of example, only the first of these children is illustrated in Fig. 3.
- the first child of collection object 160 is an object 162, which is a member of the predefined value class having numeric class identifier 43.
- Predefined value class object 162 is being used to describe a condition, by referencing a value selected from a pre-defined list of possible values. Predefined value objects are used, wherever possible, when textual names or symbols must be compared to determine whether a condition has been met.
- predefined values greatly facilitates the use and comparison of specification, by reducing the individuality of textual descriptions of objects. Predefined values also aid in establishing rules for relating textual descriptions, by permitting the controlled use of synonyms.
- the important properties of predefined value object 162 are the inte ⁇ retation and meaning property stored in field 90-162, and the controlled term additional property stored in field 164.
- the inte ⁇ retation property stored in field 90- 162 contains a pointer to a characteristic definition object 166 which defines the characteristic that is to be compared to the predefined value represented by object 162.
- the characteristic definition object 166 is a member of the characteristic definition class having numeric class identifier 32.
- characteristic definition object 166 provides predefined value object 162 with an inte ⁇ retation; specifically, predefined value object 162 is inte ⁇ reted as a product type.
- the children of characteristic definition object 166 identify specific possible values for the product type that is defined by object 166. Accordingly, the children of object 166 include a plurality of controlled term objects.
- Each controlled term object 170A, 170B, 170C represents a specific defined controlled term for the product type characteristic that is defined by object 166. Controlled term objects may represent broad and narrow controlled terms, and for such a pu ⁇ ose can be arranged in their own object heirarchy.
- the broad controlled term “forging” may be the parent of a narrower controlled term “die forging”.
- Each control object has a numeric class identifier of 50.
- the important property of a controlled term object is the controlled term itself, stored in a field 172 A, 172B, 172C. As can be seen in
- the collection of controlled term objects 170A, 170B, 170C establishes a set of available controlled terms for the product type, mainly "bar”, “wire”, “flash welded ring”, and so on.
- Predefined value object 162 sets a condition on the product type, by identifying a particular one of the controlled term object children of characteristic definition object 164.
- the controlled term property of predefined value object 162 is a pointer stored in field 164, leading to controlled term object 170A which represents the controlled term value "bar".
- predefined value object 162 represents the condition that the product type must be equal to "bar”. This is, thus, the first of the four possible product types for which paragraph 3.4 of AMS 4965, revision G is applicable.
- Other children of collection object 160 similarly represent other product types for which paragraph 3.4 is applicable. Collection object 160, through its OR child logic, represents that of any of the product types described by its children are equal to the current product type, then the remainder of the paragraph 3.4 in AMS 4965, revision G is applicable.
- collection object 178 An important property of collection object 178 is its child logic property in field 76-178 which has the value SEQUENCE. This indicates that each of the conditions set forth by the children of collection object 178 must be met in sequence in order to satisfy the requirements of the heat treatment paragraph 3.4 in AMS 4965, revision G. This is consistent with the text quoted above, which provides that there shall be solution heat treating at a particular temperature, maintenance of heat for a particular time, followed by quenching in a particular manner, and aging, followed by holding at a new temperature, heating to a new temperature and holding at a new temperature, and then cooling.
- the sequence child logic property, stored in field 76-178 thus represents that the processing steps described by paragraph 3.4 of AMS 4965, revision G, must be carried out in order to satisfy the conditions of that document.
- the children of collection object 178 represent the sequential operations and conditions that are required by paragraph 3.4 of AMS 4965, revision G.
- the first child of collection object 178 is a collection object 180.
- This collection object 180 represents a heat treatment steps that is to be performed.
- the children of collection object 180 thus include a predefined value object 182 for describing the type of heat treatment to be applied, namely solution heat treatment, and a range object 184 (having class identifier 79) for identifying a temperature range for the heat treatment.
- a second collection object 186 which is a child of collection object 178, identifies a second heat treatment step as described in paragraph 3.4 of AMS 4965, revision G.
- this collection object 186 also includes a predefined value child object 188 for identifying the type of heat treatment to be performed and a range child object 190 for identifying the range of temperature to be achieved during the heat treatment.
- Range object 190 has children 202 and 204 which represent numeric values for endpoints of the range represented by object 190.
- Objects 202 and 204 are members of the numeric value class, having class identifier 45.
- Numeric value objects have two important properties, these properties illustrated with reference to object 204 in Fig. 3.
- the first important property is an additional property 205 which provides the numeric value represented by object 204, in this case the number "8".
- Field 205 further includes a subfield 206 for storing a pointer to a unit of measure object 207 representing the unit of measure of the object of the numeric value in field 205.
- a second important property of a numeric value object is the object operator in field 93-204 of the properties of the object. The object operator will have a value of equal or not equal, as discussed above.
- a numeric value is a part of range, such as that represented by range object 190
- the object operator is used to determine whether the end of the range is included or excluded from the range. Specifically, if the second child 204 of a range object 190 has an object operator of equal, as shown in Fig. 3, this indicates that the range of value is within the range if it is less than or equal to the numeric value in field 205 of object 204. Similarly, if the object operator of the first child 202 of range object 190 has an object operator of equal, this indicates that the numeric value is in the range if it is greater than or equal to the numeric value associated with child object 202. If an numeric value object representing the end of a numeric range has an object operator of not equal, this indicates that a value which is exactly at the endpoint of the range represented by the numeric value object, is not within the range.
- numeric values stored by numeric value objects 202 and 204 are associated with a pointer in a subfield 206 leading to a unit of measure object such as object 207.
- Unit of measure object 207 is a member of the unit of measure class of objects having numeric class identifier 38.
- An important property of a unit of measure object is the unit of measure represented by that object, which is an additional property of the object stored in field 208.
- the upper end of the range represented by object 190 is eight inches; therefore numeric value object 204 has the value "8" in its field 205, and unit of measure object 207 is associated with the unit of measure "inch”.
- a reference of this form is represented by a reference class object 192, which is also a child of collection object 178.
- the important properties of reference object 192 are its priority property in field 194, which indicates whether any requirements that overlap or conflict with requirements set forth in AMS 2750 should take precedence over the requirements in AMS 4965, revision G.
- Another important property of reference object 192 is its revision property stored in field 196, which identifies the name of the revision of the specification referenced by reference property 192.
- an order object 210 having a numeric class identifier 5 represents a request for manufactured products that conform to certain customer defined specifications.
- Important properties of an order object include an additional property in field 212 identifying the order by a textual name, an additional property in field 214 identifying the date on which the order was received, and an additional property in field 216 identifying the customer originating the order.
- the values stored in fields 212 and 214 are text and date values.
- the customer identifier in field 216 is a pointer to an object 218 of the company class, which identifies the company originating the order in the manner discussed above in reference to object 126 in Fig. 3.
- Order object 210 represents all the criteria and requirements specified by a customer in an order for a product. These criteria may include a number of specific values such as height, size, shape, weight, etc. of the manufactured product. These customer criteria are represented by a criteria object 220 having a numeric class identifier of 70.
- Criteria object 220 has a number of children, each identifying a criterion of the customer specifying the order. These children may be of any of a variety of classes, depending upon the information being represented by the criteria object 220.
- the child logic of the criteria object 220 is GROUP, indicating that all of the criteria beneath the criteria object must be met.
- a first child of criteria object 220 is a numeric value object 224, having numeric class identifier 45.
- Numeric value 224 can provide a numeric value for a defined variable such as the temperature or product measurements described with reference to objects 184 and 190 of Fig. 3.
- the inte ⁇ retation of the object is provided by the inte ⁇ retation/meaning pointer in the object, which leads to a meaning/inte ⁇ retation object.
- a second child of criteria object 220 is a predefined value object 226 having numeric class identifier 43.
- Predefined value object 226 can represent a customers request that product be produced in accordance with a procedure or in accordance with a particular method.
- predefined value object 226 may indicate a heat treatment type that the customer has requested.
- a third child of criteria object 220 is a reference object 228, having numeric class identifier 69.
- Reference object 228 can be used to provide specific criteria that relate only to a particular specification, revision, layer or other subportion of specifications requested by the customer.
- reference object 228 includes in its additional fields a pointer to a specification object 232 identifying one of the specifications indicated by the customer.
- the children of reference object 228 include a predefined value object 230, indicating a predefined value to be used when evaluating the specification that is represented by specification object 232.
- some specifications for alloys include grade designations for alloys to be made in accordance with those specifications.
- Grade designations are unique within individual specifications, but not unique from one specification to another. Accordingly, if a customer identifies a grade designation, the customer must also identify the specification under which that grade designation should be used. Once the customer has specified the grade designation and a specification in which it is to be used, a reference object 228 is created to identify the specification object 232 and the predefined value to be used with that specification object as represented by predefined value object 230.
- the children of criteria object 220 may further include higher level structures such as procedure object 234, which has a numeric class identifier 16.
- Procedure object 234 has a child predefined value object 236. This structure indicates that whenever a procedure is encountered in any of the specifications identified by the order, if the procedure is of the same type as procedure object 234, then the predefined value identified by the object 236 shall be used with that procedure to identify, e.g., which of several allowed approaches should be taken. This structure allows a customer to specify, for example, that heat treatment procedures shall be conducted at a particular temperature regardless of which specifications deals with heat treatment.
- the children of criteria object 220 may also include multiple layers of reference objects.
- reference object 238 is a child of criteria object 220.
- An additional field of reference object 238 points to reference object 240 and reference object 240 then may include additional children or point to additional reference objects.
- This structure may be used to specify criteria which are applicable when procedures are cross referenced through procedures identified by the customer. For example, with reference to the example of Fig. 3, the customer might specify that when a procedure defined in AMS2750 is performed as a consequence of the cross reference in AMS4965, revision G, to AMS2750, that a specific revision of AMS2750 shall be used. To accurately capture this structure, a reference object 238 is created which has an additional field pointing to the object 120 (Fig.
- a second reference object 240 is made a child of reference object 238, and reference object 240 includes in its additional fields a pointer to a specification object representing AMS2750.
- This tree structure of reference objects thus mirrors the structure through which procedures and referenced specifications are inco ⁇ orated into specifications that have been identified by the customer.
- criteria object 220 the children of order object 210 further include reference objects each of which references a specification specified by the customer.
- reference object 242 having a marked class identifying 69 may include a pointer to a specification that the customer has requested be followed in its entirety.
- reference object 244 is like reference object 242 in that it has an additional field pointing to a specification object
- references objects include a priority field 248 for storing a relative priority value, and a revision field 250 for storing an identifier of a revision from the referenced specifications.
- the revision field is typically used so that a specific revision of the specification will always be used in filling the order.
- a priority field is typically used to allow a mechanism to resolve conflicts between specifications identified by the customer.
- reference object 244 also includes child object 246, which is a procedure class object having numeric call identifier 16. The presence of procedure object 246 as a child of reference object 244 indicates that only those procedures and specification object 252 which are of the same kind as procedure object 246 shall be used in fulfilling the customers order.
- the children of order object 210 further include an order override object 253.
- Order override object 253 represents particular actions to be taken during handling of the order represented by object 210, which deviate from normal actions taken in accordance with the designated specifications.
- An order override object identifies a context for the override, for example, that a particular temperature or other value is to be used in a particular procedure.
- the children of order object 210 also include a procedure object 254.
- Procedure object 254 because it is a child of order object 210, represents a procedure that is to be followed in connection with the order due to an explicit request by the customer without reference to any specifications. Because of procedure object 254 is a direct child of order object 210, its parameters with override those which are included due to reference to specifications through reference objects such as 242 and 244.
- the children of order object 210 may also include a standard practice object.
- This object represents standard practices for the customer that have been previously requested, and are inco ⁇ orated into orders for a customer. Because the standard practice object is also a child of the order object 210, its parameters will override those which are included due to reference to specifications through reference objects such as 242 and 244.
- a final object illustrated in Fig. 4 A, which is an important component of an order, is an object 260 that establishes rules for the environment within which the order is inte ⁇ reted. These rules in effect form a thesaurus for predefined values utilized by the various criteria, specifications and procedures or layers in the order.
- a retrieval result includes a processing object 270 which represents the entire retrieval process applied to the customers order.
- the children of the processing object include a result object 272, a log object 274 and source object 276.
- the result object 272 is the desired end result of the retrieval process.
- the result object 272 is an expanded specification that can be used directly in the combine process described below to identify how a product is to be manufactured.
- the result object 272 has the same form as the original specifications that were referenced by the customer.
- the resulting object tree can itself be part of a subsequent specification by the same customer.
- the output of the retrieval process is a "virtual" specification, reflecting a collection of technical requirements, some originating from the customers references to others specifications, some originating from the customer's specific criteria, and some potentially originating from the manufacturing process of the supplier.
- the present invention substantially streamlines the process of specifying a manufactured product, while at the same time providing powerful handling of information at a level of sophistication that has heretofore been unknown.
- result object 272 is an expanded and pruned version of the original order object shown in Fig. 4 A, in order to have a trail through which the generation of the result object can be audited, two additional child objects are associated with processing object 270. These are the log object 272 and the source object 276.
- Log object 274 is used to audit the retrieval process that generated the result object 272.
- log object 274 includes objects corresponding to each object in the original order.
- Each object in the log tree that is headed by log object 274 is cross referenced to an object in the original order and includes fields identifying whether the corresponding objects in the order were included in the result object 272 or not, and the reasons why branches were not included in result object 272, including where applicable values which were compared, boolean values that were evaluated as part of processing implication statements, and other actions that were taken to generate the result object 272.
- Source object 276 provides a trace from objects appearing in result object 272 to the original part of the original document referenced by the order from which those objects originated.
- the structure of the tree beneath source object 276 is identical to the structure of the tree beneath result object 272.
- Each object in the tree beneath source object 276 identifies the specification or criteria or other object in the original order from which the corresponding object in the result tree originated.
- Source object 276 can thus be used to directly trace the reference object 272 to the source location that produced it.
- Log object 274 can be used to determine why particular source objects in the order were carried over to result object 272 or pruned during the retrieval process. Referring now to Fig. 5, for further background, the manner in which references are used, can be discussed. References are used in specifications, to inco ⁇ orate relevant information found in another specification. References can come in many types. For present pu ⁇ oses, three types of references are allowed: revision level references, procedure level references, and characteristic references.
- Fig. 5 illustrates, in simplified form, a specification represented by specification class object 277.
- This specification has a revision represented by revision object 278.
- This revision includes a reference to another specification, which for present pu ⁇ oses will be known by the number "123".
- This reference is represented by a reference object 279 which is a child of revision object 278.
- a second child of revision object 278 is a procedure object 280 for a procedure, which for present pu ⁇ oses will be called "A”.
- Procedure A includes a reference to specification 123, indicating that thicknesses for procedure A shall be as specified in specification 123.
- This reference is represented by a reference object 281, which has an inte ⁇ retation/meaning pointer to a CHARACTERISTIC DEFINITION class object 282 which defines the characteristic "Thickness”.
- Procedure A also includes a number of layers including layer “ 1 " (represented by layer object 283), and layer “2" (represented by layer object 284).
- Layer “2" includes a reference to another specification; this reference is represented by reference object 285.
- Procedure A also includes further references to specification 123 that are different in kind from reference object 281.
- procedure A includes a reference to a procedure named "B" in specification 123, which reference is represented by object 286. Furthermore, procedure A includes a reference to the procedure named "A" in specification 123, which reference is represented by object 287. Note that reference object 287 does not include an identification of which procedure in specification 123 is being referenced. As will be seen below, under these circumstances, it is assumed that the same procedure is being referenced. Furthermore, note that the scope of the reference to the procedure "B” is defined by another object, namely the reference object 286. Fig. 5 also illustrates, in simplified form, the referenced specification named "123".
- Procedure A has two layers, named Layer X and Layer Y, and represented by objects 291 and 292.
- Procedure B also has two layers, Layer A and Layer B, represented by objects 295 and 296.
- Layer A includes identifications of numeric values, including a value for thickness; thus, thus object 295 representing layer A has child objects 297 and 298 of the numeric value class.
- Numeric value object 297 has an inte ⁇ retation/meaning pointer identifying an CHARACTERISTIC DEFINITION object 294 defining "thickness".
- Fig. 5 includes lines connecting the reference objects 279, 281 ,
- a reference object establishes an inco ⁇ oration by reference of a subset of the referenced specification. The size of the subset and the manner in which it is identified, are based upon the placement and properties of the reference object.
- reference object 279 is known as a "revision level" reference, for the reason that it is positioned as a child of revision object 278 and has a null inte ⁇ retation/meaning pointer.
- a revision level reference causes inco ⁇ oration of all procedures from the referenced revision of the referenced specification. If a revision-level reference does not specify a particular revision of the referenced specification, the most recent revision is implied. Thus, assuming that the revision represented by revision object 289 is the revision identified by reference object 279, reference object 279 inco ⁇ orates by reference, all of procedures A and B from specification 123.
- Reference object 286 is known as a "procedure level" reference because it is located below a procedure object (object 280) and has a null inte ⁇ retation/meaning pointer.
- a procedure level reference inco ⁇ orates all layers from the identified procedure in the referenced specification.
- Reference object 286 identifies procedure B in specification "123"; accordingly, layer A and layer B (represented by objects 295 and 296) from procedure B in specification "123" are inco ⁇ orated by reference object 286.
- a procedure level reference object does not identify a particular procedure, as is the case with object 287, the reference object is assumed to refer to a procedure with the same name as the procedure that is the parent of the reference object.
- object 287 is taken to inco ⁇ orate all layers from a procedure with the name "A" in specification 123; thus, object 287 inco ⁇ orates layers 291 and 292 from procedure A of specification 123.
- Procedure level reference objects need not be positioned as an immediate child of a procedure object.
- reference object 285 is a procedure level reference because it is a descendant (child of a child) of procedure object 280.
- a third level of reference is characteristic level reference.
- Object 281 represents a characteristic level reference to specification 123.
- a characteristic level reference is created by including a reference object at any level of a specification, and including in the reference object an inte ⁇ retation/meaning pointer to a CHARACTERISTIC DEFINITION class object defining the characteristic that is cross-referenced.
- object 281 in Fig. 5 has an inte ⁇ retation/meaning pointer to an object 282 defining the characteristic "thickness”.
- Object 281 also identifies specification "123", and is a child of procedure object A.
- reference object 281 inco ⁇ orates all objects in procedure A of specification 123 that relate to the characteristic thickness — which includes numeric value object 297.
- the retrieval process is a tail recursive algorithm for scanning a tree of objects and creating appropriate entries in the log, result and source that become parts of the processing object 270 (retrieval result).
- a new object in the input order tree is handled and appropriate further actions are taken.
- the retrieval procedure calls the retrieval procedure itself as further objects in the input tree are processed, until ultimately, the end of a tree branch is reached.
- the end of a tree branch may be reached due to the arrival at the last object in the branch, or due to the failure of a condition that must be satisfied for further processing of the branch.
- step 300 a log object is created to reflect the retrieval of the object so that the log has complete record of all objects that have been retrieved.
- step 304 the retrieved object is evaluated to determine whether it is to be included in retrieval. This step involves a complex analysis of a number of governing factors, and is detailed in Fig. 6B, below. As a consequence of this evaluation, it is determined that the object is or is not included in retrieval.
- step 308 the log object that was created in step 302 is modified to reflect that processing terminated at the object due to the factors evaluated in step 304.
- step 310 the cmrent invocation of the retrieval process returns a "child fail" value to indicate that the current object was not retrieved.
- step 312 the retrieval procedure stops. If in step 304, it is determined that the cu ⁇ ent object is to be retrieved, then processing proceeds to step 314 in which the status of processing the object is evaluated to determine whether any system rules that relate to the object have been applied. The evaluation of system rules will be discussed below.
- system rules may be associated with any object, and may identify special processing to be performed under certain conditions, e.g., when the object is retrieved. Also, rules may generate additional objects to be processed. If the rules, if any, for the cu ⁇ ent object have not already been applied, then in step 316 the object's rules are applied. Thereafter, processing continues to step 318. If the current object's rules have already been applied then processing continues directly from step 314 to step 318. In step 318 the result of the application the rules is evaluated, to determine whether the rules permit continued processing of the current object. In some cases, the rules associated with an object may indicate that the object should be eliminated under set conditions. Only if such conditions are not met will processing continue to step 320.
- step 320 the result of evaluation of the rules is considered, to determine whether additional objects have been created through evaluation of the rules. If no additional objects have been created, then in step 322 the object is processed based on its processing flag in the manner shown below with respect to Fig. 6C.
- step 323 processing is performed in step 323 to determine whether top-level retrieval of the object initially passed to the retrieve routine has been completed. If so, further processing is performed as necessary to capture any assumptions of referenced specifications or procedures that are not reflected in it representation, and to include these into the result. For example, it may occur that a specification has a normal dependency or environment for output properties, which might not be captured by the retrieve routine. To capture such properties, the entire result tree is scanned for any characteristic definition object having an "output" role indication property. If there is such a characteristic definition, then the procedure where this characteristic definition is defined is scanned to determine whether, for that procedure, there is a normal dependency or environment for output properties. If so, then a dependency object is created in the retrieval result to reflect this normal environment or dependency. This operation will prevent a requirement from surviving its appropriate context as a result of the retrieval process.
- step 312 the retrieval of the object is completed. If in step 318, it is determined that the rules do not permit continued processing of the current object, then in step 324 the rules are evaluated to determine whether the rules generated additional objects that ought to be processed instead. If so, then in step 326, the current object and the additional objects are gathered together as a collection object, with the current object the first object in the collection. Then, in step 328, the retrieve procedure of Fig. 6A is reinvoked, with the new collection object as the object to be retrieved. This has the effect of inco ⁇ orating additional objects with the current object. It will be noted in the second invocation of the retrieve procedure of Fig.
- step 314 it will be determined that the rules for the current object have already been applied, and processing will continued directly to step 318 without re-application of the rules in step 316. If in step 320 it is determined that the rules generated one or more additional objects, then in step 330, the current object and the additional objects are again gathered together into a collection and a new collection object is created. Here again the current object is made the first object in the collection. After step 330, in step 328, the retrieve object procedure of Fig.
- step 6 A is called again to retrieve the newly created collection object, after which the additional processing of step 323 is performed, and the retrieval procedure stops in step 312.
- step 324 If in step 324 it is determined that the rules prevent continued processing of the current object and did not generate additional objects to be processed, then processing of the current object has failed, and in step 322 control is returned to the calling procedure with the return value of "fail".
- step 304 the manner of deciding whether to retrieve an object (step 304, Fig. 6A) can be elaborated.
- a first step 305 stored information is evaluated to determine whether retrieval of a parent object led to a conclusion that the current object should be retrieved. If so, then in step 313, processing ends with the conclusion that the cu ⁇ ent object should be retrieved.
- processing of an object can lead to a conclusion that the object and all of its children should be retrieved. Under these conditions, information is stored for later inspection at step 305, to simplify the process for retrieving the child objects.
- step 306 the current object is evaluated to determine whether it is a descendant of a reference object. That is, the current object is descended from a reference object if, in the chain of objects that are the parents, grandparents, etc. of the object, there is a reference object.
- a reference object may separate an object from the order including the reference. Specifically, an order may reference a specification, and that specification may reference a second specification, and the second specification may reference a third.
- One of the consequences of the retrieve process described herein is the inco ⁇ oration of all of the referenced specifications into the retrieved version of the order.
- a reference object typically references only a certain revision or a portion of a revision of the complete tree of objects defining the entire referenced specification. For example, as seen in Fig. 5, a reference object can reference only procedures of one revision of a specification, or only layers of one procedure, or only one characteristic of one procedure. In each case, other revisions, layers and characteristics should not be retrieved. Accordingly, if the current object is descended from a reference object, in step 307 the class of the current object is evaluated to determine whether the cunent object should be retrieved.
- step 309 If the cu ⁇ ent object is a task object (step 309), then in all cases the entire task, including the cu ⁇ ent object and its children, is included in the material referenced by the reference object, and should be retrieved. Accordingly, in this situation, processing proceeds to step 311, where a note is stored to indicate that all children of the current object should be retrieved, so that in subsequent processing of these child objects, in step 305 it will be immediately determined that the child object is to be retrieved. After step 311, processing proceeds to step 313, and the current object is retrieved.
- step 315 If the cu ⁇ ent object is a document object (step 315), then in all cases the current object should be retrieved. Therefore, processing proceeds directly to step 313. If the cu ⁇ ent object is a revision object (step 317), then the object should be retrieved if it is the revision that is identified by the cu ⁇ ent objects' reference object ancestor. Thus, in step 319, it is determined whether the ancestor reference object specifies a revision. If not, the most cu ⁇ ent revision should be used; thus, in this case, in step 321, the cu ⁇ ent object is evaluated to determine whether it represents the latest revision. If so, then processing continues to step 313 and the current object is retrieved; if not, then processing continues to step 325 and the cu ⁇ ent object is not retrieved.
- step 349 the current object is evaluated to determine whether it represents the specified revision. If so, then processing continues to step 313 and the cu ⁇ ent object is retrieved; otherwise, processing continues to step 325 and the current object is not retrieved.
- the object should be retrieved if it is the procedure that is identified by the current objects' reference object ancestor.
- the ancestor reference object specifies a reference scope by way of a reference scope object.
- a reference scope object defines a scope for a reference, e.g. by identifying procedures that are referenced.
- the cu ⁇ ent procedure object is evaluated to determine whether it satisfies the scope criterion. If so, then processing continues to step 311 , to cause the cu ⁇ ent object and all of its children to be retrieved. If the curcent object does not satisfy the scope criterion, processing continues to step 325, and the cu ⁇ ent object is not retrieved.
- step 329 the ancestor reference object does not have a scope criterion object, then a scope for the reference is assumed, based on the position of the ancestor reference object. Specifically, in this case, in step 333 the position of the ancestor reference object is evaluated. If the ancestor reference object is at the revision level (step 347), i.e., the ancestor reference object is the child of a revision object in the specification containing the ancestor reference object, then processing continues to step 311, and the current object and all of its children are retrieved.
- step 333 the ancestor reference object is at the procedure or characteristic level (step 337), then in step 339 the ancestor reference object is evaluated to determine whether the ancestor reference object identifies a procedure. If so, then in step 341 the cu ⁇ ent procedure object is evaluated to determine whether the ancestor reference object identifies the procedure of the current object. If not, then processing proceeds to step 325 and the current object is not retrieved. If, however, the ancestor reference object identifies the procedure of the current object, then in step 343 the ancestor reference object is evaluated to determine whether it is at the characteristic level, i.e., references a characteristic. If not, the ancestor reference object must reference the entire procedure represented by the cu ⁇ ent object, and therefore processing continues to step 311 and the cu ⁇ ent object and all of its children are retrieved.
- the characteristic level i.e., references a characteristic.
- step 343 If in step 343 it is determined that the reference object is at the characteristic level, then the cu ⁇ ent procedure object should be retrieved, and processing continues to step 313.
- step 341 If in step 341 it is determined that the current object is not in the identified procedure, then processing continues to step 325 and the cu ⁇ ent object is not retrieved. If in step 339 it is determined that the ancestor reference object does not identify a procedure, then the procedure being referenced is assumed from the location of the reference object. Specifically, in this situation, in step 345 the ancestor reference object is evaluated to determine whether it is a child of an object representing the same procedure as the current object. If so, then processing continues to step 343 to determine whether the reference object is a characteristic or procedure reference, and take appropriate action.
- step 345 If in step 345 it is determined that the procedure that contains the ancestor reference is different from the procedure that contains the current object, then the cu ⁇ ent object is not in the referenced procedure, so processing continues to step 325 and the cu ⁇ ent object is not retrieved.
- step 307 If in step 307, it is determined that the current object is none of the other types discussed above, then in step 351 the ancestor reference object is evaluated to determine its level; specifically, the ancestor reference is evaluated to determine whether it is a child of a revision or procedure object.
- step 215 processing continues directly to step 215, and the cu ⁇ ent object is retrieved.
- step 351 the ancestor reference object is at the characteristic level, then it cannot be assumed that the cu ⁇ ent object should be retrieved. Accordingly, in this case in step 353 the cu ⁇ ent object is evaluated to determine whether it is a characteristic object. If not, processing continues to step 313 and the cu ⁇ ent object is retrieved. If, however, the current object is a characteristic object, then in step 355 the current object is compared to the ancestor reference object to determine whether the current object relates to the same characteristic as is referenced by the reference object. If not, then processing continues to step 325 and the current object is not retrieved. If, however, the current object relates to the characteristic referenced by the reference object, then processing continues to step 311 and the cunent object and all of its child objects are retrieved.
- step 322 the processing flag for an object is generated in step 335, and the appropriate action is taken based upon the processing flag for the object. If the processing flag has a value of DO NOT PROCESS 336, then in step 338 appropriate DO NOT PROCESS processing is performed as shown in Fig. 7A. If the value of the processing flag is CHILDREN ONLY 340, then in step 342, CHILDREN ONLY processing is performed. If the value of the processing flag is REGULAR 344, then REGULAR processing 346 is performed as shown in Fig. 7C. If the value of the processing flag is CHILD DEPENDENT
- CHILD DEPENDENT processing 350 is performed as shown in Fig. 7D.
- the processing flag is INFORMATION ONLY 352, then INFORMATION ONLY processing 354 is performed as shown in Fig. 7E.
- the processing flag is REFERENCE 356, then REFERENCE processing 358 is preformed as shown in Fig. 7F.
- the processing flag of the object is FORMULA 360, then FORMULA processing 362 is performed as shown in Fig. 7D.
- the processing flag for the object is RULE 364, then RULE processing 366 is performed for the object in Fig. 7H.
- the processing flag for the object is ACTION 368, then ACTION processing 370 is performed for the object as shown in Fig. 71.
- DOCUMENT processing 374 is performed for the object as shown in Fig. 7J. If the processing flag for the object is
- PREPARATION 376 PREPARATION processing 378 is performed for the object as shown in Fig. 7K. If the processing flag for the object is UNKNOWN 380, then UNKNOWN processing 382 is performed for the object as shown in Fig. 7L.
- Fig. 6D an explanation can be made of the manner in which the processing flag for an object is determined in step 335 of Fig. 6C. Initially, in step 357, the cu ⁇ ent object is evaluated to determine whether it is the descendant of a reference object. If not, then in step 359, the current object is evaluated to determine whether its inte ⁇ retation/meaning pointer leads to a special "SDL DEFINITION" class object.
- step 363 the processing flag is obtained from this SDL DEFINITION class object.
- step 365 the processing flag that was retrieved is evaluated to determine whether it has a value of "UNKNOWN". If the processing flag has a value of "UNKNOWN”, then processing continues to step 369, and the processing flag stored in the class definition for the cu ⁇ ent object is used. If the processing flag is not "UNKNOWN" in step 365, then in step 367 the processing flag from the SDL DEFINITION object is used. If in step 361 , the cu ⁇ ent object does not have a meaning inte ⁇ retation pointer leading to an "SDL DEFINITION" object, then processing continues directly to step 369, and the processing flag stored in the class definition for the current object is used.
- step 357 it is determined that the current object is a descendant of a reference, different steps must be taken to determine the processing flag for the object. Specifically, in step 371, the level of the ancestor reference object is evaluated.
- step 371 If in step 371 the ancestor reference object is at the revision level (step 373), then the processing flag is returned as PROCESS CHILDREN ONLY. This prevents objects at a higher level than REVISION from being inco ⁇ orated into the result. If in step 371 the ancestor reference object is at the procedure level (step 377), then the cu ⁇ ent object is evaluated to determine whether the cunent object relates to the same procedure as the ancestor reference object. If so, then in step 375 the processing flag is returned as PROCESS CHILDREN ONLY. If the cunent object does not relate to the same procedure as the ancestor reference object, then in step 381, the processing flag is returned as CHILD DEPENDENT,
- DO NOT PROCESS processing 338 can be discussed. For objects that have DO NOT PROCESS processing flags, the object is not to be retrieved. Accordingly, for these objects, in step 390, a log object is created and added to the log tree, and then processing stops 392.
- CHILDREN ONLY processing 342 only the children of an object are processed and the object itself is omitted from the results. Accordingly, under these conditions in step 394 a log object is created and added to the log tree to reflect that the cunent object was eliminated due to its CHILDREN ONLY processing flag. Then in step 396, the children of the cu ⁇ ent object are retrieved below in greater detail in Fig. 8. Thereafter, processing of the object stops 398.
- step 400 a copy of the object is created, without its children, and the copy is added to the result tree.
- REGULAR processing an object is carried from the input tree structure of objects to the result tree.
- step 402 a source object co ⁇ esponding to the cu ⁇ ent object is created and added to the source tree.
- step 404 a log object is created and added to the log tree to indicate that the object was kept because of its REGULAR processing status. Processing then continues to step 396 as shown in Fig. 8, in which children of the cunent object are retrieved. After retrieval of the children of the cunent object, processing is done 406.
- CHILD DEPENDENT processing can be described.
- the inclusion of the object in the result tree is a function of whether any children of the object are to be included in the result tree. Accordingly, in step 408, a copy of the cunent object without its children is created, and is made a root of a temporary new result tree, which can be conditionally added to the retrieval results if it is shown that the there are children surviving the retrieval process. Then in step 410, a source object is created to conespond to the new result tree. Then in step 396, illustrated in
- the children of the cunent object are retrieved.
- the results of the retrieval of the children is evaluated.
- the result of retrieval of the children may be the addition of the child objects to the copy of the cunent object created in step 408. If, however, no children survive the retrieval process, then the copy created in step 408 will not have any children.
- step 408 if the root object created in step 408 does not have children after step 396, processing proceeds from step 412 to step 414 and step 416 in which the copy created in step 408 is deleted and the source object created in step 410 is deleted. Then in step 418, a log object is created reflecting that the cunent object was not retrieved because none of its children were retrieved. Then in step 420, a "child fail" return condition is delivered and in step 422, processing of the cunent object is done.
- step 412 If the result of retrieval of the children of the cunent object is the addition of child objects to the copy created in step 408, then processing proceeds from step 412 to step 424 and step 426 in which the result object created in step 408, and therefore its children as well, are copied to the result tree.
- step 428 the source object created in step 410 is moved to the source tree at the appropriate location.
- step 430 a log object is created and added to the log tree to indicate that the object was retrieved because at least one of its children survived the retrieval process. After this is done, processing of the cunent object stops in step 422.
- retrieval of child objects may change properties of the parent of those child objects. Accordingly, after the retrieval of the children in step 396 in Fig.
- the cunent object being evaluated in step 412 may no longer have a CHILD DEPENDENT flag. If this occurs, processing passes through step 432 directly to steps 426, 428 and 430 to add the result created in step 408 to the result tree and the source object created in step 410 to the source tree, and create a log object and add the log object to the log tree indicating that the processing flag of the cunent object changed and caused retrieval of the object.
- Objects having an INFORMATION ONLY processing flag exists only to convey information to users, and no to be retrieved from compilation and evaluation in light of other objects. Accordingly, INFORMATION ONLY processing in step 354 merely involves copying the cunent object and all its children to the result tree in step 434, creating a source object for those copied objects in step 436 and creating a log object in step 4389 indicating that the cu ⁇ ent object and its children were copied due to the INFORMATION ONLY processing identified by the processing flag of the object.
- step 358 REFERENCE processing in step 358 can be discussed.
- log object is created and added to the log tree indicating that REFERENCE processing was performed on the object.
- the following steps utilize a stack of reference information to track whether a cu ⁇ ent object is a member of a reference subtree, and to determine whether the reference subtree co ⁇ esponds to the cunent location of the value of other objects.
- step 446 because a new object is being processed, an entry is pushed onto the reference stack to reflect a new level of reference processing.
- step 448 the reference object pointer is evaluated to determine whether the object it references is valid. If the object it references is valid, then in step 450 the current processing priority is updated with the priority value in the objects special priority field. Then in step 452, retrieval of the reference object is initiated by invoking the retrieval procedure shown in Fig. 6A.
- step 448 If in step 448, it is determined that the object referenced by the cunent object is not valid, then in step 454 a log object is created indicating that processing was terminated due to an invalid reference, and this log object is added to the log tree. Then a "child fail" status is returned to the calling procedure in step 456. After either step 456 of step 452, processing of the cunent object is completed and therefore in step 458, an entry is popped from the cunent reference stack, reflecting the end of reference processing of a cunent object. Processing then stops in step 460.
- Formula processing involves evaluating a formula that is represented by an object.
- step 396 all of the children of the cunent object are evaluated to reduce them to numeric values if possible.
- step 462 it is determined whether all the children have been evaluated to numeric values. If not, then no further action can be taken on the formula and in step 464 the formula and its evaluated children are copied directly to the result tree. If, however, all of the children have been evaluated to the numeric values, then in step 466, the formula represented by the cunent object is evaluated, to produce a new numeric value.
- step 468 it is determined whether there are any criteria embedded in the formula.
- step 470 it is determined whether the evaluated formula meets these criteria. If the evaluated formula meets the criteria or if there are no criteria in the formula, then the evaluated result of the formula is moved to the retrieval tree of in step 472. If the evaluated result of the formula does not meet the criteria, then in step 474, a conflict object is created, identifying the criteria, the numeric formula result, and indicating that retrieval of the formula was not possible due to the failure of the result of the formula to meet the criteria. After any of steps 464, 472 and 474, in step 476, a log entry is created and added to the log tree to reflect the processing that was performed on the formula object. Then in step 478, a source object is created and added to the source tree to identify the source for the formula object. Processing is then stopped 480.
- RULE and ACTION processing 366, 370 can be discussed.
- RULE and ACTION objects should not be encountered, and are not retrieved.
- step 467/473 a log object is created and added to the log tree, a child fail is returned (step 469/475)and then processing stops 471/477.
- step 479 a copy of the object is created, without its children, and the copy is added to the result tree.
- an object is carried from the input tree structure of objects to the result tree.
- step 482 a source object conesponding to the cunent object is created and added to the source tree.
- step 484 a log object is created and added to the log tree to indicate that the object was kept because of its DOCUMENT processing status. Processing then continues to step 396 as shown in Fig. 8, in which children of the cunent object are retrieved. After retrieval of the children of the cunent object, processing is done 486.
- PREPARATION processing 378 is performed in the same manner as REGULAR processing 346, as described above with reference to Fig. 7C.
- UNKNOWN processing 382 can be discussed.
- UNKNOWN objects should not be encountered, and are not retrieved. Accordingly, when an UNKNOWN object is encountered, in step 494, a log object is created and added to the log tree, a child fail is returned (step 496) and then processing stops 498.
- the process for retrieving the children of an object begins with evaluating 550, the child logic of the cunent object.
- step 554 the first child object is selected, and in step 556 the retrieval process of Fig. 6 A is called for this child object.
- step 558 if another child object is available, then in step 560 this additional child object is selected, and processing returns to step 556 to call the retrieval process of Fig. 6A for the next child object.
- step 564 it is determined whether all of the children return failed. If all children return failed, then in step 564, a "fail" value is returned, and retrieval of the children is done 566. If, however, at least one child object did not return failed, then because the child logic for the cunent object is OR, then in step 568 the results produced by retrieval of the child objects are added to the result tree, and then processing stops.
- step 572 the first child object is selected and in step 576, the retrieval process of Fig. 6A is invoked for the first child object. Immediately after this retrieval in step 578 a determination is made whether the child retrieved in step 576 return failed. If the child return failed, processing immediately proceeds to step 564 to return a failed value, and then stops. Only if the child did not return failed, processing proceeds to step 580 in which it is determined whether there is another child object for the cunent object. If there is another child object, then in step 582, the additional child object is selected and processing returns to step 576 to retrieve the additional child object.
- step 580 After all child objects have been retrieved, processing proceeds from step 580 to step 568 in all of the objects produced as a result of retrieval of the children are added to the result tree and then processing stops. Thus, only if all children do not return failed will children be added to the result tree.
- the child logic of the cunent object is GROUP 584, in step 586 the first child object is selected, and in step 588 the retrieve process of Fig. 6A is invoked for this first child object.
- step 590 it is determined whether there is another child object, and if so in step 592 this additional child object is selected and processing returns to step 588 to retrieve the next child object.
- step 590 After all child objects have been retrieved, whether or not failed, processing proceeds from step 590 to step 568 to add the results of the retrieval of the children to the result tree.
- step 598 an evaluation engine is invoked for the IF child object.
- step 600 the result of evaluation of the IF child object is used. If the result of the retrieve of the IF child object is not a failed condition, then processing proceeds to step 602, where the retrieval procedure of Fig. 6A is again called for the THEN child object. Then processing proceeds to step 568 to add the child results to the results to the results tree.
- step 600 determines whether there is an ELSE child object. If there is no ELSE child object, processing proceeds directly to step 564 and a failed condition is returned. If there is an ELSE child object, then in step 608 the retrieval procedure of Fig. 6A is invoked for this third child object. After retrieval of the ELSE child object, processing will continue to step 568 and the result of the retrieval of the child object will be added to the result tree. If the child logic of the cunent logic is DEPENDENCY 610, then, as noted above, during the retrieval process limited actions are taken to evaluate the logical relationship of the children and the object.
- step 611 the FOR child object is evaluated to determine whether it will always fail. If not, then in step 612, all children of the dependency object are moved directly to the result tree without further retrieval, and then processing is stopped. If the FOR child will always fail, then in step 613, only the OTHERWISE child(ren) are retrieved and added to the results tree.
- a process for combining retrieved objects to form a combination object can be explained.
- multiple trees of objects representing technical documents that are to be combined are converted to a single tree of objects that represents the combined requirements of each of the documents.
- This single object is refened to as a bottom-line object.
- a bottom-line object is created.
- a log object is created, which is used to indicate what routines were performed during combine and a source object is created, which is used to indicate the source of the various results in the bottom-line object.
- the combine routine like the retrieve routine, is a tail recursive procedure in which cu ⁇ ent invocations of the procedure recursively call the same procedure as the tree of objects being delivered to the combine routine is scanned.
- control passes to step 702 rather than step 700 so that the log, source and bottom-line objects are not unintentionally regenerated.
- a first analysis of the object being combined is made. Specifically, it is determined whether the object is an implication class object.
- implication class objects identify conditions and consequences of those conditions, but are not evaluated during combine routines. Accordingly, if the cu ⁇ ent object is an implication class object, control passes to step 706, in which all children of the implication object are copied to form a result object for the combine routine, and then processing of the combine routine is completed. If the cunent object is not an implication class object, then control passes from step 704 to step 708 in which the processing status of the cunent object is evaluated. As will be seen in the following, different actions are taken in combining an object based upon its processing status.
- step 710 If the processing status in step 710 is REGULAR, PREPARATION, FORMULA, REFERENCE, or FOR INFORMATION ONLY, then in step 712 copy of the object and any of its children are returned as the result of the combine routine, and a log entry is created reflecting that the object is included in the combine. If, in step 714, the processing status of the cunent object is DO NOT PROCESS or UNKNOWN, then the combine routine terminates immediately, as such objects should not be processed or cannot be processed. If, in step 716, the processing of the cu ⁇ ent object is DOCUMENT or PROCESS CHILDREN ONLY, then in step 717, a group object is created to form the first object in the result of the combine routine.
- step 719 the object with CHILD DEPENDENT processing status is copied to form the beginning of a result tree.
- step 720 the first child of the object is selected.
- step 722 the child object is fetched.
- step 724 a copy of the fetched child is attached to the result object.
- step 726 it is determined whether there is another child, and if so, processing returns to step 722.
- step 728 the result object and its children are passed to the combine children routine described below with reference to Fig. 9B.
- the result is the same number or fewer children, which are then returned along with the result object as the result of combination of the original tree. This result is returned in step 730 and a log object is created to reflect the manner in which it was created.
- step 732 the children of the object are evaluated to determine whether there is more than one child. If there is not more than one child, then in step 734 the child that was received as an input is returned as a result. If there is more than one child, then in step 736 the child logic of the parent is evaluated. If the child logic of the parent is SEQUENCE, EXCLUSIVE AND INCOMPLETE or DEPENDENCY, then in step 734 the input children are returned as the result. In all other cases, processing proceeds to step 738. In step 738, the generation of a new result is initiated by making a temporary copy of the parent object and moving the children received to the process beneath the temporary copy.
- step 740 the first child of the temporary copy is selected.
- step 742 the first child is evaluated to determine whether it is a collection object with GROUP child logic. If so, then in step 744, the children of the collection object are moved to become children of the temporary object, and the collection object is deleted. This causes collection objects to be removed as part of combining children. After step 744, processing returns to step 740 to again select the first child of the temporary parent object.
- step 742 If, in step 742, the cu ⁇ ent child being processed is not a collection object with GROUP child logic, then in step 746, the children are evaluated to determine if there is another child. If so, processing returns to step 742 to evaluate the next child.
- step 746 processing proceeds from step 746 to step 748 in which the first child is again selected as a candidate object and is removed from the parent object.
- step 750 the candidate object is evaluated to determine if it is a task object. If the candidate object is a task object, then in step 752 the candidate is moved back to the position of a child of the parent object that was received by the combine children routine of Fig. 9B. Then, in step 754, the temporary object is evaluated to determine if there are other children to be processed. If so, then processing returns to step 748 to select the first child for subsequent processing.
- step 750 the candidate object is not determined to be a task class object
- step 756 the first child remaining under the temporary parent object is selected for use as a test object.
- step 758 the candidate object and the test object are delivered to a combine two objects routine of Fig. 9C routine described below in Figure 9C. As elaborated below, the procedure of Figure 9C will evaluate the two objects to determine whether their meanings permit combination of the objects. If the objects cannot be combined, then an enor condition will be returned and processing will continue from step 758 to step 762, in which the temporary parent is evaluated to determine if there is another child to be used as a test object.
- step 764 to select the next child as the test object, then returns to step 758 to repeat the combine two objects routine of Fig. 9C. If there are no other children to be used as test objects, then processing proceeds from step 762 to step 752, the candidate object is moved to become a child of the parent child input to the combine children routine of Fig. 9B, as noted above.
- step 758 If in step 758 it is determined that the meaning of the two objects delivered to the combine two objects routine of Fig. 9C allows those objects to be combined, then a single object will be returned. This single object will either be a combined object reflecting the combined meaning of the two input objects, or will be a conflict object, reflecting that the two combined objects cannot be reconciled. In either case, processing proceeds to step 760 where the candidate object is replaced with the result object produced in step 758. Processing then proceeds to step 762 to determine whether there is another child of the temporary parent object to be tested as described above. After all children of the temporary parent object have been tested for combination with other children and returned to a position as children of the input parent object, in step 754 it will be determined that there are no other temporary children of the parent.
- processing proceeds to step 768 in which the input parent and its children which have been combined are returned as the result of the combine children routine of Fig. 9B.
- Fig. 9C the process for combining two objects can be explored. This process begins with step 770 in which the child logic of the parent of the two objects is evaluated. Different actions are taken for different objects, as explored below. If the child logic of the parent is CONFLICT, 771, this indicates the children cannot be combined and, therefore, in step 772, an indication is returned that the child objects cannot be combined.
- step 774 the two objects are evaluated to determine if both objects are procedures. If not, then in step 776 the two objects are evaluated to determine if their meaning or inte ⁇ retation are compatible. Specifically, the meaning/inte ⁇ retation pointed in each object is evaluated to determine if both pointers identify the same meaning object. If the meaning/inte ⁇ retation pointers for the two objects are not compatible, then in step 778, if either or both of the two objects has an inte ⁇ retation or meaning object which itself is an SDL definition, then the meaning of the parent of the SDL definition is obtained and it is compared in the same manner for compatibility. If, in this second step, it is determined that the objects do not have compatible meanings, then processing continues again to step 772 and an enor result is returned indicating that the objects may not be combined.
- step 774 If, in step 774, it is determined that the objects to be combined are procedures, then in step 780 the procedure names are compared to determine whether they are compatible, i.e. identical. If not, then the objects may not be combined and processing continues to step 772. If the child logic of the parent object is either AND or 783, or if the meaning and inte ⁇ retation of the objects are compatible in step 776 or step 778, then in step 784 the priorities of the two objects are compared. If the two objects do not have the same priority, then in step 786 the object with the higher priority is returned as the result of combining the two objects. This causes higher priority objects to override lower priority objects.
- a similar procedure may be used in alternative embodiments of the invention to prioritize verified objects, i.e.
- Prioritization based on approval status i.e. verified and unverified status, may be performed before or after prioritization based on the priority property of the objects.
- step 788 different actions are taken based upon the processing status of the two objects. Specifically, based on the processing status of the first object to be combined, processing will branch to CHILD DEPENDENT 790, FOR INFORMATION ONLY 792 and all other 794 branches. Under each of these branches, further branches will be performed based upon the processing status of the second object. Specifically, when the first object is CHILD DEPENDENT 790 and the second object is CHILD DEPENDENT 796, special processing for combining two objects which are both CHILD
- step 798 will be performed in step 798 as elaborated below with reference to Fig. 9D. If the first object is CHILD DEPENDENT 790 and the second object is FOR INFORMATION ONLY 800 then in step 802 a conflict object will be returned with the two objects as children, indicating that the two objects may not be combined. If the first object is CHILD DEPENDENT 790 and the second object is some other value 804, then in step 806, a copy of the CHILD DEPENDENT object will be included in the children of the other object. Then in step 728, the combine children routine of Fig. 9B will be repeated to attempt to combine the CHILD DEPENDENT object with the children of the other object. In step 808 the result is evaluated to determine whether any conflict object was created.
- step 810 the result is returned. If a conflict object was created, then there is a conflict between the CHILD DEPENDENT and other objects and so a conflict object is created in step 802 with the CHILD DEPENDENT and other object as children of the conflict object, and this conflict object is returned as the result of the combine two objects routine of Fig. 9C. If the first object is FOR INFORMATION ONLY 792, then the second object is either CHILD DEPENDENT 814, or other 824, processing proceeds to step 802 to return a conflict object. If the first object is FOR INFORMATION ONLY 792, and the second object is FOR INFORMATION ONLY 816, then in step 818 it is determined whether the two objects are exactly identical.
- the first object is returned 820 as the result of combining the two objects. If not, then the two objects cannot be combined and an enor condition is returned by proceeding to step 772. If the first object is other 794, and the second object is CHILD DEPENDENT, 826, then processing continues to step 826 to attempt to combine the two objects as described above. If the first object is other 794 and the second object is FOR INFORMATION ONLY 828, then processing proceeds to step 802 to return a conflict object as discussed above. If the first object is an other object 794 and the second object is an other object 829, then processing continues to a combine structures routine 830 described below with reference to Figure 9D.
- a first step 840 the objects are evaluated to determine whether the objects are either layer or collection class objects. If not, processing continues to a combine structures routine described below with reference to Fig. 9E. If the two objects are either a layer or collection object, then in step 842 the child logic of the two objects is evaluated to determine the appropriate action to take. As will be seen below, the action to be taken with respect to the two objects is highly dependent upon the child logic of the two objects.
- step 846 the two children are evaluated to determine if they are exactly the same. If so, in step 848, the first object is returned as the result. If the children are not exactly the same, then in step
- step 849 it is determined whether the two objects are both AND. If not, then in step 854 the conflict object is created. If both objects are AND, then in step 854
- step 850 all of the children of the two objects are placed beneath a temporary parent object. Then, in step 728, the combine children routine of Fig. 9B of
- Fig. 9B is invoked to attempt to combine the children into a smaller number of objects. Thereafter, in step 852, the result of the combine children routine of Fig. 9B is evaluated to determine whether any conflict objects were returned. If there were conflict objects returned, then in step 854 the conflict object is returned with the two objects input to the CHILD DEPENDENT processing routine 798 as its children. If no conflict objects are returned in step 728, then in step 856, the first object delivered to the CHILD DEPENDENT processing routine 798 is returned, with its children equal to the results returned in step 728. If the child logic of the two objects to be combined is both OR
- step 858 then in step 860, a unique pair of children from the two objects is selected, and this pair of children is passed to the combine two objects routine of Fig. 9C of Fig. 9C. Thereafter, if there is another unique pair in step 862, processing returns to step 758 to pass this unique pair to the combine two objects routine of Fig. 9C of Fig. 9C. After this process has been performed for every unique pair of children of the two objects, then in step 864, it is determined whether any non-conflict results were produced. If so, then in step
- step 854 an OR object is returned with all the non-conflict results as its children. If not, then in step 854 a conflict object is returned with the two objects passed to the CHILD DEPENDENT processing routine 798 as its children. If the two CHILD DEPENDENT objects to be combined have CHILD DEPENDENT child logic 870, then in step 872 a temporary object is created having as one child a first child of the OR object, and as a second set of children all of the children of the AND object. Then in step 728 the combine children routine of Fig. 9B of Fig. 9B is invoked.
- step 874 if there are any other children of the OR object, processing returns to step 872 to make a new temporary object having the next child of the OR object and all of the children of the AND object and the combine children routine of Fig. 9B of Fig. 9B is again invoked.
- step 876 an OR object is returned, including all of the results produced in step 728 as its children. If the child logic of the two CHILD DEPENDENT obj ects is
- step 854 a conflict object is returned having these two objects as their children, since objects with this combination of child logic cannot be combined.
- step 884 the children of the first and second objects are put together under one of the two objects and this object is then passed to the combine children routine of Fig. 9B of Fig. 9B.
- the result of the combine children routine of Fig. 9B will then be the result of combining the two CHILD DEPENDENT objects.
- step 888 a temporary copy is created of the
- step 728 the combine children routine of Fig. 9B of Fig. 9B is invoked to attempt to combine the children of the new temporary object.
- step 890 it is determined whether any conflict objects were produced as a result of the combine children routine of Fig. 9B. If not, then at step 892 the AND object is replaced with the result of the combine children routine of Fig. 9B, and the child of the GROUP object that was used is removed from the GROUP object. Thereafter, or immediately after step 890 if a conflict object was produced, the GROUP object is evaluated to determine if it has another child in step 894.
- processing returns to step 888 in which the AND object and its children are copied and another child of the GROUP object is added to the children of the copy of the AND object.
- processing proceeds from step 894 to step 896 where it is determined whether there are any children of the GROUP object remaining. Children will be remaining in the GROUP object if conflicts were created between the children of the AND object and any one child of the GROUP object. If children are remaining, then in step 898, a conflict object is returned including the cunent AND object and the GROUP object as its children. If no children remain in the GROUP object, then none of the children of the GROUP object conflicted with children of the AND object, and in this case, in step 900, the AND object is returned.
- step 910 the objects are evaluated to determine if they are of the same class. If not, then in step 912, a conflict object is returned with two objects as its children. Only if the objects are of the same class is an attempt made to combine the objects. Specifically, in step 914, the object operators of the two objects are compared. As will be seen below, different actions are taken for different combinations of object operators in the two objects being combined. Cases are illustrated in Fig. 9E at steps 916, 918, 920, 922, 924, 926, 928, 930, 932,
- step 950 the properties of the two objects are compared. If the two properties are equal, then in step 952 the first object is returned as the result of the combine routine. If the properties of the two objects are not equal, then in step 912, a conflict object is returned having the two objects as children.
- a conflict object is returned.
- the object properties must be compared to determine whether they are equal.
- both objects have an object operator of greater than (>). In this situation, the largest property is returned .in step 972. In case 926, one property has an object operator of greater than
- step 970 the properties are compared to determine if they are equal. If so, in step 974, the property having the greater than (>) object operator is returned. If the properties are not equal, then the property having the largest value is returned in step 972.
- step 983 the object having the smallest property is returned.
- the properties must be compared to determine what action to take. Specifically, in step 984, the properties are compared to determine whether they are equal. If the properties are equal then step 986 the object having the object operator of less than ( ⁇ ) is returned. If the properties are not equal, then in step 983, the smallest property is returned.
- step 936 again the properties must be compared to determine the appropriate action to take.
- step 992 the properties are compared to determine whether they are equal. If so, then in step 994, the object having an operator of less than or equal ( ⁇ ) or greater than or equal (>) is returned, but its object operator is changed to less than ( ⁇ ) or greater than (>), respectively. If the properties of the two objects are not equal, then in step 996 it is determined whether the property of the second object is grater than the property of the first object. If so, then in step 998 the object with an operator of greater than or equal ( ⁇ ) or less than or equal ( ⁇ ) is returned. If not, in step 912 a conflict object is returned.
- step 938 the properties must be compared in step 996 to determine the appropriate action to take, and then proceed to step 998 or 912.
- step 940 the properties must be compared to determine the appropriate action to take. Specifically, in step 1004, it is determined whether the first property is greater than the second property. If not, then in step 912 a conflict object is returned. If so, then in step 1006 an object having the object operator of less than ( ⁇ ) or greater than (>) or less than or equal ( ⁇ ) or greater than or equal ( ⁇ ) is returned.
- step 1000 again the properties must be compared to determine the appropriate action to take. Specifically, in step 1000, it is
Abstract
Description
Claims
Priority Applications (9)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2001510145A JP2003504764A (en) | 1999-07-08 | 2000-07-05 | Display, management, filtering and composition of technical content |
IL14750800A IL147508A0 (en) | 1999-07-08 | 2000-07-05 | Representation, management, filtering and synthesis of technical content |
EP00947047A EP1196877B1 (en) | 1999-07-08 | 2000-07-05 | Representation, management and synsthesis of technical content |
AU60716/00A AU6071600A (en) | 1999-07-08 | 2000-07-05 | Representation, management, filtering and systhesis of technical content |
CA002378248A CA2378248A1 (en) | 1999-07-08 | 2000-07-05 | Representation, management, filtering and synthesis of technical content |
AT00947047T ATE241176T1 (en) | 1999-07-08 | 2000-07-05 | PRESENTATION, MANAGEMENT AND SYNTHESIS OF TECHNICAL CONTENT |
DE60002876T DE60002876T2 (en) | 1999-07-08 | 2000-07-05 | PRESENTATION, ADMINISTRATION AND SYNTHESIS OF TECHNICAL CONTENT |
IL147508A IL147508A (en) | 1999-07-08 | 2002-01-08 | Representation, management, filtering and synthesis of technical content |
IL180606A IL180606A0 (en) | 1999-07-08 | 2007-01-09 | Representation, management, filtering and synthesis of technical content |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US09/349,753 US6405211B1 (en) | 1999-07-08 | 1999-07-08 | Object-oriented representation of technical content and management, filtering, and synthesis of technical content using object-oriented representations |
US09/349,753 | 1999-07-08 |
Publications (2)
Publication Number | Publication Date |
---|---|
WO2001004812A2 true WO2001004812A2 (en) | 2001-01-18 |
WO2001004812A3 WO2001004812A3 (en) | 2001-11-15 |
Family
ID=23373812
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/US2000/018422 WO2001004812A2 (en) | 1999-07-08 | 2000-07-05 | Representation, management, filtering and systhesis of technical content |
Country Status (9)
Country | Link |
---|---|
US (2) | US6405211B1 (en) |
EP (2) | EP1196877B1 (en) |
JP (1) | JP2003504764A (en) |
AT (1) | ATE241176T1 (en) |
AU (1) | AU6071600A (en) |
CA (1) | CA2378248A1 (en) |
DE (1) | DE60002876T2 (en) |
IL (3) | IL147508A0 (en) |
WO (1) | WO2001004812A2 (en) |
Families Citing this family (70)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8321411B2 (en) * | 1999-03-23 | 2012-11-27 | Microstrategy, Incorporated | System and method for management of an automatic OLAP report broadcast system |
US6405211B1 (en) | 1999-07-08 | 2002-06-11 | Cohesia Corporation | Object-oriented representation of technical content and management, filtering, and synthesis of technical content using object-oriented representations |
US6550057B1 (en) * | 1999-08-31 | 2003-04-15 | Accenture Llp | Piecemeal retrieval in an information services patterns environment |
US6684216B1 (en) * | 1999-09-29 | 2004-01-27 | Katherine A. Duliba | Method and computer system for providing input, analysis, and output capability for multidimensional information |
US7047281B1 (en) | 2000-08-08 | 2006-05-16 | Fineground Networks | Method and system for accelerating the delivery of content in a networked environment |
WO2002012997A1 (en) * | 2000-08-08 | 2002-02-14 | Fineground Networks | Method and system for parameterized web documents |
US8024217B2 (en) * | 2000-08-17 | 2011-09-20 | Mamoud Sadre | Method of tradeable financial instrument from value-added manufactured product by pareto market analysis |
JP4657432B2 (en) * | 2000-09-28 | 2011-03-23 | 富士通株式会社 | Device for converting hierarchical structured documents |
US6847956B2 (en) * | 2001-02-06 | 2005-01-25 | General Electric Company | System and method for determining specific requirements from general requirements documents |
US7310687B2 (en) * | 2001-03-23 | 2007-12-18 | Cisco Technology, Inc. | Methods and systems for managing class-based condensation |
US7080328B1 (en) * | 2001-03-28 | 2006-07-18 | Ebay, Inc. | Graphical user interface for filtering a population of items |
US7890517B2 (en) * | 2001-05-15 | 2011-02-15 | Metatomix, Inc. | Appliance for enterprise information integration and enterprise resource interoperability platform and methods |
US7058637B2 (en) * | 2001-05-15 | 2006-06-06 | Metatomix, Inc. | Methods and apparatus for enterprise application integration |
US6925457B2 (en) * | 2001-07-27 | 2005-08-02 | Metatomix, Inc. | Methods and apparatus for querying a relational data store using schema-less queries |
US20030208499A1 (en) * | 2002-05-03 | 2003-11-06 | David Bigwood | Methods and apparatus for visualizing relationships among triples of resource description framework (RDF) data sets |
US6856992B2 (en) * | 2001-05-15 | 2005-02-15 | Metatomix, Inc. | Methods and apparatus for real-time business visibility using persistent schema-less data storage |
US20030046093A1 (en) * | 2001-08-30 | 2003-03-06 | Erickson John S. | Rights management |
US8589400B2 (en) * | 2001-11-30 | 2013-11-19 | Intelligent Medical Objects, Inc. | Longitudinal electronic record system and method |
US7693917B2 (en) | 2001-11-30 | 2010-04-06 | Intelligent Medical Objects, Inc. | Method for adaptive data management |
US7124140B2 (en) * | 2001-12-10 | 2006-10-17 | Oracle International Corporation | Database system having heterogeneous object types |
US7210097B1 (en) | 2002-05-22 | 2007-04-24 | Pitney Bowes Inc. | Method for loading large XML documents on demand |
US20030225783A1 (en) * | 2002-05-28 | 2003-12-04 | Han-Chao Lee | Task object correlation method |
US20040019589A1 (en) * | 2002-07-25 | 2004-01-29 | Basrur Rajesh G. | Driver for mapping standard database queries and commands to markup language documents |
CA2501847A1 (en) * | 2002-10-07 | 2004-04-22 | Metatomix, Inc | Methods and apparatus for identifying related nodes in a directed graph having named arcs |
US7299448B2 (en) * | 2003-03-28 | 2007-11-20 | International Business Machines Corporation | Context-sensitive attributes |
US7689569B2 (en) * | 2003-03-31 | 2010-03-30 | Qwest Communications International Inc. | Systems and methods for managing large data environments |
EP1690210A2 (en) * | 2003-07-07 | 2006-08-16 | Metatomix, Inc. | Surveillance, monitoring and real-time events platform |
US7590971B2 (en) * | 2003-08-01 | 2009-09-15 | Idx Investment Corporation | Enterprise task manager |
US8401688B2 (en) * | 2004-02-26 | 2013-03-19 | The Boeing Company | Identification of engineering intent requirements in an electronic environment |
US7665063B1 (en) | 2004-05-26 | 2010-02-16 | Pegasystems, Inc. | Integration of declarative rule-based processing with procedural programming |
WO2006059240A2 (en) * | 2004-06-16 | 2006-06-08 | Ids Scheer Aktiengesellschaft | User interface for complex process inplementation |
US8335704B2 (en) | 2005-01-28 | 2012-12-18 | Pegasystems Inc. | Methods and apparatus for work management and routing |
US7490098B2 (en) * | 2005-06-10 | 2009-02-10 | International Business Machines Corporation | Apparatus, system, and method for processing hierarchical data in disparate data repositories |
EP1922620A4 (en) | 2005-08-10 | 2010-11-17 | Iav Gmbh Ingenieursgesellschaf | Creating, designing, managing, scheduling, developing and producing products |
US7809761B2 (en) | 2005-10-11 | 2010-10-05 | Idx Investment Corporation | Data object tracking system and method |
US8224853B2 (en) * | 2005-11-02 | 2012-07-17 | Sourcecode Technologies Holdings, Inc. | Methods and apparatus for updating a plurality of data fields in an electronic form |
US8239226B2 (en) * | 2005-11-02 | 2012-08-07 | Sourcecode Technologies Holdings, Inc. | Methods and apparatus for combining properties and methods from a plurality of different data sources |
US20070208777A1 (en) * | 2005-11-02 | 2007-09-06 | Sourcecode Technology Holding, Inc. | Methods and apparatus for designing a workflow process using resource maps and process maps |
US20070143305A1 (en) * | 2005-11-02 | 2007-06-21 | Sourcecode Technology Holding, Inc. | Methods and apparatus for storing functions associated with an electronic form |
US9348799B2 (en) * | 2005-12-09 | 2016-05-24 | Adobe Systems Incorporated | Forming a master page for an electronic document |
US7774300B2 (en) * | 2005-12-09 | 2010-08-10 | International Business Machines Corporation | System and method for data model and content migration in content management applications |
US8924335B1 (en) | 2006-03-30 | 2014-12-30 | Pegasystems Inc. | Rule-based user interface conformance methods |
JP4146479B2 (en) * | 2006-09-28 | 2008-09-10 | 株式会社東芝 | Structured document search device, structured document search method, and structured document search program |
US7796309B2 (en) * | 2006-11-14 | 2010-09-14 | Microsoft Corporation | Integrating analog markups with electronic documents |
CN101197011A (en) * | 2006-12-08 | 2008-06-11 | 深圳富泰宏精密工业有限公司 | Graphics file management system |
US8250525B2 (en) | 2007-03-02 | 2012-08-21 | Pegasystems Inc. | Proactive performance management for multi-user enterprise software systems |
EP2145297A4 (en) * | 2007-05-08 | 2012-05-30 | Sourcecode Technology Holding Inc | Methods and apparatus for exposing workflow process definitions as business objects |
US7809702B2 (en) * | 2007-05-08 | 2010-10-05 | International Business Machines Corporation | Generating from application modifications commands to modify the objects in a repository |
US8056000B2 (en) * | 2007-08-27 | 2011-11-08 | International Business Machines Corporation | Apparatus and system for an automated bidirectional format transform |
US7958154B2 (en) * | 2007-08-29 | 2011-06-07 | International Business Machines Corporation | Apparatus, system, and method for command manager support for pluggable data formats |
US8763087B2 (en) * | 2008-10-09 | 2014-06-24 | Yahoo! Inc. | System and method for content access control |
US10481878B2 (en) * | 2008-10-09 | 2019-11-19 | Objectstore, Inc. | User interface apparatus and methods |
US8843435B1 (en) | 2009-03-12 | 2014-09-23 | Pegasystems Inc. | Techniques for dynamic data processing |
US8849873B2 (en) * | 2009-03-18 | 2014-09-30 | Bentley Systems, Incorporated | Specifications automation system and method |
US8468492B1 (en) | 2009-03-30 | 2013-06-18 | Pegasystems, Inc. | System and method for creation and modification of software applications |
US9146913B2 (en) | 2010-03-29 | 2015-09-29 | Bentley Systems, Incorporated | Specifications automation system and method |
US8880487B1 (en) | 2011-02-18 | 2014-11-04 | Pegasystems Inc. | Systems and methods for distributed rules processing |
US20140325330A1 (en) * | 2011-11-25 | 2014-10-30 | Assignment Angels Pty Ltd | Pedagogical System and Method |
US9195936B1 (en) | 2011-12-30 | 2015-11-24 | Pegasystems Inc. | System and method for updating or modifying an application without manual coding |
CN103440352B (en) * | 2013-09-24 | 2017-04-19 | 中国科学院自动化研究所 | Method and device for analyzing correlation among objects based on deep learning |
US10469396B2 (en) | 2014-10-10 | 2019-11-05 | Pegasystems, Inc. | Event processing with enhanced throughput |
CN105824855B (en) * | 2015-01-09 | 2019-12-13 | 阿里巴巴集团控股有限公司 | Method and device for screening and classifying data objects and electronic equipment |
CN105429996B (en) * | 2015-12-15 | 2019-05-31 | 浙江远望信息股份有限公司 | A method of intelligence discovery and positioning address conversion equipment |
US10372834B2 (en) | 2016-01-15 | 2019-08-06 | DISCUS Software Company | Creating and using an integrated technical data package |
US10698599B2 (en) | 2016-06-03 | 2020-06-30 | Pegasystems, Inc. | Connecting graphical shapes using gestures |
US10698647B2 (en) | 2016-07-11 | 2020-06-30 | Pegasystems Inc. | Selective sharing for collaborative application usage |
US11429642B2 (en) * | 2017-11-01 | 2022-08-30 | Walmart Apollo, Llc | Systems and methods for dynamic hierarchical metadata storage and retrieval |
US11048488B2 (en) | 2018-08-14 | 2021-06-29 | Pegasystems, Inc. | Software code optimizer and method |
US11641354B2 (en) * | 2020-03-09 | 2023-05-02 | Nant Holdings Ip, Llc | Enhanced access to media, systems and methods |
US11567945B1 (en) | 2020-08-27 | 2023-01-31 | Pegasystems Inc. | Customized digital content generation systems and methods |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5530853A (en) * | 1992-11-12 | 1996-06-25 | International Business Machines Corportaion | Method for filtering items in a computer application program container object using filter data for related entries in a container object of another application program |
US5727204A (en) * | 1995-06-07 | 1998-03-10 | Hughes Electronics | Database organization for rapid multi-set membership determination |
US5956508A (en) * | 1994-08-26 | 1999-09-21 | International Business Machines Corporation | Creation of manageable management collections using filters |
Family Cites Families (33)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPS61123934A (en) * | 1984-11-20 | 1986-06-11 | Fujitsu Ltd | Automatic producing system of table specification |
US4833594A (en) * | 1986-12-22 | 1989-05-23 | International Business Machines | Method of tailoring an operating system |
US5261080A (en) | 1987-08-21 | 1993-11-09 | Wang Laboratories, Inc. | Matchmaker for assisting and executing the providing and conversion of data between objects in a data processing system storing data in typed objects having different data formats |
US5293585A (en) | 1989-08-31 | 1994-03-08 | Kabushiki Kaisha Toshiba | Industrial expert system |
US5333237A (en) | 1989-10-10 | 1994-07-26 | Hughes Aircraft Company | Hypermedia structured knowledge base system |
JPH04211865A (en) * | 1990-03-16 | 1992-08-03 | Hitachi Ltd | Method for supporting routine document preparation |
JP3266246B2 (en) | 1990-06-15 | 2002-03-18 | インターナシヨナル・ビジネス・マシーンズ・コーポレーシヨン | Natural language analysis apparatus and method, and knowledge base construction method for natural language analysis |
US5701466A (en) | 1992-03-04 | 1997-12-23 | Singapore Computer Systems Limited | Apparatus and method for end user queries |
JPH07129691A (en) * | 1993-11-02 | 1995-05-19 | Nec Corp | Written proposal preparing device |
US5689417A (en) | 1994-03-11 | 1997-11-18 | Southwire Company | Medium-voltage cable expert system |
US5504890A (en) | 1994-03-17 | 1996-04-02 | Sanford; Michael D. | System for data sharing among independently-operating information-gathering entities with individualized conflict resolution rules |
JPH07319917A (en) | 1994-05-24 | 1995-12-08 | Fuji Xerox Co Ltd | Document data base managing device and document data base system |
US5799268A (en) | 1994-09-28 | 1998-08-25 | Apple Computer, Inc. | Method for extracting knowledge from online documentation and creating a glossary, index, help database or the like |
US5550746A (en) | 1994-12-05 | 1996-08-27 | American Greetings Corporation | Method and apparatus for storing and selectively retrieving product data by correlating customer selection criteria with optimum product designs based on embedded expert judgments |
US5980096A (en) * | 1995-01-17 | 1999-11-09 | Intertech Ventures, Ltd. | Computer-based system, methods and graphical interface for information storage, modeling and stimulation of complex systems |
US5737739A (en) | 1995-12-19 | 1998-04-07 | Xerox Corporation | System that accesses a knowledge base by markup language tags |
US5765137A (en) | 1996-03-04 | 1998-06-09 | Massachusetts Institute Of Technology | Computer system and computer-implemented process for correlating product requirements to manufacturing cost |
US5983237A (en) * | 1996-03-29 | 1999-11-09 | Virage, Inc. | Visual dictionary |
US5778378A (en) | 1996-04-30 | 1998-07-07 | International Business Machines Corporation | Object oriented information retrieval framework mechanism |
US5970476A (en) * | 1996-09-19 | 1999-10-19 | Manufacturing Management Systems, Inc. | Method and apparatus for industrial data acquisition and product costing |
US6182029B1 (en) * | 1996-10-28 | 2001-01-30 | The Trustees Of Columbia University In The City Of New York | System and method for language extraction and encoding utilizing the parsing of text data in accordance with domain parameters |
JP3896621B2 (en) * | 1997-02-24 | 2007-03-22 | 石川島播磨重工業株式会社 | Document creation apparatus and method |
JP3887867B2 (en) * | 1997-02-26 | 2007-02-28 | 株式会社日立製作所 | How to register structured documents |
US6169987B1 (en) * | 1997-03-25 | 2001-01-02 | Mci Communications Corporation | System and method to automate equipment placement at remote sites |
US6112210A (en) * | 1997-10-31 | 2000-08-29 | Oracle Corporation | Apparatus and method for null representation in database object storage |
US6112207A (en) * | 1997-10-31 | 2000-08-29 | Oracle Corporation | Apparatus and method which features linearizing attributes of an information object into a string of bytes for object representation and storage in a database system |
US6061690A (en) * | 1997-10-31 | 2000-05-09 | Oracle Corporation | Apparatus and method for storage of object collections in a database system |
US6154738A (en) * | 1998-03-27 | 2000-11-28 | Call; Charles Gainor | Methods and apparatus for disseminating product information via the internet using universal product codes |
US6083276A (en) * | 1998-06-11 | 2000-07-04 | Corel, Inc. | Creating and configuring component-based applications using a text-based descriptive attribute grammar |
US6192364B1 (en) * | 1998-07-24 | 2001-02-20 | Jarg Corporation | Distributed computer database system and method employing intelligent agents |
US6263332B1 (en) * | 1998-08-14 | 2001-07-17 | Vignette Corporation | System and method for query processing of structured documents |
US6249844B1 (en) * | 1998-11-13 | 2001-06-19 | International Business Machines Corporation | Identifying, processing and caching object fragments in a web environment |
US6405211B1 (en) | 1999-07-08 | 2002-06-11 | Cohesia Corporation | Object-oriented representation of technical content and management, filtering, and synthesis of technical content using object-oriented representations |
-
1999
- 1999-07-08 US US09/349,753 patent/US6405211B1/en not_active Expired - Lifetime
-
2000
- 2000-07-05 CA CA002378248A patent/CA2378248A1/en not_active Abandoned
- 2000-07-05 DE DE60002876T patent/DE60002876T2/en not_active Expired - Fee Related
- 2000-07-05 AT AT00947047T patent/ATE241176T1/en not_active IP Right Cessation
- 2000-07-05 IL IL14750800A patent/IL147508A0/en active IP Right Grant
- 2000-07-05 EP EP00947047A patent/EP1196877B1/en not_active Expired - Lifetime
- 2000-07-05 EP EP03076294A patent/EP1341115A3/en not_active Withdrawn
- 2000-07-05 WO PCT/US2000/018422 patent/WO2001004812A2/en active Application Filing
- 2000-07-05 JP JP2001510145A patent/JP2003504764A/en active Pending
- 2000-07-05 AU AU60716/00A patent/AU6071600A/en not_active Abandoned
-
2002
- 2002-01-08 IL IL147508A patent/IL147508A/en not_active IP Right Cessation
- 2002-05-13 US US10/144,104 patent/US6658428B2/en not_active Expired - Fee Related
-
2007
- 2007-01-09 IL IL180606A patent/IL180606A0/en unknown
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5530853A (en) * | 1992-11-12 | 1996-06-25 | International Business Machines Corportaion | Method for filtering items in a computer application program container object using filter data for related entries in a container object of another application program |
US5956508A (en) * | 1994-08-26 | 1999-09-21 | International Business Machines Corporation | Creation of manageable management collections using filters |
US5727204A (en) * | 1995-06-07 | 1998-03-10 | Hughes Electronics | Database organization for rapid multi-set membership determination |
Also Published As
Publication number | Publication date |
---|---|
EP1196877B1 (en) | 2003-05-21 |
EP1341115A2 (en) | 2003-09-03 |
JP2003504764A (en) | 2003-02-04 |
DE60002876D1 (en) | 2003-06-26 |
IL147508A0 (en) | 2002-08-14 |
US20030014424A1 (en) | 2003-01-16 |
IL147508A (en) | 2007-03-08 |
US6658428B2 (en) | 2003-12-02 |
WO2001004812A3 (en) | 2001-11-15 |
DE60002876T2 (en) | 2004-04-22 |
CA2378248A1 (en) | 2001-01-18 |
ATE241176T1 (en) | 2003-06-15 |
US6405211B1 (en) | 2002-06-11 |
EP1341115A3 (en) | 2004-09-01 |
AU6071600A (en) | 2001-01-30 |
EP1196877A2 (en) | 2002-04-17 |
IL180606A0 (en) | 2007-06-03 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US6405211B1 (en) | Object-oriented representation of technical content and management, filtering, and synthesis of technical content using object-oriented representations | |
US6795819B2 (en) | System and method for building and maintaining a database | |
US7035837B2 (en) | Document component management and publishing system | |
US5752021A (en) | Document database management apparatus capable of conversion between retrieval formulae for different schemata | |
US6377956B1 (en) | Automatically configuring product manual by binding document objects in logical structure to proper versions of component documents in a document database | |
US6052693A (en) | System for assembling large databases through information extracted from text sources | |
JP4644420B2 (en) | Method and machine-readable storage device for retrieving and presenting data over a network | |
US9858255B1 (en) | Computer-implemented method and system for automated claim construction charts with context associations | |
US5649218A (en) | Document structure retrieval apparatus utilizing partial tag-restored structure | |
US5802529A (en) | Apparatus and method for document database management of documents having a plurality of document structures | |
US20060218160A1 (en) | Change control management of XML documents | |
US20030172357A1 (en) | Knowledge management using text classification | |
US20020147711A1 (en) | Apparatus, method, and program for retrieving structured documents | |
US20020103835A1 (en) | Methods and apparatus for constructing semantic models for document authoring | |
WO2002031690A2 (en) | A universal device to construct outputs for xml queries | |
JP2004501421A (en) | Method and apparatus for generating metadata for documents | |
JP2004506955A (en) | Reusable data markup language | |
CN101171582A (en) | Dynamic method for xml documents generation from a database | |
JP2003044491A (en) | Knowledge analytic system. method for setting analytic condition, saving analytic condition and re-analyzing processing in the system | |
JP2003281149A (en) | Method of setting access right and system of structured document management | |
WO2001018630A2 (en) | Xml dynamic content retrieval using style and content definition sheets | |
EP1014283A1 (en) | Intranet-based cataloguing and publishing system and method | |
JP2002297601A (en) | Method and device for structured document management, and program | |
Böhm et al. | Building a hybrid database application for structured documents | |
JP4013632B2 (en) | XML format data deduplication method and apparatus, program, and computer-readable recording medium |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AK | Designated states |
Kind code of ref document: A2 Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CR CU CZ DE DK DM DZ EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG UZ VN YU ZA ZW |
|
AL | Designated countries for regional patents |
Kind code of ref document: A2 Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG |
|
121 | Ep: the epo has been informed by wipo that ep was designated in this application | ||
DFPE | Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101) | ||
AK | Designated states |
Kind code of ref document: A3 Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CR CU CZ DE DK DM DZ EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG UZ VN YU ZA ZW |
|
AL | Designated countries for regional patents |
Kind code of ref document: A3 Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG |
|
WWE | Wipo information: entry into national phase |
Ref document number: 147508 Country of ref document: IL Ref document number: 2378248 Country of ref document: CA |
|
WWE | Wipo information: entry into national phase |
Ref document number: 2000947047 Country of ref document: EP |
|
WWP | Wipo information: published in national office |
Ref document number: 2000947047 Country of ref document: EP |
|
REG | Reference to national code |
Ref country code: DE Ref legal event code: 8642 |
|
WWG | Wipo information: grant in national office |
Ref document number: 2000947047 Country of ref document: EP |
|
WWE | Wipo information: entry into national phase |
Ref document number: 180606 Country of ref document: IL |