User interface and methods for building structural queries

Disclosed herein is a user interface and methods for building a formulated query to search a database of structural data which is organized by classes, attributes of classes, literals of attributes, and structural relations between classes. The user interface can display results of the formulated query and includes a structural query section to define constraints for the formulated query. The structural query section includes one or more query elements to be populated and a means for adding one or more additional query elements, wherein each query element can have a class portion which is populated by designating one of a special class identifier and a concrete class identifier, and can have one or more attribute and literal portions. The class portion can be populated by designating the class identifier from an offered list, and the user interface can further include an offer section which displays the offered list. The offered class identifiers, relation identifiers, attribute identifiers and literal values can come from the particular searched structural data. The offered class identifiers, relation identifiers and attribute identifiers can come from the definition of the structural content of the searched data. A relationship between query elements is expressible using a defined structural relation, such as a “contains” relation. Relationships between two or more query elements or two or more query element attribute-literal pair portions are also expressible using logical relations, such as a logical “AND” relation, a logical “OR” relation, and a logical “XOR” relation. A query results section displays results of the formulated query after the formulated query is executed.

CROSS-REFERENCE TO RELATED APPLICATIONS

Not Applicable

Not Applicable

FIELD OF THE INVENTION

The present invention relates to a user interface and methods for building structural queries.

BACKGROUND OF THE INVENTION

Industrial automation or control systems include controllers to monitor and control machinery in a manufacturing process, as well as human machine interfaces (HMI) to allow operators to interact with the controllers or other devices in the systems. A controller of this type typically is a special purpose computer that runs a stored control program in a specific programming language in real-time. The controller examines a series of inputs, typically from sensors, reflecting the status of a controlled machine or process and, based on the logic of the control program, generates outputs in the form of electrical signals to control actuators or the like to control the machine or process. One type of controller is a programmable logic controller (PLC), which typically runs under the direction of a ladder logic program that includes instructions or statements which define relationships between an output variable and one or more input variables. In ladder logic programs, the input and output variables can be represented graphically as contact symbols and coil symbols arranged in a series of rungs running between a pair of vertical power rails, and it is common to represent and view these programs graphically.

Industrial control systems can store a significant amount of data of various types and taking a variety of forms, including for example, HMI display graphic files (GFX), HMI project configurations, PLC files with ladder logic code, network configuration, file attributes and file metadata, for example New Technology File System (NTFS) metadata. Much of this data is stored in associated data files on file systems in one or more locations. The industrial devices can also generate a significant amount of data relevant to the operation of the manufacturing process, such as data from sensors or data indicative of various events, including alarms that can occur in the control system. This industrial data can be relevant and useful to an operator such as a control system designer or control system administrator in order to design new systems, add components, design new programs or interfaces, or troubleshoot problems.

Industrial data of these types can be converted to a structural data form and stored in a structured database. Various structural data forms exist, such as for example, XML (extensible markup language), OWL (web ontology language), or RDF (resource description framework) formats. Searching a structured database, such as an RDF-Schema (RDFS) or OWL configured database, requires knowledge of a specialized and complex query language, such as SPARQL (query language for RDF). SPARQL can thus be used to produce queries for searching an RDF representation of file content, including content representative of ladder logic programs, graphic files, etc. For querying XML databases, specialized and complex query languages, such as XQuery and XPath are also required. To be able to query databases containing structural data using the above mentioned query languages directly, a user would have to be familiar with the relations and hierarchy between the data, which are stored in the database, and also with the names of items forming the structure (e.g., names of classes and their attributes), and with the content and format of values (e.g., strings, numbers, dates).

When performing such a search, a user will often have to become familiar with numerous types of objects (such as for example “Tags”), their properties (attributes), values of these properties, and with reciprocal relations between the objects, which form a hierarchical structure. The aforementioned “Tags” are commonly used for identification of a memory unit in a particular device. Without the knowledge of the specific object types, their properties, values assigned to the properties, and relations used on particular devices or in particular file types (such as HMI files), search requests may continually fail to produce any results, even if a user is well versed in the complex query language.

Accordingly, it would be desirable to provide a method for generating structural queries for industrial or any other data which does not require extensive knowledge of searched object types, their properties, values of the properties, relations used in the structure, and a complex query language. It would further be desirable to provide a method for generating structural queries which overcomes the limitations of conventional searching techniques resulting from unfamiliarity with the variables used in conjunction with the various devices or files.

