Goal-based Service Utilization Using SPARQL and OWL-S[1]

Goal-based service utilization helps service clients to avoid any dependency on technical details of the "how"s, just focusing on the "what"s. That is, if a service client does not need to formulate its request in terms of interfaces and methods but can simply express the meaning of what it wants to achieve, it is communicating goal-based.

Goal-based service utilization is particularly useful in open distributed systems, such as the Web or well-designed Ambient Intelligence (AmI) systems, that allow components, whether physical or logical, to be added and removed dynamically and nevertheless guarantee a certain level of operation, without having to recompile, reinstall or restart any part of the existing and running system. In particular, there can be no assumption about service availability in open distributed systems so that zero or more components may exist that provide a required service. Obviously, the independence from concrete interfaces and methods leads to more openness of such systems.

We believe that SQL-like query languages generally provide a suitable formalism for goal-based communication as they just rely on a data model and per se pose no technological or methodical requirements on query handling. In such queries, the goal can be formulated starting with simple "speech acts", such as DELETE, INSERT, SELECT, and UPDATE, while the remaining of the query allows to unambiguously interpret what the query is supposed to achieve.

The emerging Semantic Web technologies provide a possible solution for modeling and exchanging data in open distributed systems, on which we rely to provide a solution for goal-based service utilization. In particular, we use OWL-S for describing services and SPARQL as the query language. Let's just start with an example to see how SPARQL could be used to formulate service requests:
"...the phone rang. When Pete answered, his phone turned the sound down by sending a message to all the other local devices that had a volume control."
[excerpt from the example scenario in the beginning of The Semantic Web]

Relying on an understanding of the domain summarized in the following UML diagram and using a syntax similar to SPARQL Update, a first attempt to formulate the above request in terms of SPARQL could look like the following[2]:

The main problems with the above query are twofold:

1  The "data view" of service classes

OWL-S justifiably concentrates on domain-independent aspects of modeling services. The link to the domain ontology is made by introducing concepts like profile:ServiceCategory, on one side, and using domain concepts in the description of the process preconditions, inputs, outputs, and results, on the other side. However, there is no argument against bringing these two aspects together by (1) using the OWL-S concept service:Service directly as the root of the domain-specific service ontologies for defining specific service classes, and (2) explicitly relating such classes to the domain concepts. The UML diagram below enhances the above simple ontology accordingly by defining volume control services as services that control devices with volume control.


The notion of data view of classes of services is derived from this explicit definition of service classes that are related to the domain ontology. The above figure is already imparting how the vol:VolumeControl class of services views the "world" in terms of classes of data. Consequently, RDF graphs can be imagined to exist that contain the instances of vol:VolumeControl as nodes that are related (via vol:controls) to other nodes reflecting the state of this "world". We call such a graph a data view graph. Service components can address each reachable node in the "data view graph" of their realized services by a closed ordered list of property URIs, a.k.a. property paths. As an example, for a software component controlling the volume level of a stereo set in our:livingRoom of our:flat, a part of the imaginary "data view graph" at a given point in time may be summarized as:

Property path of reachable nodes Values of reachable nodes
( vol:controls ) our:stereoSet
( vol:controls vol:volumeLevelPercentage ) 40
( vol:controls phw:occupies ) _:BN123
( vol:controls phw:occupies phw:isIn ) ( our:livingRoom our:flat )

Based on this understanding, the semantic of inputs, outputs, and effects of a large set of concrete services can be summarized the following way:
The thesis is now that both components that realize services (and want to advertise their profiles) and clients that want to issue a service request can rely on this shared "data view" of the domain services.

2  Adaptation of SPARQL for service querying

As indicated in the beginning, we favor the usage of SPARQL for formulating service requests. Relying on the concept of "data view", it even appears very natural to do so. We only need to find a solution for the two problems mentioned in the end of the introductory text. We suggest to resolve them based on a new query clause, namely 'CALL', in conjunction with a variable that is used as the "entry point" in the WHERE clause:
CALL ?s
DELETE { ?device vol:volumeLevelPercentage ?oldvol }
INSERT { ?device vol:volumeLevelPercentage 10 }
WHERE {
    ?s a vol:VolumeControl ;
       vol:controls ?device .
    ?device phw:occupies ?loc .
    ?loc phw:isIn some:loc .
    FILTER ( ?oldvol > 10 )
}

