Creating an innovative mediator environment such as graphical user interfaces, lighter weight languages to help the users in the challenging task of making unambiguous requests is crucial in semantic web applications. The query language in the Virtual Query System (VQS) of the SemanticLIFE framework is designed for this purpose. The proposed query language namely Virtual Query Language (VQL) is in a further e®ort of reducing complexity in query making from the user-side, as well as, simplifying the communication for components of the SemanticLIFE system with the VQS, and increasing the portability of the system.
VQL is a much lighter weight language than RDF query languages; but it o®ers interesting features to complete the tasks of information querying in the Semantic Web applications.
The rest of this paper is organized as follows: ¯rstly, similar approaches is brie°y presented in Section 2. Next, details of the VQL are pointed out in Section 3. Section 4 introduces VQL query operators; and the issues of mapping a VQL query to the respective RDF query are then described in Section 5. Finally, the paper is concluded with a sketch of the future work. 2
There are two main approaches to reduce the di±culty in creating queries from
user-side in Semantic Web applications. The ¯rst trend is going to design the
friendly and interactive query user interfaces to guide users in making the queries.
The high-pro¯led examples for this trend are GRQL [
GRQL - Graphical RQL - relies on the full power of the RDF/S data model
for constructing on the °y queries expressed in RQL [
Another graphical query generation interface, SEWASIE, is described in [
The second approach of reducing complexity is the e®ort in creating much
lighter query languages than expressive RDF query languages. Following this
trend, the approach in [
[
Meanwhile, the approach of GetData Query interface [
Our approach, VQL, continues this trend to design an e®ective and lighter weight query language to assist the users make queries in simple manner and simplify the communication between components of the SemanticLIFE system with the query module - the VQS. 3 3.1
A number query languages have been developed for the Semantic Web data such
as data in form of RDF (RQL [
These query languages all provide very expressive mechanisms that are aimed at making it easy to express complex queries. Unfortunately, with such expressive query languages, it is not easy to construct queries to normal users as well as to ask abstract information. What we need is a much lighter weight query language that is easier to use. A simple lightweight query system would be complementary to more complete query languages mentioned above. VQL is intended to be a simple query language which supports \semantic" manner from users' queries. In the context of the VQS and SemanticLIFE system, we can see the aims of VQL as follows:
- VQL helps clients making queries without knowledge of RDF query languages. The user just gives basic parameters of needed information in VQL queries, and would receive the expecting results.
- VQL assists users in navigating the system via semantic links or associations provided in the powerful query operators based on ontologies.
- VQL simpli¯es the communication between Query module and other parts. Since the components asking for information do not need to issues the RDF query statement, which is uneasy task for them. As well as this feature keeps the SemanticLIFE's components more independent.
- VQL enables the portability of the system. Actually, the SemanticLIFE and VQS choose a speci¯c RDF query language for the its back-end database. However, in the future, they probably could be shifted to another query language, so that this change does not e®ect other parts of the systems, especially the interface of the system database. 3.2
Query Document Syntax. Generally, a VQL query is a document having four parts: parameters, data sources, constraints, and query results format as the schema depicted in Fig. 1.
The ¯rst part contains parameters of specifying the information of interest. A parameter consists of a variable name, the criteria value, and additional attributes for sorting or eliminating unneeded information from the results. The second part is used for specifying the sources where the information will be referred to extract from. Obviously, the information need de¯ned in the ¯rst part must be related to the sources speci¯ed in this part.
Thirdly, the constraints of the query are de¯ned in the third part of the document. Here the relations between sources, parameters are combined using the VQL operators. Finally, the format of query results is identi¯ed in the fourth part. VQL supports four query results formats that are XML, text, RDF graph, and serialized objects of query result sets. This provides °exibility for clients to process the query results.
XML-based Format. A standard format for information exchange, a easyto-use and familiar-to-clients format, a widely accepted standard, and a °exible and open format are the requirements for the VQL query document. We have considered some alternatives and decided to choose XML as the format for VQL query syntax. A XML-based VQL query is structured as follow (Fig. 2): - The top level or the body of query is <query> element. Here, the type of the query must be speci¯ed in type attribute. The reserved terms used for this attribute are "data", "schema", "itql1" and "itql2" for di®erent VQL query types (see section 3.4). For example, <query type="data"> is a VQL data query. - The second level contains required sub-elements. Depending on the type of a VQL query the elements are used respectively: for the data query, elements of
Fig. 2. An XML-based VQL Query Example <params>, <sources>, and <relations> are used once for each. These elements have their children speci¯ed in the third level. Fig. 2 is an example. For the schema query or the iTQL type 1 query, we use only one <statement> element which contains a RDF query statement (Fig. 3). For the iTQL2 query, elements of <select>, <from>, <where>, <orderby>, <limit> and <offset> are used in the same way, where last three are optional as described in Fig. 4. Moreover at this level, we must identify the query results format in the <resultformat> element by a term among "xml", "text", "rdf", or "object". - The third level elements are only applied for the VQL data queries. The elements are children of <params>, <sources>, and <relations>; and the tags consequently are <param>, <source>, and <relation> with their own attributes.
- <param> element : each parameter is identi¯ed by this element with required attributes: show and name. While show is set to 1 or 0 that means the result of this parameter is shown in the result sets or not; name has two parts: a variable and the meta ¡ inf ormation which are put together with ":", i.e. variable:metainfo. Besides, this element has two optional attributes known as order="1"/"0" and exclude="string". The order attribute is used for sorting, while exclude is for excluding some information from query results. The element is enclosed with an optional value for ¯ltering.
- <source> element : names of concerned sources for users' requests will be put here. This element has only one attribute name which is an internal name of data sources. This internal name is assigned automatically by the system.
- <relation> element : contains a constraint of the VQL query. The required attributes of each constraint are: id=\number", param=\variable", source=\sourcename", and optional or=\id". The id is assigned a number, variable in the related <param> is used in this param attribute. Attribute source is identi¯ed with source ¡ name or left empty in the case of only one data source speci¯ed; and or is assigned by id of another <relation> in order to make an OR expression.
The operator for the constraint is put as value of the <relation> element.
Logic Operators. VQL's logic operators consist of AND, OR and NOT. While NOT is de¯ned in each <param> element by using the exclude attribute, AND and OR operators are identi¯ed in <relation> items. OR is de¯ned by the "or" attribute, e.g. or="2" means that the current constraint will be combined with the constraint number \2" using logic OR operator. AND is implied in a relation without "or" attribute.
Comparison Operators. The comparison operators are used in <relation> part of VQL queries. These operators are presented as follow: equal An equal comparison in form of triples which is used by leaving the <relation> item empty. gt The operator means GREATER-THAN which is used for comparing values of basic data types such as String, numbers. lt Similarly to the previous one, the operator means LESS-THAN. dt:gt This operator is used for comparing the date/time value AFTER a point of time. Value format of this type confronts XML Schema (XSD) data types. dt:lt Similarly to the dt:lt operator; but it means for the date/time value
BEFORE a point of time. str:match This is the pattern matching operator for strings. This comparison operator uses common pattern expression. ft:match This is the powerful operator relying the full-text index applied in SemanticLIFE's metastore. It is used for searching the full-text data such as content of a ¯le or email attachments, or stored WWW pages.
Expressions. In order to formulate the expressions for the query criteria, VQL uses "or" attribute in <relation> elements as boolean OR operator to combine these constraints ¯rst, and then it uses boolean AND to combine into the ¯nal expression. The sequence of <relation> elements are important in combining expressions. 3.4
Data Query Type. VQL data query type is commonly used for information querying. A query of this type consists of the four parts as discussed above. In order to inform VQL parser to process the query as a VQL data query, we identify "data" term in the query: <query type="data">.
An example for this query type is shown in Fig. 2: the query retrieves messages' time-stamp of ¯les uploaded and browsed web pages in the SemanticLIFE repository in November 2005.
From this query type, we obtain deductive queries for special operations in semantically information retrieval. These operations help users easily get information of interest and obey the principle of VQL design: \ask less, get more." The deductive queries, so-called VQL query operators, are detailed in Section 4. Schema Query Type. The syntax of this query type consists of two parts: the ¯rst one is the <statement> element containing a RDF query statement; and the second part is used to set the query results format. Necessarily, "schema" must be identi¯ed in the query body. A schema query example is illustrated in Fig. 3.
However, the question is that how does the user create RDF query
statements? Actually, the schema or ontology queries are o®ered to clients in form
query templates or programmatic VQL API.
iTQL Query Types. Similarly, with `iTQL query types' RDF query statements
are wrapped in VQL query documents. The name of `iTQL query type' comes
from the RDF query language used in the system. Since the SemanticLIFE
framework uses Kowari [
The format of the ¯rst iTQL query type, so-called VQL iTQL query type 1, is similar to the schema query depicted Fig. 3, where the term "itql1" is used instead of "schema" in the <query> tag. Meanwhile, in VQL iTQL query type 2, each parts of RDF query statement, such as select and from, are put in respective query parts. With the iTQL's SELECT statement, its parts are: select, from, where, orderby, limit, and offset.
Fig. 4 is an example of VQL iTQL query of type 2, in which "itql2" is speci¯ed in <query> tag. As depicted in the ¯gure, the expressions of clauses of the RDF query statement are ¯lled in respective elements of the VQL query.
In order to increase the °exibility in query results processing, VQL provides four query results formats that are XML format, text format, RDF graph, and serialized query results. In a VQL query, we identify the query results format in the <resultformat> element at the second level.
Query Results XML Format: <resultformat>xml</resultformat>
VQL query results XML format is similar to a W3C's format for SPARQL
query results presented in [
Query Results Text Format: <resultformat>text</resultformat> The text format of VQL query results is structured as following: the variable and its value of each item are then paired in form of VAR_NAME = VALUE. These pairs are connected by semicolons, and one row is for each items.
Query Results RDF Format: <resultformat>rdf</resultformat> The RDF-graph format of query results is designed for semantic web client applications, here they prefer semantic enriched data. The query results will be transformed to RDF graphs before returning them to the clients.
Serialized Query Results Object: <resultformat>object</resultformat> Concerning with the inside components communication in the SemanticLIFE system, components sometimes would like to use query results object without format transformation. The VQL serializes the results and send the serialized objects back to the asking component. 4
In this section, we present deductive queries for special operations in making
complex queries in simpler manner which helps users \ask less, get more." This
is the principle of building user-centered applications [
GetInstances operator is the common form of VQL data queries. The operator retrieves appropriate information according the criteria described in parameters, sources, constraints of the query. The properties with show attribute set to "1" will be involved in the query results.
Fig. 2 is an example of GetInstances operator. As depicted, the query is about retrieving the message's time-stamp from 01/11/2005 to 30/11/2005 of uploaded ¯les and browsed WWW pages. The operators in the constraint part, "dt:gt" and "dt:lt", are combined using boolean `AND'. 4.2
This query operator assists the user easily retrieve all metadata properties and their values of resulting instances. This query operator is very useful when the user does not care or not know exactly what properties of data instances are. The case could happen when he/she makes request; or he/she would like to get all metadata of these data items by the simplest way.
In order to make a GetInstanceMetadata operator, we must put one parameter in the query document with the reserved string "METADATA". The other parameters could be used for the criteria of the query to ¯lter the query results. The rest of the query document is similar to a normal data query. Fig. 5 describes a example of this operator.
Fig. 5. VQL GetInstanceMetadata Query Operator.
Here, the query is about getting the metadata and their values of uploaded ¯les which are sent from 01/11/2005, as well as the timestamps of these ¯les. 4.3
In semantic web applications, particularly in the SemanticLIFE system, ¯nding relevant or associated information plays an important role. When we make a query to search for a speci¯c piece of information, we also would like to see associated information to what we found. For example, when we are looking for an email message with a given email address, we also want to see the linked data to this email such as the contact having this email address, appointments of the person in the email, web pages browsed by this person. Obviously, this operator shows the VQL power and obeys the principle of \ask less, get more" for users.
In order to make a request of this operator, we must identify a parameter containing the a reserved word "RELATED-WITH" in the query document. The <sources> element is used to limit a range of data sources in searching associated information as presented in following ¯gure (Fig. 6).
In this example, the query asks for instances of Email data source containing a speci¯c email address, e.g. hta@gmx.at; and from found messages, the related information in the appreciate data sources, which are identi¯ed in <sources> of the query, will be located as well.
Fig. 6. VQL GetRelatedData Query Operator. 4.4
This query operator operates by using the system's ontology and RDF graph pattern traversal. The operator aims at ¯nding out the associations/links between instances and objects. For instance, we are querying for a set of instances of emails, contacts and appointments, and normally, we receive these data separately. However, what we are expecting here is that the links between instances (as well as objects) provided additionally. The links are probably properties of email addresses, name of the persons, locations, and so on.
GetLinks operator helps us to ful¯ll this expectation. This operator is similar to GetInstanceM etadata in the way of exploiting the metastore. While GetInstanceM etadata operator tries to get related instances based on analysis of a given link or information and the ontologies, GetLinks extracts the associations in instances or objects. In order to make a GetLinks operator, the reserved word "SLINKS" (semantic links ) must be identi¯ed in one <param> element.
We distinguish the detecting links between instances and objects as following: if sources are speci¯ed in the query document without any parameters except "SLINKS", then the links will be detected between objects. Otherwise, if some parameters are shown, the links are implied for instances' associations. An example of GetLinks query operator is described in Fig. 7. The query will return the associations between instances having the given receiver's email and the contact name in three data sources Email, Contact, and Calendar.
By providing these operators, VQL o®ers a powerful feature of navigating the system by browsing data source by data source, instances by instances based on found semantic associations. 4.5
The SemanticLIFE system covers a large range of data sources, from personal data such as contacts, appointments, emails to ¯les stored in his/her computer, e.g. the o±ce documents, PDF ¯les, media ¯les. Therefore, a query operator to get the contents of these ¯les is very necessary.
Fig. 8. VQL GetFileContent Query Operator.
Normally, to carry out this task, we must de¯ne two parameters in the query document, the ¯rst one is the ¯le path got from the previous query; and the second one is de¯ned with reserved word "CONTENT". In the <source> element of the query, a data source is identi¯ed as a reference; and the constraint part is often left empty. The query is described in Fig. 8 is an example of GetF ileContent operator, where a content of the ¯le having name "CFP_WISM_06.pdf" with its full path will be extracted from the metastore. 5
The VQL parser translates the VQL query to correspondent RDF query
statements; accesses the metastore to get results, then transforms them to the
appreciate format and sends the processed results back to the user. In this section, we
present the ¯rst stage of a query process in the VQS [
Expressions in VQL queries are likely to be mathematical ones, while the \expressions" in RDF queries are in form of the triples. Therefore, an accurate expression mapping from normal expressions in VQL queries to triple expressions in RDF queries is crucial. VQL carries out this task as following steps: 1. Forming mathematical expressions from elements of a VQL query. 2. Representing the ¯nal aggregated expression into an expression tree. 3. From the expression tree, we traverse and formulate triple expressions for
RDF query with referring to ontologies and related sources in the VQL query. Example: Looking back at Fig. 2 as an example, an expression will be formed from described query's parts as follows (here msgT S is used instead of messageT imeStamp for shorter representation):
(msgT S ¸ #01=11=2005#) \ (msgT S · #30=11=2005#) From this expression, we can create the expression tree as depicted in Fig. 9.
Using this tree, we generate the triple expressions for the RDF query by traversing the tree. The generated triple expressions are described below in iTQL RDF query language: (<slife:msgTS> <tucana:after> '2005-11-01T00:00:00Z') and (<slife:msgTS> <tucana:before> '2005-11-30T00:00:00Z') where, "slife" is the namespace for the ontology and data schema of SemanticLIFE metastore; and <tucana:after> and <tucana:before> are comparison operators of iTQL.
Furthermore, the data sources are taken into account during mapping expressions. The speci¯ed data sources in the VQL query document (in sources part and <relation> elements) are used for either identifying the expression applied on them or generating correspondent queries for them. Hence from a VQL query, more than one RDF query are probably generated. 5.2
Syntax mapping takes care the issue of translating from VQL query syntax to a RDF query language syntax. VQL queries are actually interpreted as SELECT statements of RDF query languages. The iTQL's SELECT statement contains three required clauses select, from, where, and optional clauses such as orderby, and exclude. The syntax mapping will parse VQL query's parts to the clauses of RDF SELECT statement(s).
First of all, the select clause of the RDF query will be ¯lled by <params> parts of the VQL query. The parameters set to "1" will be put as variables of the select clause, and unshown parameters (set to "0") are used for forming the criteria only. Additionally, some extra variables will be added in the clause to get the message's URI and the name of data sources. Secondly, the from clause will be generated automatically by VQL parser. For the time being, all data sources are stored in one huge metastore with a unique network address. And this network address plugged access protocol will be placed in from clause. Thirdly, generated triple expressions will be used for the where clause. As discussed, the process of generating the triple expression combines all three parts of the VQL query - params, sources, and relations - along a further analysis by adding more expressions to clarify the criteria.
Last but not least, we have two optional attributes, order and exclude, for each parameter. If the order is set to "1", then the variable will be added into orderby clause. And if an exclude is speci¯ed, an expression in form of exclude($param $op $exclstr) will be added into the where clause. 5.3
The semantic mapping takes part in both mapping tasks above to resolve semantic ambiguity problems. This is the vital and decisive mapping task of the VQL. The semantic mapping is going to solve the following concerns during query generating process from the user's initial VQL query: { Disambiguating query items { Resolving semantic con°icts Disambiguating query items. The inaccuracy of a query is mainly due to the ambiguities inside itself. Coping with ambiguous items in the VQL query made by a user is a decisive step in parsing it later on. Here the ambiguity could be in terminological manner, i.e. requested data properties are not clear. For example, a "Name" property in a query is ambiguous because the query parser can not identify which \name" will be extracted, contact name or name of email sender/receiver.
Clarifying these properties could be done by using data source speci¯ed in the query and the ontologies of the system. Based on the data sources, the appreciate properties in the ontology will be detected and used instead of ambiguous items.
For instance, concerning the "Name" property is described above, this mapping task must rely on the related source described either in source or constraints elements, e.g. Contact; after on, based on ontologies, appreciate properties will be located such as contactFirstName, contactLastName.
Resolving semantic con°icts. In a further disambiguation users' queries, especially when the user asks for information using an ambiguous entity over many data sources. The issue is that how to identify user's \intended" properties for which data sources. For example, "Name" property is constrained with Email and Contact. If the "Name" properties is constrained with a source identi¯ed in a <relation> element, then the issue is similar to the discussion above. Otherwise, the query has to: { get all related properties in system ontology based on speci¯ed data sources.
In this case, there are probably more than one query generated; or { suggest the most related properties from ontology based on a semantic similarity of properties in the same query. For instance, if other properties are major requesting for Contact items, so that the \names" of Contact object would be suggested.
The semantic mapping is applied for all types of the VQL query. Generally, all user-entered queries should be check for implied semantic problems as well as the syntax of them. 6
In this paper we have presented the Virtual Query Language, a design of a query language aiming at a signi¯cant complexity reduction in formulating semantic meaningful queries.
As the next steps of VQL, the issues of improving by considering RDF as the alternative format for VQL, and building a graphical interface on top of this language will be discussed consequently in the details. We see the advantages of the RDF as standard for the Semantic Web applications, so that coding the VQL in RDF as `RDF forms' would be considered. As well as, a powerful interface for VQL in context of the VQS will be taken into account.