BRIEF SUMMARY OF THE INVENTION

The invention relates to a user interface and methods for building structural queries which allow a user to build such queries seamlessly and without the need to be familiar with the structure and the content of the searched data which is stored in a database and without the need to be familiar with a complex query language. Using the interface, a user can build structural queries without the need to formulate them directly in the complex query language.

The data searched by a formulated structural query are expected to have a structural form that includes containers (classes), which can have, but need not have, one or more properties (attributes). Containers (classes) are structurally related to other containers (classes), forming a hierarchical data structure. Properties (attributes) can have, but need not have, one or more values (literals). Each class has identification, e.g., a name of that class, which is not treated as a property of that class. Similarly, each attribute has identification, e.g., a name of that attribute. As used herein, the nomenclature of containers, properties of containers, and values of properties is considered essentially equivalent to classes, attributes of classes, and literals of attributes, as illustrated and described in the example below.

A structural query can be built step by step by defining constraints in one or more query elements, and defining a structure of query elements by expressing relationships between them using one or more defined interconnections including structural relations and logical relations. A query element is a construction block of the structural query and initially includes one or more portions to be filled in or populated. The query element portions can include a class portion for designating a class (using an identifier) and one or more other portions for designating an attribute and possibly a literal. A populated query element thus expresses constraints possibly for a class and possibly for its attributes and literals assigned to those attributes. If present, each class portion can be populated with a concrete class identifier or a special class identifier. If present, an attribute portion, a literal portion, or an attribute-literal pair portion can be populated in a similar manner. Automatic default designations can also exist. For example, if an attribute portion is populated, a class portion can automatically be populated by an “ANY CLASS” item. Relationships between query element portions can be expressed using one or more logical relations.

In particular, concrete identifiers include names of structural relations, names of classes, names of attributes, or specific values of literals such as number, string, date etc. Special identifiers essentially act as “wild-cards”, able to replace any class, attribute, literal or structural relation. For example, using a special class identifier to populate a class portion in a query element can express that the user doesn't care about the names of classes possible at the appropriate structural position in the query. The same is true for an attribute portion of a query element or a literal portion of a query element, where the user doesn't care about the names of attributes of the appropriate class, or the literals for some attribute. The same can be true for existing relations in a given structure position. However, a special identifier can also be used to mark a position in the query, values of which a user doesn't know, but wants to find. This special identifier can be called for example variable and has assigned an identifier, such as a variable name, allowing one to distinguish individual variables. Values or combinations of values corresponding to defined variables represent query results. A query can be run using the so-far defined constraints to generate query results which provide available concrete values (identifiers of classes, attributes and relations, or values of literals) for variables with respect to the so-far defined constraints.

The user interfaces and methods described herein allow the construction of structural queries by providing a means to define an overall structure of one or more query elements and a means to fill-in (populate) the query elements in a way that a user can only enter or select parameters to ensure the correctness and validity of the query, and/or in a way to ensure that at least some results to the formulated structural query will be obtained. One way to ensure that at least some results will be obtained can be achieved by offering selectable items (e.g., names of classes, names of attributes, names of relations, and values of literals) to the user for the query construction which items come from the actual data in the searched database. Ensuring the correctness and validity of the query can be achieved by defining a query element using the definition of the structural content of the searched data, i.e., not the actual searched data themselves, but their formal descriptions. In this case it is ensured that the formulated query will be syntactically and structurally correct, but not that it will return at least some results, because the actual data in the database doesn't necessarily have to fulfill all the possible patterns allowed by the structural definition. Also, in at least one embodiment, such as that illustrated and described below, at least some concrete literal values (such as a number or date) have to be manually entered, so neither their existence nor the correctness of their format is ensured.

Query elements can be interconnected using one or more defined structural relations, such as a “contains” relation, so forming a hierarchical structure. The “contains” relation is transitive, which means that when class A contains class B which contains class C, then class A contains class C. This shortened pattern can be used in a query instead of a complete listing of the paths between classes.