With this new clause, we resolve both of the aforementioned problems: (1) The query is identifiable as a service request, and (2) there is no need to refer to any concrete data graph. Here, a second example: To get the URIs of all volume-controllable devices in some:loc, the service query could look like the following:

CALL ?s
SELECT ?d
WHERE {
    ?s a vol:VolumeControl ;
       vol:controls ?d .
    ?d phw:occupies ?l .
    ?l phw:isIn some:loc .
}

Using such service queries, clients avoid both technology bias regarding the realization of services and dependence on input parameters. If a service component that cannot process such queries and is accessible only over conventional ways, such as Web service calls, has registered a service that matches a certain query, it will be a task of service match-making to decide if a certain constant value used in the query must be passed as an input parameter. Such a decision will depend on the conditions under which a certain service matches a certain request. E.g., in the examples above, a registered service may match not only if its "data view" is a priori restricted to devices in some:loc but also in case it accepts the location of the controlled devices as an input parameter to restrict its data view accordingly. Similarly, in case of the constant value 10 as the new volume level percentage, both of the operations setVolumeLevel(DeviceWithVolumeControl, int) and setQuiet(DeviceWithVolumeControl) might match if both of them guarantee the same effect.

3  OWL-S service descriptions using the "data view" notion

We use a special variant of SPARQL in service profiles for describing the semantic of process results, especially the effects and output bindings. We call this variant SPARQL-S. SPARQL-S queries always start with 'FOR EACH CALL:' and their mandatory WHERE clause must start with the service instance whose results are being described. So far, only one extension to the standard SPARQL specification was needed in the body of such queries, namely a new unary operator called passedValueFor has been introduced that can be used both in statements and in filters.

Let's look at an example[3] for understanding how a "data view" extension to OWL-S works. The first segment of the example defines server:MyVolumeControl as a subclass of vol:VolumeControl, whose instances control things that occupy a space in our:flat while enumerating all of its instances. Furthermore, all input and output parameters used in the description of these instances in the following segments are also declared in this segment.

server:MyVolumeControl a owl:Class ;
  rdfs:subClassOf vol:VolumeControl ;
  rdfs:subClassOf [
    a owl:Restriction ;
    owl:onProperty vol:controls ;
    owl:allValuesFrom [
      a owl:Restriction ;
      owl:onProperty phw:occupies ;
      owl:allValuesFrom [
        a owl:Restriction ;
        owl:onProperty phw:isIn ;
        owl:hasValue our:flat
      ]
    ]
  ] ;
  owl:oneOf (
    server:getControlledDevices
    server:getDeviceByLocation
    server:getVolumeLevelOfDevice
    server:setVolumeLevelOfDevice
  ) .

server:devicesToReturn a process:Output ;
  process:parameterType "http://ontology.example.org/VolumeControl.owl#DeviceWithVolumeControl"^^xsd:anyURI .

server:deviceLocation a process:Input ;
  process:parameterType "http://ontology.example.org/PhysicalWorld.owl#Location"^^xsd:anyURI

server:theDevice a process:Input ;
  process:parameterType "http://ontology.example.org/VolumeControl.owl#DeviceWithVolumeControl"^^xsd:anyURI .

server:volumeLevel a process:Output ;
  process:parameterType "http://www.w3.org/2001/XMLSchema#int"^^xsd:anyURI .

server:newVolumeLevel a process:Input ;
  process:parameterType "http://www.w3.org/2001/XMLSchema#int"^^xsd:anyURI .

The next segment defines the service instance that delivers the list of all devices controlled. To reflect the semantic of the returned value(s), the new property dv:fromSPARQLS has been used in the context of a process:OutputBinding to specify an appropriate query. As this query does not restrict the set of controlled devices, it means that the service will effectively return all of them.

server:getControlledDevices a server:MyVolumeControl ;
  service:presents [
    a profile:Profile ;
    profile:has_process server:getControlledDevicesProcess ;
    profile:hasOutput server:devicesToReturn ;
    profile:hasResult [
      a process:Result ;
      process:withOutput [
        a process:OutputBinding ;
        process:toParam server:devicesToReturn ;
        dv:fromSPARQLS """FOR EACH CALL:
          SELECT ?d WHERE {
            server:getControlledDevices vol:controls ?d .
          }"""^^xsd:string
      ]
    ]
  ] .

