4.4 A Unified Querying Formalism for Semantic Web Services
4.4.2 From an Abstract Query Model to SWS2QL
this section (e.g., a descending or ascending order of the results with respect to some attribute of the result set).
Besides the result set modifiers, the attributes which should be contained within the result set are also defined (e.g., the name of the service or the provider name). One of these attributes can also be used as sorting criterion by specifying its ID as the value of anorderByattribute. The abstract query model is defined using an XSD document, which is presented in Appendix D.2.
Listing 4.1:Example SWS2QL Query (Excerpt)
1 SELECT ? service 2 WHERE {
3 ? table aqm : table DEFAULT . 4 GRAPH ? table {
5 ? service rdf : type atsm : service .
6 ? service atsm : hasname ’’ weather forecast ’’ .
7 } ...
Within the query sections of SWS2QL queries, the properties of the components of the desired service are specified in terms of RDF triples. An excerpt of a simple, table-based SWS2QL query is shown in Listing 4.1. Prefix definitions are skipped for ease of reading. In order to permit imprecise matching and to integrate similarity thresholds into an SWS2QL query, a specific extension function is introduced, which can be used within SPARQL FILTER expressions. Generally, the opportunity to make use of extension functions is inherently provided by the SPARQL grammar and has also been proposed by Kiefer et al.
[125] for the integration of imprecise matching capabilities into SPARQL (cp. Section 4.5).
Listing 4.2:Extension Function for Determining DoM Values in SWS2QL
xsd : boolean sws2ql : dom ( IRI offURL , IRI reqURL , simple literal dom )
In SWS2QL, the extension function for the integration of semantic references is defined as shown in Listing 4.2. Basically, this function takes into account two URLs and a DoM value, which can either be text-based or numerical. Depending on the type of matchmaker associated with the surrounding query section of the extension function, the semantics of the URLs change. In case of a lightservice query, the URLs represent semantic references pointing to OWL DL-based concepts of a specific component within the service offer and the service request. Both are to be compared with the specified DoM value in mind.
If the extension function is specified within a fullservice query section, the URLs refer to the access URIs of the service offer and the query by example service and are used by a fullservice matchmaker to identify two services. In general, the DoM value can either be one of the predefined DoM constants or a numerical representation of the requested degree of similarity.
In detail, the first argument of the extension function is given by the respective variable of an RDF triple, which is matched against all service offers, and the second argument is specified by the service requester in order to state the desired OWL DL-based concept for a specific property or to reference the example service to retrieve similar services.
Based on the different threshold values, a matchmaker is able to determine the matching services for a specific query section. Although, weights could be introduced for the several parts of a service within a single query section, this would raise the modeling effort and complexity. Thus, the computation of a total similarity value for the services resulting from a single query section is left to the respective matchmaker within SWS2QL. However, a service requester must have means to obtain the total similarity value of a specific query section in order to specify global similarity thresholds. As already stated by Kiefer et al.
[125], the application of extension functions does not permit to assign similarity scores to variables, so that similarity values cannot be reused within other query statements, e.g., for the weighted aggregation of the results. However, assigning similarity values to variables can be achieved within SWS2QL through the application of theGRAPHkeyword.
Listing 4.3:Property Function to Retrieve Total Similarity Scores in SWS2QL
Var1 sws2ql : sim ( IRI graph )
In order to obtain the total similarity value from a matchmaker, the virtual triple approach as proposed by Kiefer et al. [125] is used (cp. Section 4.5). In doing so, the property function depicted in Listing 4.3 is introduced. This function takes into account one argument, the object value of the RDF triple, repre-senting the IRI of the graph assigned to a specific query section. The global similarity value computed by the matchmaker associated with the query section is then returned by the function and assigned to
the subject variable. For the weighted aggregation of the results of all query sections, a similar property function to the one proposed by Kiefer et al. could be used. However, as already mentioned, SWS2QL is restricted to at most one conjunction of a semantic-based query type and a syntactic query type.
Listing 4.4:Extension Function for the Definition of Global Thresholds in SWS2QL
xsd : boolean sws2ql : thold ( Var1 sim , simple literal thold )
In addition, it is assumed that no fuzzy keyword-based search is performed, i.e., no text-based similarity measures are applied. Nevertheless, a standardFILTERfunction provided by SPARQL can be applied to perform a substring matching. In doing so, the corresponding parameter value of a service offer only has to contain the specified keyword, i.e., the keyword can be part of a larger string, but the parameter value does not have to match the keyword exactly. Since no fuzzy keyword-search is contained within the query, no aggregation function has to be applied for the results of the semantic-based query section and the keyword-based query section. Instead, a service offer must contain the parameters defined in the keyword-based query section and, at the same time, adhere to the arguments and their given threshold values specified within the semantic-based query section. Nevertheless, to be able to specify a global similarity threshold for the total similarity value resulting from a semantic-based query section, a service requester can make use of the new extension function depicted in Listing 4.4. The function takes into account a variable holding the total similarity score of a specific query section and a numerical or text-based value specifying the requested minimum degree of similarity. All services with a total similarity at least as high as the similarity threshold are returned to the service requester.
Listing 4.5:SWS2QL Query (Example)
1 SELECT ? service
2 WHERE {
3
? lightservice aqm : lightservice MM2 .
4 GRAPH ? lightservice {
5
? service rdf : type atsm : service .
6
? service atsm : hasInterface ? interface .
7
? interface atsm : hasOperation ? operation .
8
? operation atsm : hasInput ? input .
9
? operation atsm : hasOutput ? output .
10
? input atsm : hasParameter ? inconcept .
11
? output atsm : hasParameter ? outconcept .
12 FILTER( sws2ql : dom (? inconcept ,
13
’’ http :// www . example . com / geography . owl# location ’’, ’’SUB ’ ’))
14 FILTER( sws2ql : dom (? outconcept ,
15
’’ http :// www . example . com / weather . owl# temperature ’’, ’’EXACT ’ ’))
16 } .
17
? table aqm : table DEFAULT .
18 GRAPH ? table {
19
? service rdf : type atsm : service .
20
? service atsm : hasInterface ? interface .
21
? interface atsm : hasOperation ? operation .
22
? operation atsm : hasName ? opname .
23 FILTER regex(? opname , ’’ forecast ’’)
24 } .
25
? similarity sws2ql : sim (? lightservice )
26 FILTER( sws2ql : thold (? similarity , ’’0.5 ’’))
27 }
28 ORDER BY DESC ? similarity
29 LIMIT 20
Listing 4.5 shows an example SWS2QL query. This example combines a lightservice query (Lines 3–
16) with a table-based query (Lines 17–24). Regarding the former, Line 3 defines the named graph as described above. In this example, a named graph “lightservice” is defined and the matchmaker MM2 is applied to it. The query statement itself (Lines 5–11) follows the ATSM specification as pre-sented in Appendix A.1.3. In Lines 12–15, two filters are applied which define the parameter con-straints as presented in Listing 4.2. In this example, the service offer’s input parameter needs to reference “http://www.example.com/geography.owl#location” or be one of its subconcepts (indi-cated by the DoM “SUB”). Accordingly, the service offer’s output parameter needs to reference “http:
//www.example.com/weather.owl#temperature”, as the corresponding DoM is “EXACT”. In this
exam-ple, we make use of the subsumption relationships from Section 3.2.1 and the matchmakerMM2. However, the filter could also specify a numerical value – in this case, another matchmaker would have to be ap-plied.
The table-based query statement is also defined by specifying an accordingly named graph (Line 17).
Here, the filter (Line 23) makes use of the standardregexregular expression which defines that the given argument (here: “forecast”) needs to be contained in the parameter’s textual description (here: name of the operation) [215].
The property function in Line 25 is used to retain the total similarity value for a service computed by the respective matchmaker. For this, the property function defined in Listing 4.3 is used. In order to specify a global similarity threshold value for the service offers, the extension function defined in Listing 4.4 is applied (Line 26). So, in the example at hand, the overall similarity needs to be larger than
“0.5”. Accordingly, the matchmaker MM2 needs to be able to handle subsumption relationships for single parameters and compute a numerical similarity. In the work at hand, this is done using LOG4SWS.KOM.
Finally, solution modifiers are defined in Lines 28 and 29 to display the results in descending order and to restrict the number of results to 20.