To express other constraints between query elements, other defined interconnections are available, including various logical relations such as a logical “AND”, a logical “OR”, a logical “eXclusive OR” (“XOR”), and possibly also other logical relations. The logical relation can interconnect query elements or portions within a query element to form a logical hierarchical structure. Classes connected with a logical relation or with a structure of logical relations are on the same structural hierarchical level. Similar to logical relations between classes, there can also be a logical relation or a structure of logical relations between attributes of a class. Additionally, there is a mathematical relationship defined between an attribute and its literal or group of literals, using mathematical operators including for example an equals operator, a not equals operator, a greater than operator, a less than operator, a greater than or equal to operator, a less than or equal to operator, string operators (e.g. substring), operators working with a set (e.g. one of a set) or working with a range (e.g. interval), etc.

The structure of the query is composed from query elements interconnected by structural and logical relations defined between them, as described above. A defined structure can be expanded in any direction. New query elements can be added as superior to already defined query elements, as inferior to already defined query elements, or they can be positioned inside the current structure, i.e. inferior to some query elements and superior to query elements previously directly inferior to their new directly superior query elements. A new logical relation can be created, or an existing logical relation, e.g. logical “AND” and/or logical “OR” can be extended by a new sibling query element.

When a new query element is created, it has to be filled with values (populated). As mentioned above, to make the query building process easy, seamless and secure, it is desirable to guide the user to construct a valid query, i.e., to construct structures of query elements (e.g., interconnected with structural relations) and to fill query elements with parameters (e.g., names of classes, names of attributes and values of literals), which ensures that for the structural query there exist corresponding data in the database, i.e., the formulated query matches some data in the database. One way to achieve this safe query building is to provide for query building only those parameters, which are really available in the searched data, and to do this with concern to the already defined query, i.e., with concern to the already existing constraints. Using this method, when editing a query element portion (class name, attribute name or literal value) or adding a new query element or editing a structural relation, the user is provided with suitable items for the particular position in the query (class names, attribute names, literal values, relations), which can be obtained from the data stored in the database, e.g. by an “explorative” query. This approach incorporates data exploration or browsing—the user is able to navigate through the searched data as the query is constructed. This is especially important when the user has only a vague notion of how to formulate a desired query.

Another possibility to build the structural shape of the query without having to instantly query the database is using the definition of the structural content of the searched data, i.e. not the searched data themselves, but their formal description. Using this approach, the classes, attributes and relations, which each play a role in the formal definition, can be filled, while literal values will likely have to be entered manually, as they are not part of the formal structural definition. A query built with the use of the formal structural definition is always syntactically and structurally correct, because it doesn't allow other constructions than those permitted by the definition. But because the real data in the database doesn't have to implement all the possible patterns allowed by the formal structural definition and the manually entered literal values don't have to exist or they may have a wrong format, it is not ensured that there will exist matching data for the query pattern in the database. In other words, although the query can be correctly formatted, in some cases, the query will not produce any data results.

Other embodiments, aspects, features, objectives and advantages of the present invention will be understood and appreciated upon a full reading of the detailed description and the claims that follow.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

Referring toFIG. 1, exemplary user interface architecture2is depicted in communication with a database4(which in some embodiments can be multiple databases) containing structural data. The user interface architecture2includes one or more interface portals6(three being shown in this example) in communication with an interface service8(software application) which can for example run either as a stand-alone application on a hosting device10or as a web-service hosted by an application server. As a general overview, each user interface portal6can be operated by a respective user11to access the interface service8and build a formulated query. The formulated query includes one or more query elements, such as a class portion, wherein the class portion is populated by designating a concrete identifier or a special identifier. The class portion can be automatically populated with a default item. Relationships between two or more query elements can be expressed using defined structural relations or defined logical relations. Further, a query element can include, in addition to a class portion, additional portions to be populated, including one or more attribute portions, and one or more literal portions. The attribute portions within a query element can be similarly interconnected using logical relations. Between an attribute and a literal there is a mathematical relation. The attribute portion and the literal portion are populated by designating a concrete identifier or a special identifier. The attribute portion and the literal portion can also be automatically populated with a default item. The formulated query can be evaluated by the interface service8, which searches the database4to produce results which can be displayed on a respective user display12of user interface portal6.

In particular, the database4contains structural data such as industrial data compiled in a structural format. Various structural formatting protocols can be used, for example, Extensible Markup Language (XML), Resource Description Framework (RDF), a Web Ontology Language (OWL) or RDF-Schema (RDFS). In at least one embodiment, the structural data uses RDF to provide classes, attributes and literals. Additionally, the structural data can have structural relationships, such as a “contains” relation, defined between the classes.

