– could be overcome by using comprehensive,
semantically-rich description language.
Until the moment, there are published several
proposals for languages and systems supporting
universal service descriptions (Bandara A., 2004),
(OWL-S, 2007), (Sun, 2007). Universal frameworks
such as uMiddle (Nakazawa J., 2006) try to enable
seamless device interaction over diverse middleware
platforms. However, they fail in achieving flexible
and adequate interoperability between environments
based on different service technologies. Creation of
languages as USQL (Unified Service Query
Language) is quite prominent as this is a way to
enable service requestors to interact with
heterogeneous service registries, for the discovery of
available services (Pantazoglou, 2006).
2 REQUIREMENTS FOR
SERVICE DESCRIPTION
LANGUAGE
Service descriptions can be done in various levels of
detail. They range from simple keyword-based to
highly complex ontology-based approaches and
many different languages have been proposed in the
last years. We can distinguish four clusters of
description languages: keyword-based, template-
based, object-based and ontology-based descriptions
(Klein M., 2003). As presented in figure 1, the lower
is the semantic expressiveness the higher is the
ability of such a language for automated
comparison. While keyword-based descriptions are
far from semantic context representation, template-
based approaches - such as WSDL, SLP (Bratoev
M., 2006) and UPnP (Microsoft, 2007), and object-
based representations - like these used in CORBA
and Jini (Sun, 2007), try to structure service
descriptions into templates and objects. However,
they provide means for describing non-functional
service aspects while functional semantics have to
be still derived from textual descriptions, names and
parameters. Finally, ontology-based approaches -
such as RDFS, DAML-S (Defense, 2006) and OWL-
S (OWL-S, 2007), succeed in providing higher
expressiveness by trying to define an upper
extendible ontology for all types of services where
there are proposed general service descriptions for
both non-functional and functional service attributes
such as input/output parameters and result effect.
The definition of a powerful, protocol
independent, language for service description is
vitally important for implementation of mediated
translation. In principle, this language should be
highly expressive and able to represent every
concept in a set of real service description
languages. It must allow automatic comparison of
service descriptions without any need for additional
human analysis. It also has to be flexible and
adaptable to changes in order to reflect the
evaluation of real description formats.
Figure 1: Classification of service description languages.
A good service description language has the
following important characteristics:
• Semantically expressive - service descriptions
must be expressive and flexible, scaling to
future device types and providing support for
reasoning about services.
• Automatically comparable – the ability for
automatic comparison of service descriptions
is essential and implies well structured
descriptions
• Flexible and extensible – as the information
that should be included in the service
description changes the language must be
able to accommodate the new reality
• Editable – descriptions should be easily created
and modified by humans, possibly by using
special-purpose editors.
Our vision for such a language is that it should be
ontology-based. The particular format for service
description should be able to represent various
properties of the service such as its interface and
attributes as well as its dynamic behavior. When
examining requirements about semantic
expressiveness, we naturally come to the conclusion
that only ontology-based description languages can
provide enough expressiveness for an automatic
service trading. Describing services using ontology
is superior to using other forms of data structures
such as service templates etc. used in current
standards, because that method provides a structure
that makes it possible to reason about and derive
WEBIST 2009 - 5th International Conference on Web Information Systems and Technologies
106