Service Request Completion

[amedranogil]

Since universAAL does not have a knowledge base in memory (in comparison with other semantic frameworks and reasoners) it is some times difficult to address conditions, specially regarding service requests in dynamic resources; since the service profiles are "fixed".

The idea is to create a module (optionally installed) that will extend the service calls by completing the service requests where the information lies in the CHe.
For example: Service request: "turn off any device that is on" would be "not matched". The component would query the CHe for the "devices that are on" then issue the simplified service requests ("turn device x off") which will be matched.

Would need some integration with service bus, in order to find out if the service request is valid or needs completion; and probably we would need to create a component that transforms class expressions to SPARQL.

[saiedt]

This is one of the "future plans" with the service bus, since years! The idea is that a component assists the service bus (like the dialog manager assists the ui bus) to generate a composite service based on other available service; in the conclusions of "Semantic RPC using SPARQL <http://www.ai.sri.com/daml/services/owl-s/extensions/SemanticRPC/Semantic-RPC-using-SPARQL.html>", this has been formulated the following way: 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 section2 <http://www.ai.sri.com/daml/services/owl-s/extensions/SemanticRPC/Semantic-RPC-using-SPARQL.html#Adaptation_of_SPARQL_for_service>with a single difference, namely thatsome:locis replaced byour:flat: If the only registered services are those of section3 <http://www.ai.sri.com/daml/services/owl-s/extensions/SemanticRPC/Semantic-RPC-using-SPARQL.html#OWL-S_service_descriptions_using_the>, then a possible query execution plan could consist of the following steps: * callserver:getDeviceByLocationProcessby passingour:flatas input * for each of the devices in the output of the previous step o callserver:getVolumeLevelOfDeviceProcessby passing the device at hand as input o if the volume level in the output of the previous step is a number greater than 10, callserver:setVolumeLevelOfDeviceProcessby passing the device at hand and the constant value10as input 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. It is indeed an important point that can be addressed in our research projects, with the hope to find good performing solutions for it.

…

-- Saied Alejandro Medrano wrote on 1.3.17 12:57:

Since universAAL does not have a knowledge base in memory (in comparison with other semantic frameworks and reasoners) it is some times difficult to address conditions, specially regarding service requests in dynamic resources; since the service profiles are "fixed". The idea is to create a module (optionally installed) that will extend the service calls by completing the service requests where the information lies in the CHe. For example: Service request: "turn off any device that is on" would be "not matched". The component would query the CHe for the "devices that are on" then issue the simplified service requests ("turn device x off") which will be matched. Would need some integration with service bus, in order to find out if the service request is valid or needs completion; and probably we would need to create a component that transforms class expressions to SPARQL. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ARVIhw0jSy53EFPhZh59SsC3zs-fAwaNks5rhV0XgaJpZM4MPkGg>.

[cstockloew]

see also uaal issues S1 (and S2). This proposal seems to be a special case whereas the original proposal is not restricted to CHE but use any available services to complete the request.