Further referring toFIG. 1, each interface portal6includes both the respective user display12and a respective user input device14. The respective user display12of each respective interface portal6is used to view one or more output screens (seeFIGS. 2-21) rendered by a client application and driven by the interface service8. Each user display12can be one of various user viewing devices, for example, a monitor, such as found associated with a desk top or laptop personal computer, or an industrial monitor, such as a PanelView or a VersaView display as manufactured by Rockwell Automation, Inc. of Milwaukee, Wis. Each user input device14is used to enter commands and enter or select query parameters and values from the output screens provided (driven) by the interface service8, and can include one of various components suitable for selecting a portion of a screen viewed on the user display12and/or entering data, for example, a mouse pointing device, a joystick, a keyboard, or a touch-screen monitor interface. In addition, in some embodiments, the user display12and user input device14can be associated with a single device, such as a personal computer, a touch-screen monitor, a PDA, or a mobile phone.

The interface service8operates to generate screen content for each respective interface portal6such that one or more formulated queries can be generated using the respective interface portal6under the direction of the respective user11. The interface service8also operates to process the formulated queries, access the database4to obtain query results, and communicates the results to the interface portal6to be displayed. The interface service8further operates to provide one or more offered lists of possible items which can be displayed on the interface portal6, and list of available actions, allowing a user to build structural queries including desired constraints and to essentially browse the structural data located on the database4, as further described below.

The hosting device10, within which the interface service8is shown to be situated, can take a variety of forms. For example, it can be a computer (or other microprocessor based controller) including a networked computer hard drive. Alternatively, the interface service8can instead be situated on a computerized device having one or more of numerous digital data storage spaces, such as a stand-alone hard-drive, a virtual hard-drive, or ROM and RAM memory. Additionally, the interface service8in the present embodiment communicates with each interface portal6via one or more interfaces13, such as a local or remote network connection, realized by a wired or a wireless network. The use of a wireless network allows a portable device such as a personal digital assistant (PDA) to serve as an interface portal6. When a Web browser is used as the interface portal6, the Web browser, or appropriate plug-in, renders the output screens and the selected query parameters are sent to the interface service8. To facilitate the rendering of the output screens, RIA (Rich Internet Applications) technologies can be used, such as Adobe Flash, Adobe Flex, Microsoft Silverlight, and Sun JavaFX. Further, the interface service8and the interface portal6can reside in a single device, such as a personal computer.

The interface service8in some embodiments uses the hosting device10to communicate with the database4(or in some cases, multiple databases). Communication between the interface service8and the database4can be facilitated by one of various communication methods, for example, a local or remote, wired or wireless network connection. Additionally, the interface service8and the interface portal6can reside on the same device as the database4.

FIGS. 2-21are various examples of output screen views that can be displayed on each exemplary user display12ofFIG. 1, and illustrate one embodiment of a method for constructing a formulated structural query. In particular,FIGS. 2-16illustrate the generation of a sample query, “Find files that contain a blinking caption,” which can be used for finding data corresponding to graphical displays on an HMI device, for example. As discussed further below, a structural query requires an object-oriented formulation (regardless of its concrete visualization form) to be expressed using the user interface12. With respect to the present sample query, it can be understood as follows. The “Find files” part of the sample query means that objects (instances) of the “File” class should be found, to be identified by the “fileName” property (attribute) of those objects. The “that contain” part of the sample query means that the “File” objects must contain the “blinking caption” component, i.e., there should be at least one object (instance) of the class “Caption”, with the property (attribute) “blink” with assigned value “true” contained within the “File” object. Correspondingly, as will be described further below,FIG. 15graphically illustrating this sample query can be understood as follows: “Find instances of type (class) “File” with property (attribute) “fileName”, show values of “fileName” (via the variable “fileName—1” which is assigned to the literal associated with the “fileName” attribute) where the “File” object contains object of type (class) “Caption”, where this object has property (attribute) “blink” with the value (literal) set to “true”.

Referring toFIG. 2, to formulate a query including one or more query elements, an initial query screen16is provided on the user display12when the interface service8is initially accessed by the user11. The initial query screen16includes a title section18, a structural query section20(“Structural query”), which usually displays the formulated query, and a query results section22(“Last results”), which displays results from the database4of a prior query processed by service8which was run by the user. At other stages of the query building process, other dialogs can be displayed, which can be contained in the mentioned dialogs, or can overlay them. In one embodiment, the different sections, such as the structural query section20and the query results section22, can be differentiated from one another, using standard textual information (caption/header), positional means, and also by using different colors on the screen.