For defining server:getDeviceByLocation, we need to get the desired location as an input parameter. This input parameter should be incorporated in restricting the process results for each performance of the process to only those controlled devices that are in the passed location. To reflect this, the new unary operation passedValueFor is used in the specified query.

server:getDeviceByLocation a server:MyVolumeControl ;
  service:presents [
    a profile:Profile ;
    profile:has_process server:getDeviceByLocationProcess ;
    profile:hasInput server:deviceLocation ;
    profile:hasOutput server:devicesToReturn ;
    profile:hasResult [
      a process:Result ;
      process:withOutput [
        a process:OutputBinding ;
        process:toParam server:devicesToReturn ;
        dv:fromSPARQLS """FOR EACH CALL:
          Select ?d WHERE {
            server:getDeviceByLocation vol:controls ?d .
            ?d phw:occupies ?l .
            ?l phw:isIn passedValueFor(server:deviceLocation)
          }"""^^xsd:string
      ]
    ]
  ] .

server:getVolumeLevelOfDevice can be described very similarly like above; the significant difference is that a concrete device should be passed as input instead of a location.

server:getVolumeLevelOfDevice a server:MyVolumeControl ;
  service:presents [
    a profile:Profile ;
    profile:has_process server:getVolumeLevelOfDeviceProcess ;
    profile:hasInput server:theDevice ;
    profile:hasOutput server:volumeLevel ;
    profile:hasResult [
      a process:Result ;
      process:withOutput [
        a process:OutputBinding ;
        process:toParam server:volumeLevel ;
        dv:fromSPARQLS """FOR EACH CALL:
          Select ?p WHERE {
            server:getVolumeLevelOfDevice vol:controls ?d .
            ?d vol:volumeLevelPercentage ?p .
            FILTER { ?d = passedValueFor(server:theDevice) }
          }"""^^xsd:string
      ]
    ]
  ] .

In case of server:setVolumeLevelOfDevice, a second parameter is needed that specifies the new volume level; it is used in an expression defining the process effects. According to OWL-S, only instances of expr:Expression can be used for specifying the process effects; hence, this example introduces the concept dv:SPARQLS as the class of SPARQL-S expressions.

server:setVolumeLevelOfDevice a server:MyVolumeControl ;
  service:presents [
    a profile:Profile ;
    profile:has_process server:setVolumeLevelOfDeviceProcess ;
    profile:hasInput server:theDevice ;
    profile:hasInput server:newVolumeLevel ;
    profile:hasResult [
      a process:Result ;
      process:hasEffect [
        a dv:SPARQLS ;
        expr:expressionBody """FOR EACH CALL:
          DELETE { ?d vol:volumeLevelPercentage ?p }
          INSERT { ?d vol:volumeLevelPercentage
                      passedValueFor(server:newVolumeLevel) }
           WHERE {
             server:setVolumeLevelOfDevice vol:controls ?d .
             ?d vol:volumeLevelPercentage ?p .
             FILTER { ?d = passedValueFor(server:theDevice) }
           }"""^^xsd:string
      ]
    ]
  ] .

In a nutshell, we have introduced only two new concepts, namely dv:SPARQLS and dv:fromSPARQLS, whose formal definitions can be given in conformance with both OWL-DL and OWL-S as follows[4].

dv:SPARQLS a owl:Class ;
  rdfs:subClassOf expr:Expression ;
  rdfs:subClassOf [
    a owl:Restriction ;
    owl:onProperty expr:expressionBody ;
    owl:allValuesFrom xsd:string
  ] ;
  rdfs:subClassOf [
    a owl:Restriction ;
    owl:onProperty expr:expressionLanguage ;
    owl:hasValue [
      :- dv:SPARQL-S ;
      a expr:LogicLanguage ;
      expr:refURI "http://www.w3.org/TR/rdf-sparql-query/"^^xsd:anyURI
    ]
  ] .

dv:fromSPARQLS a owl:DatatypeProperty ;
  rdfs:subPropertyOf process:valueSpecifier ;
  rdfs:domain process:Binding ;
  rdfs:range xsd:string .

