process is then a browsing experience in which the user looks for information resources that he/she eady knows and which are somehow related to the target, and from there locates additional information on the target resource until it can be found Fig. 1. A phase of GRDL III. QUERY FORMULATION semi-structured data provide expressive mechanisms that are aimed at Many kinds of complex queries can be formulated express complex queries;however as a problem of finding a group of objects of certain a lot of computational resources to process. The idea types which are connected by certain relationships. In of GetData is to design a simple query interface which the Semantic Web, this translates to graph patterns enables to network accessible data presented as with constrained object node and property arc types. directed labelled graph. This approach provides a An example would be"Find all papers published in system which is very easy to build, support both type IEEE proceedings from 2000 to 2003 about of users, data providers and data consumers ontology-based query, cited by recent publications The multi-facet search portals mentioned earlier in 2005,where"publications ,"IEEE proceedings", can also be regarded of as user interfaces for creating years are ontological class restrictions on nodes and a very constrained subset of complex graph patterns published in,"cited by", and"time restriction are While in the simple case the query is formulated the required connecting arcs in the pattern. While searching for an information such patterns are easy to formalise to query in the properties, in a wider sense the definitions of how the context of the semantic web, they remain problematic objects map to the views can be arbitrarily complex because they are not easy to formulate for the users. and involve graph navigation, as for example where Therefore, a number of approaches of the research items are not directly annotated to particular event into complex queries have been developed on the types, but the link is drawn from a combination of level of user interfaces for creating such query item type and material, for example patterns as intuitively as possible In an effort of this approach, [20] presents GRQL,a graphical user interface for building graph pattern IV. QUERY REFINEMENT queries that is based on navigating ontology. Firstly, a A. Query Ambiguity Discovering class in the ontology is selected as a starting point. All In the early approach, word sense disambiguation properties defined as applicable to the class in the of the terms in the input query and words in the ontology are then given for expansion. Clicking on a document has shown to be useful for improving both property expands the graph pattern to contain that precision and recall of an information retrieval property,and moves selection to the range class system. In the approaches of [1], [2] and[3],lexical defined for that property, e.g. clicking the "creates relations from WordNet are used for query expansion, an Artist class creates the pattern but without treating the query ambiguity expansion, Artist→ creates→ Artifact 5] focus to the Artifact class, showing the properties query ambiguity in two factors: the structure of the for that class for further path expansion. In addition to query and the content of the knowledge repository lengthening the path, other operations can be Regarding ambiguities in the query structure, there are performed on the query pattern. The pattern can be two issues are defined: structural ambiguity in which tightened to concern only some subclasses of a class, the structure of a user's query is analysed regarding as by tightening Artifact to "Painting of Sculptures"in the underl the underlying ontology, and semantic am the previous example toArtist-creates, second factor is the content of the /ledge Painting or Sculpture". In a similar way, repository. The ambiguity of a query property restriction definitions can be tightened into knowledge repository is repository-dependent. To subproperties. More complex queries can be overcome, [ 15] introduces a 'response factor'for formulated by visiting a node created earlier and taking the specificities of knowledge repository branching the expression there, creating patterns such content in determining the ambiguity of a query. This as the one visually depicted in Fig. I factor of a query is the measure to know how the In a further effort of reducing the complexity of terms from that query cluster the resources in the query formulation, the approach of "Semantic Search" underlying knowledge repository nterface, namely Get Data[41, expresses the need of a In recent activities, another approach for dealing much lighter weight interface for constructing with query ambiguity is presented in [17]. In this complex queries. The reason is that the current query process, firstly, potential ambiguities of the initial languages for RDF, DAML, and more generally for query are discovered and assessed (Ambiguityprocess is then a browsing experience in which the user looks for information resources that he/she already knows and which are somehow related to the target, and from there locates additional information on the target resource until it can be found. Fig. 1. A phase of GRDL III. QUERY FORMULATION Many kinds of complex queries can be formulated as a problem of finding a group of objects of certain types which are connected by certain relationships. In the Semantic Web, this translates to graph patterns with constrained object node and property arc types. An example would be “Find all papers published in IEEE proceedings from 2000 to 2003 about ‘ontology-based query’, cited by recent publications in 2005,” where “publications”, “IEEE proceedings”, years are ontological class restrictions on nodes and “published in”, “cited by”, and “time restriction” are the required connecting arcs in the pattern. While such patterns are easy to formalise to query in the context of the semantic web, they remain problematic because they are not easy to formulate for the users. Therefore, a number of approaches of the research into complex queries have been developed on the level of user interfaces for creating such query patterns as intuitively as possible. In an effort of this approach, [20] presents GRQL, a graphical user interface for building graph pattern queries that is based on navigating ontology. Firstly, a class in the ontology is selected as a starting point. All properties defined as applicable to the class in the ontology are then given for expansion. Clicking on a property expands the graph pattern to contain that property, and moves selection to the range class defined for that property, e.g. clicking the “creates property” in an Artist class creates the pattern “Artist→creates→Artifact”, and moves the focus to the Artifact class, showing the properties for that class for further path expansion. In addition to lengthening the path, other operations can be performed on the query pattern. The pattern can be tightened to concern only some subclasses of a class, as by tightening Artifact to “Painting of Sculptures” in the previous example to “Artist→creates→ Painting or Sculpture”. In a similar way, property restriction definitions can be tightened into subproperties. More complex queries can be formulated by visiting a node created earlier and branching the expression there, creating patterns such as the one visually depicted in Fig. 1. In a further effort of reducing the complexity of query formulation, the approach of “Semantic Search” interface, namely GetData [4], expresses the need of a much lighter weight interface for constructing complex queries. The reason is that the current query languages for RDF, DAML, and more generally for semi-structured data provide very expressive mechanisms that are aimed at making it easy to express complex queries; however, the queries require a lot of computational resources to process. The idea of GetData is to design a simple query interface which enables to network accessible data presented as directed labelled graph. This approach provides a system which is very easy to build, support both type of users, data providers and data consumers. The multi-facet search portals mentioned earlier can also be regarded of as user interfaces for creating a very constrained subset of complex graph patterns. While in the simple case the query is formulated as searching for an information with particular properties, in a wider sense the definitions of how the objects map to the views can be arbitrarily complex and involve graph navigation, as for example where items are not directly annotated to particular event types, but the link is drawn from a combination of item type and material, for example. IV. QUERY REFINEMENT A. Query Ambiguity Discovering In the early approach, word sense disambiguation of the terms in the input query and words in the document has shown to be useful for improving both precision and recall of an information retrieval system. In the approaches of [1], [2] and [3], lexical relations from WordNet are used for query expansion, but without treating the query ambiguity. Meanwhile, the approach in [15] examines the query ambiguity in two factors: the structure of the query and the content of the knowledge repository. Regarding ambiguities in the query structure, there are two issues are defined: structural ambiguity in which the structure of a user’s query is analysed regarding the underlying ontology; and semantic ambiguity. The second factor is the content of the knowledge repository. The ambiguity of a query posted in a knowledge repository is repository-dependent. To overcome, [15] introduces a ‘response factor’ for taking the specificities of knowledge repository content in determining the ambiguity of a query. This factor of a query is the measure to know how the terms from that query cluster the resources in the underlying knowledge repository. In recent activities, another approach for dealing with query ambiguity is presented in [17]. In this process, firstly, potential ambiguities of the initial query are discovered and assessed (Ambiguity- 3