As illustrated, because no query has yet been constructed, there are no results to display in the query result section22. Instead an information section21is displayed, which functions as a brief guide for how to get some results. The structural query section20is configured to provide various user selectable boxes or buttons, which initiate various tasks when selected. For example, a “Create-new-query” button24is provided which when selected allows a user to begin constructing a new formulated query by inputting desired search parameters, including desired concrete or special identifiers, and any structural relations between this and any additional query elements.

For example, once a user selects the “Create-new-query” button24, the structural query section20becomes modified as shown inFIG. 3. In particular, the structural query section20in screen16can provide a graphical view of the formulated query as it is being generated by the user11. A formulated query can contain one or more query elements, whose content and relations can be specified to define the query. The structural query section20initially shows an empty query element prompting for population. A query element can be populated by selecting its action-enabled area25and entering for example an “Edit” command, which can be selected from a pop-up menu (not shown). As shown inFIG. 4, a query element26is edited in a query element editing screen28, which displays the query element26in more detail and provides editing functionality.

Further with respect toFIG. 4, the query element editing screen28is provided as an overlay to the query screen16, and includes a query element section30that encloses the query element26. The query element26provides one or more query element portions to be populated which each can correspond to one or more of classes, attributes, and literals. In the particular example illustrated, the query element26initially contains a first designation area32having a selectable and action enabled “Set-class!” prompt34and a second designation area36that includes a “Set-attribute!” prompt38and a “Set-literal!” prompt40, both of which are selectable and action-enabled.

Once a user selects one of the action-enabled areas, such as the “Set-class!” prompt34, and selects for example an “Edit” option from a pop-up menu, an output screen having an offer section42is displayed, one example of which is shown inFIG. 5. The offer section42generally can provide a list43which includes possible concrete and special identifiers which can be assigned to a particular query element portion. The concrete identifiers in the list43can reflect the actual data in the structured database4and can be generated as a result of an “explorative” query which is run for this purpose. The concrete identifiers in the list43can also reflect any possible data which can be in the database4. In this case, the concrete identifiers come from the definition of the object model structure corresponding to the data stored in the database4. A stored list of the possible classes or attributes can be accessed and displayed as part of list43and the structural database4doesn't have to be queried.

In addition to the concrete identifiers which can be selected, the list43of offer section42can also include special identifiers which can be selected. These two displayed special identifiers operate as “wild-cards” in a query element portion and include a “VARIABLE” item39and an “ANY CLASS” item41for classes (or an “ANY ATTRIBUTE” item for attributes, etc.). The “ANY CLASS” item41is a substitute for all possible class identifiers and is used as a wild-card to express that the user doesn't care what the concrete identifier is for the corresponding query element class portion. The “VARIABLE” item39serves to mark the query element portion as a “place of interest”. This means that the user wants to obtain identifiers (in case of classes and attributes, or literal values in case of literals) as a query result.

As shown inFIG. 5, for example, selection of the “Set-class!” prompt34results in the displaying of the list43in the offer section42of all the specific possible classes corresponding to data in the database4which are suitable for that particular class portion of the query element26, in this case, the first designation area32. The identified classes are depicted in alphabetical order, although other organizational configurations can be used, such as organizing by domain (e.g. RSView, file, RSLogix, seeFIG. 5), database location, etc. To populate the first designation area32, the user can select one of the concrete classes identified in list43or one of the special identifiers “VARIABLE” item39or “ANY CLASS” item41. The selection can be entered in a variety of ways depending upon the embodiment including, for example, by moving a cursor to a desired item via a mouse and clicking on that item. If the user selects the “VARIABLE” item39, the user can be prompted to enter a variable name, which then serves to identify items related to that variable in the query results section. If the user selects the “ANY CLASS” item41, the formulated query will not be limited by any specific class. As shown inFIG. 5, if the user selects the specific class “File” from the offer section42, that selected class is then displayed in the first designation area32within the action enabled area corresponding to prompt34.

