saiedt
commented
7 years ago 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 https://github.com/universAAL/service/issues/1, or mute the thread https://github.com/notifications/unsubscribe-auth/ARVIhw0jSy53EFPhZh59SsC3zs-fAwaNks5rhV0XgaJpZM4MPkGg.
cstockloew
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.