4  Realization

The above concept has been realized along with an OWL reasoner within the EU FP7 project PERSONA. However, we are not supporting the proposed SPARQL variants directly, neither on the client side nor on the server side. Instead, the provided solution is based on data structures that can be the result of parsing such SPARQL variants.

The match-making is done within a middleware[5] based on a distributed message brokering mechanism. Equivalent realizations of the middleware run on all of the nodes of the networked ensemble; they cooperate to find the appropriate service components for each service request. Each instance of the middleware is used by components locally attached to it and hides the decentralized nature of the system from those components. The service components register their service profiles with the local instance of the middleware. A component who wants to utilize a service, calls an operation of the local instance of the middleware that can be sketched the following way:

ServiceResponse call(ServiceRequest)

This single operation performs the whole process referred to as Semantic RPC, from issuing a service request, over distributed matchmaking with semantic profiles of available and accessible services, to deriving input parameters for each matched service, calling them, getting the results, mapping them back onto an appropriate response, and returning the constructed result.

So far we could cover all sorts of interoperability needs within the PERSONA system based on the above scheme. All the practical difficulties arisen so far could be mastered based on improvement of domain ontologies, normally by adding missing concepts. Results of evaluating this solution will be available in the spring / summer 2010, after the deployment and tests with real users has taken place in the pilot sites.

5  Conclusion

We have shown how SPARQL (with slight changes) can be used for goal-based service utilization, on one side, and for specifying process results in a slightly extended version of OWL-S, on the other side. With this approach, service match-making can be extended with something like query optimization mechanisms leading to dynamic service composition: On one side, there is a concrete query that formulates a service request and on the other side, there are a set of registered service profiles that describe the "low-level operations" available; if any of those available services directly matches the request, then we are at the traditional level of service match-making, otherwise a "query execution plan" can be worked out for achieving the requested results based on a combination of the low-level operations. As an example, we can consider the first query in section 2 with a single difference, namely that some:loc is replaced by our:flat: If the only registered services are those of section 3, then a possible query execution plan could consist of the following steps:
In addition to working on solid mechanisms for generating such query execution plans in the course of service match-making, another interesting topic for future work is the transformation of user instructions formulated in natural languages into service queries as means for dealing with speech-based user interaction in smart environments.

Footnotes

1 This is an attempt to improve the presentation of the main results of a work of mine in reply to review critique that I had received on a related paper originally sent to the research track of ISWC2009. Due to the lack of time for improving the paper at that time, I submitted it without changes to the co-located workshop SMR2; the published version of that paper can be found here.

2 The following namespace-prefix associations have been assumed throughout this article:

Prefix Namespace
expr http://www.daml.org/services/owl-s/1.1/generic/Expression.owl#
owl http://www.w3.org/2002/07/owl#
phw http://ontology.example.org/PhysicalWorld.owl#
process http://www.daml.org/services/owl-s/1.1/Process.owl#
profile http://www.daml.org/services/owl-s/1.1/Profile.owl#
rdfs http://www.w3.org/2000/01/rdf-schema#
service http://www.daml.org/services/owl-s/1.1/Service.owl#
vol http://ontology.example.org/VolumeControl.owl#
xsd http://www.w3.org/2001/XMLSchema#

3 In this example, (1) the prefix "dv:" refers to a new namespace that defines the needed "data view" concepts, and (2) the new names used in the descriptions are assumed to be expressive enough for human readers.

4As an alternative, dv:fromSPARQLS can be substituted by an object property dv:fromExpression with expr:Expression as its rdfs:range so that output bindings make use of dv:SPARQLS quite similar to its usage in the specification of process effects.

5 See The PERSONA Service Platform for AAL Spaces.

Author

Mohammad-Reza (Saied) Tazari
Wissenschaftlicher Mitarbeiter     :=  Senior Researcher
Interactive Multimedia Appliances  ||  http://www.igd.fhg.de/igd-a1

Fraunhofer-Institut
Graphische Datenverarbeitung       :=  Computer Graphics
Fraunhoferstr. 5
64283 Darmstadt, Germany           ||  http://www.igd.fhg.de/

saied.tazari <at> igd.fraunhofer.de