Further, the offer section42additionally provides an “Expand-all” button44and a “Collapse-all” button46for providing a lesser or greater organizational view of the displayed items for selection. This functionality concerns the items within the organized structure (class names, attribute names, literal values), which are displayed as a tree-view in list43. Items displayed outside the organized structure, e.g., the special values, are not affected by these buttons. By providing a list of identified classes (or attributes or literals) for the user11to preview, the user can be assured that a specific class (or attribute or literals) exists in the structured database4, and the user need not be familiar with the particular nomenclature used for data in the structured databases4. In the case of using the structure (object model) definition for query building, identifiers are displayed only for classes and attributes, which play a role in this structure, while literal values, for example strings, dates or numbers, are not displayed but have to be entered manually. In this manner, the user doesn't have to be familiar with the specific names of classes and attributes, with a hierarchical structure of the classes, and with the competence of attributes to individual classes, but has to be aware how to correctly formulate a literal value of appropriate data type, e.g. the correct format for specifying a date. Generally, providing an offered list of identifiers based on object model structure definition reduces exploratory query searches, but doesn't ensure the overall correctness of the query, but only of its structure format.

Further referring toFIG. 5, the user can further populate the formulated query by inputting items in the second designation area36. As previously discussed, the second designation area36contains the “Set-attribute!” prompt38and the “Set-literal!” prompt40. Similar to the operation of the first designation area32, the “Set-attribute!” prompt38can be selected to produce a comprehensive list of selectable concrete attribute identifiers (i.e., all the possible specific items available for attributes) in the offer section42. Also, the “Set-literal!” prompt40can be selected to produce a comprehensive list of selectable concrete literals in the offer section42.

Referring toFIG. 6, an exemplary view of the offer section42is provided in which a list45of selectable attributes is displayed, as would occur following a user's selection of an “Edit” option from for example a pop-up menu following selection of the “Set-attribute!” prompt38inFIG. 5.FIG. 6also shows the second designation area36as it would appear after the attribute “fileName” is selected from the list45in the offer section42. Alternatively, the user can select another one of the attributes of the list45or the “ANY ATTRIBUTE” item from the list, in which case the formulated query would not be further limited by any specific attribute. If the user selects the “VARIABLE” item and enters a variable name in appropriate dialog, the names of attributes of the “File” class will be displayed as results when a structural query is run. When a user selects an attribute (concrete attribute identifier or special identifier), a variable name is automatically generated for the literal associated with that attribute (i.e. value of the attribute). For example, as shown, when the attribute “fileName” is selected, the variable name “fileName—1” is provided in the second designation area36. The user can leave that variable name for the literal (it is equivalent to a user's selection of the “VARIABLE” item from literal values offer and setting “fileName—1” as variable name manually) or can select or enter a concrete value for the literal.

In addition, as discussed below, the literal value is related to the attribute identifier by a mathematical relationship, which in the illustrated embodiment is an equals relation (“=”). Once a user is finished populating the query element26, confirmation of this can be provided, such as by selecting an “OK” button50on the query element editing screen28. Completion of the query element26closes the query element editing screen28and the query element26is displayed in the query screen16as shown inFIG. 7.

Turning toFIG. 8, once a query element26has been populated in the structural query section20and it contains one or more variables, i.e. identification of places of interest in the query, values relevant to which the user wants to find in the structural database, a formulated query can be executed, for example, by selecting a “Run-query” button52. The results of the formulated query are then displayed in the query results section22. Running a formulated query with the items in the illustrated query element26produces a list of all items (in the illustrated case names of files), which are relevant for the specified variables in the query. Because there are no other constraints defined, this list displays names of all files corresponding to the data stored in the database4. This query example (containing just one query element26) is defined rather broadly, so a significant number of resultant files can be returned, although the possible query results are limited by the size and content of the database4. For other queries, the number of results can be lesser or greater in extent. Also in the present example, the query element26is populated to define desired results: namely, literal values related to the “fileName” attribute of instances of the “File” class. To further narrow the search, a user can add additional query elements in association with the query element26as discussed with reference toFIG. 9.

Referring toFIG. 9, the query element26can in at least some circumstances operate in association with one or more element connectors54(in this example, two are shown). The element connectors54are used to create structural and logical hierarchical relationships between the query element26and one or more additional query elements. One such structural relationship is a “contains” relation. For example, an element connector54extending from the top of the query element26can place the query element26in a subordinate position to another query element (or elements) on top, requiring the query element26to be contained within that top query element, whereas an element connector54extending from the bottom of the query element26can place the query element26in a superior position relative to another query element (or elements) on the bottom, requiring any such bottom query element to be contained within query element26.

To add an additional query element in association with the existing query element26, the user selects one of the element connectors54extending from the query element26. For example, selecting the lower element connector54ofFIG. 9and selecting a “Contains” option from the pop-up menu that appears in turn produces an action-enabled prompt55, as shown inFIG. 10, which corresponds to a new empty inferior query element.

Further, selecting the prompt55and picking for example an “Edit” option from its pop-up menu results in the query element editing screen28again being displayed; now containing the new query element56, as shown inFIG. 11. The designation areas of the new query element56, which are the same as those associated with the query element26(e.g., designation areas32,36), can then be filled.

In particular, as shown inFIG. 12, the first designation area32of the additional query element56is populated by selecting its corresponding prompt so as to bring up the offer section42reflecting a class list53, and then selecting the class “Caption” from the offer section42. The offer of identifiers for the edited class respects the already defined constraints in the query, so only classes that can be contained within the “File” class are offered. Again, the list53comes either from an explorative query of the database4, or it is deduced from the definition of the data object model structure.

As shown inFIG. 13, the attribute of the second designation area36of query element56is populated by selecting the corresponding prompt so as to bring up the offer section42reflecting an attribute list55, and then selecting the attribute “Blink,” from the offer section42. As discussed above, when a specific or concrete attribute identifier is selected, an associated literal variable name is automatically assigned. In the present example, the variable name “Blink—2” is assigned. If the user then selects the action-enabled area of the literal40surrounding this variable name and picks an “Edit” option from its pop-up menu, the offer section42provides a list57of concrete literal values available in the database4, as shown inFIG. 14.

The user can then select a specific literal from the items in the offered list57. For example, if the user selects “true” from the offered list57, this item is then provided as a specific literal in the second designation area36.

After the user selects the “OK” button50, the query element editing screen28closes and the structural query section20displays the updated formulated query as shown inFIG. 15. As shown, the updated formulated query graphically displayed in the structural query section20particularly includes the query elements26,56and their interrelationship. Based on the illustrated populated query elements26,56in structural query section20, the formulated query provides for all “Files” having an attribute of “fileName”, where the “File” further includes a “Caption” having an attribute of “Blink” and the literal value of the “Blink” attribute equals “true”, providing the names of such files, i.e. the literals of the “fileName” attribute. The user can run the updated formulated query by selecting the “Run-query” button52, and the query results section60displays the results of the execution of the updated formulated query, as shown inFIG. 16, wherein the results display names of files relevant for the defined variable “fileName—1” with respect to the constraints defined in the query.

As discussed above, in this example, the hierarchical position of a given query element depends on whether it is placed above or below another query element26. A user can also insert a new query element between two already existing query elements, (e.g., between query elements26,56) by selecting the element connector54situated between them. Further, as shown inFIG. 17, selecting the intermediate element connector54provides other options for defining relationships between query elements. In particular, relationships between query elements can also be represented using logical “AND” and logical “OR” operators (and possibly also other suitable operators) in addition to the structural relationship (e.g. “contains” relation) between two or more query elements. In this regard, selecting the intermediate element connector54brings up a pop-up menu64having an “AND” item66, an “OR” item68and an “Insert-intermediate-query-element” item70. When selected, the “Insert-intermediate-query-element” item70allows the user to merely insert an intermediate query element (not shown inFIG. 17) subordinated to the query element26above and superior to the query element56below. Alternatively, when a user selects “AND” item66or “OR” item68from the pop-up menu of the element connector54, a new empty query element can be created as a sibling to the original query element from whose top the element connector extends. In this case, the “AND” item66is selected, creating a new query element which is initially denoted by its action-enabled prompt72as shown inFIG. 18and which is a sibling to the query element56.

The new query element (initially denoted by “Populate!” prompt72) that is created is in a logical “AND” relationship with the query element56. This new empty query element together with query element56, is in a subordinate relationship to the query element26, and it can then be populated as desired, but with respect to the already defined constraints.

In addition to the various options for adding and interconnecting query elements, the query element portions can be interconnected using logical operators too. For example, referring toFIGS. 19A-19D, additional pairs of attributes and literals can be added to a single query element, such as the illustrated query element26. For example, when the query element26(FIG. 19A) is in the query element editing screen28, the user can select an attribute-literal pair connector74in the second designation area36to display a logical operator selection pop-up menu76that includes an “AND” item78and an “OR” item80, which represent logical “AND” and logical “OR” operators, respectively (FIG. 19B). Similar to above, other suitable logical operators, such as “XOR” (“eXclusive OR”), can also be used. Once a logical operator has been selected, such as by selecting the “AND” item78(FIG. 19C), an additional designation area, which in this example is a new empty attribute-literal pair82, displaying prompts “Set-attribute!” and “Set-literal!”, is added to the query element26for defining a second attribute-literal pair (FIG. 19D). The new attribute-literal pair82has the previously selected logical relationship (e.g. “AND”) to the already defined attribute-literal pair.

Further, as shown inFIGS. 20A-20C, a query element can include various combinations of query element portions such as multiple attribute-literal pairs82that can be combined using one or more logical operators (logical “AND” and/or logical “OR”) to define various relationships. In addition, multiple logical subordinate and superior relationships can be established among the attribute-literal pair portions82of a given query element. For example,FIG. 20Adepicts three attribute-literal pair portions82connected in a logical “AND” relationship. Also for example,FIG. 20Bdepicts two attribute-literal pair portions82in a logical “AND” relationship, where the logical “AND” relationship is in a logical “OR” relationship with still another attribute-literal pair portion82. Further for example,FIG. 20Cdepicts two attribute-literal pair portions82in a logical “OR” relationship, wherein the logical “OR” relationship is in a logical “AND” relationship with yet another attribute-literal pair portion82.

In addition to providing numerous combinations of attribute-literal pair portions82, the attribute-literal pair portions82themselves can be further modified. As seen inFIG. 21, the attribute-literal pair portion82includes a mathematical operator84that defines the relationship between the attribute item and the literal item. As shown, a default mathematical operator such as equals (“=”) is often used. However, in at least some embodiments, the default operator can be replaced by another mathematical operator, for example, “≠”, “<”, “>”, “≦”, “≧”, etc. In some such embodiments, to achieve such replacements, the query element editing screen28includes an operator bar86having various mathematical operators buttons85to select (depending on data type of values relevant to the appropriate attribute). When editing the literal of the attribute-literal pair portion82, a user is able to select a desired mathematical operator button85from the operator bar86to replace the current equals sign (or other default or previously selected operator). Additionally, the operator bar86can include still other options, for example an “Interval” button88that allows the user to specify an interval of allowed values for the appropriate literal. Depending on the data type of the values, it is also possible to use for example a “One-of-a-set” operator, or a “None-of-a-set” operator, which can replace a series of attribute-literal pairs connected with one or more “OR” operators, or one or more “AND” operators in a more effective way. Another possibility, suitable for string values, is a “Substring” operator, defining that the values of the appropriate attribute (the literals relevant to it) have to contain such substring.

In this manner, the user interface can be used to generate a formulated query by populating one or more query elements and arranging multiple query elements in various forms indicating desired hierarchical structural and logical relationships. Further, each query element can include a populated class and can contain one or more populated attribute-literal pairs, wherein the attribute-literal pairs can also be arranged in various forms indicating desired logical hierarchical relationships. Thus, a variety of simple or complex queries can be easily formulated, which in turn can be used to obtain desired search results.

It is specifically intended that the present invention not be limited to the embodiments and illustrations contained herein, but include modified forms of those embodiments including portions of the embodiments and combinations of elements of different embodiments as come within the scope of the following claims. In particular, the visualization form, implementation technology, interaction and organization model of client-server communication as well as user interaction techniques can differ between various embodiments. Visualization forms can be graphical as well as textual. As described above, the visual form of the structural query may be graphical and resemble UML (Unified Modeling Language) object diagrams, but is not limited to this form. A UML-like form is able to express query elements (e.g. as rectangles), their content (e.g. classes and possibly one attribute-literal pair or a logical hierarchical structure of more attribute-literal pairs), and relations (e.g. as lines connecting query elements). But the structural query can be expressed and constructed in other suitable ways, for example also as structured text or even pseudo-natural text, still using the described methods of query construction and populating of query elements.

Besides a complex editor allowing construction and definition of all the above described segments of the structural query, and providing possibly also some other options like working with data types or filtering of values offered to the user, there can still (co)exist a simplified editor, not capable of constructing and defining a full featured query, but providing a simplified functionality and operation. Such an editor could be used to construct simple queries or to fill query elements which don't need to specify a complex attribute-literal structure. It can be a complement to the complex editor.

To reduce the amount of work related to query creation, a user can save a part of an already defined structural query and later use it as a base of a new query, or append it to an already constructed query.