Artifacts for Multi-Agent Systems have been defined as runtime entities providing some kind of function or service that agents can fruitfully exploit to achieve their individual or social goals. In order to enable agents to autonomously discover the available services, select the proper artifact(s), and use the services they need, it is necessary to describe the services offered by artifacts in terms of (i) what each service does, (ii) how to access it, and (iii) how it works. In this paper we explore how OWL-S (Ontology Web Language for Services), a language specifically aimed for the description of Web Services, can be exploited also for describing the services offered by artifacts. In particular, we investigate how to represent the artifact features by means of OWL-S, provide an example, and discuss some preliminary results in terms of advantages and limitations of this approach.
According to Activity Theory [
In particular, in the Agents&Artifacts (A&A) [
Many sorts of artifacts can populate a MAS, providing agents with a number of different services,
embodying a variety of diverse models, technologies and tools, and addressing a wide range of
application issues. In particular, artifacts are used to mediate between individual agents and the
MAS (individual artifacts), to build up agent societies (social artifacts), and to mediate between a
MAS and an external resource (resource artifacts) [
In this paper we explore the use of the OWL-S [
So, the paper is structured as follows. Section 2 introduces the artifact features, while Section 3.1 briefly presents the fundamental semantic web languages, with special regard to OWL-S. Next, Section 3.2 introduces how OWL-S can be used for describing artifacts, and Section 3.3 provides some details about artifact representation in OWL-S; a discussion about the pros and cons of this approach is developed in Section 3.4. Then Section 4 presents a simple example – a sketch of a flight tracking system – based on the (social) artifacts provided by the TuCSoN infrastructure technology. Some relevant related work is reported in Section 5; conclusions follow in Section 6. 2
Usage Interface — The set of operations provided by an artifact defines what is called its usage interface, which (intentionally) resembles interfaces of services, components or objects – in the object-oriented acceptation of the term. Operations are the means by which an artifact provides for a service or function: an agent executes an action over an artifact by invoking an artifact operation. Execution typically terminates with an operation completion, representing the outcome of the invocation.
Operating Instructions — Coupled with a usage interface, an artifact provides agents with
operating instructions, that is a description of the procedure that an agent has to follow to
meaningfully interact with an artifact over the time. Moreover, operating instructions also come with
the specification of preconditions for actions and effects to perceptions [
Function Description — Finally, an artifact is characterised by a description of the functionality it provides. Function description explains what to obtain from the artifact – a key information for artifact selection. Clearly, function description is an abstraction over the actual implementation of the artifact: it hides inessential implementation details while highlighting its key aspects.
For instance, consider the case of a digital camera. In order to choose a digital camera among all that are available in the market, interested customers usually start by checking the cameras’ technical specifications, such as its memory, zoom capabilities, etc.: these are actually a form of function description – they explain what the camera does. Also, each camera has its own buttons and panels, which must be operated according to the instruction provided by the vendor in the user’s manual. Buttons and panels represent the camera’s usage interface – i.e., how to access it – while the user’s manual describes how to use them to suitably configure the camera resolution, the zoom ratio, etc. – thus representing the operating instruction.
In addition, artifacts typically exhibit further relevant properties, which enhance MAS engineers’ but also agents’ ability to use them for their own purposes. For instance, it should be possible to monitor artifacts as an observable part of the environment, so as to check the development of the activities, track the system history, and evaluate the overall system performance. Desirable artifact features can then be listed as follows: Inspectability — The state of an artifact, its content, the laws governing its behaviour, its usage interface, operating instructions and function description might be all or partially inspectable by agents.
Controllability — The operational behaviour of an artifact should be controllable so as to allow engineers and agents to monitor its proper functioning: it should be possible to stop and restart an artifact working cycle, to trace its inner activity, and to observe and control a step-by-step execution.
Malleability — The behaviour of an artifact should be modifiable at execution time in order to adapt to the changing needs or mutable external conditions of a MAS.
Linkability — Artifacts can be used encapsulate and model reusable services in a MAS. To scale up with complexity of an environment, it might be useful to compose artifacts, by allowing artifacts to invoke operations on other artifacts.
As a final remark, it is worth noting that the above artifact features usually play different roles
in the viewpoints of agents and of MAS engineers. For instance, operating instructions are mostly
seen as a design tool by/for engineers, and as a run-time support by/for rational agents. Instead,
features like inspectability and malleability gain particular interest when the two viewpoints can
be made one: for instance, an intelligent agent capable of playing the role of the MAS engineer
could in principle understand the state and dynamics of the MAS by observing the artifacts, and
then possibly change the overall MAS behaviour by suitably altering the artifacts behaviour [
The Semantic Web project [
RDF has been conceived for describing Web resources – that is, anything identified by a Uniform Resource Identifier (URI): in turn, RDFS specifies the schema for defining properties, classes and inter-relationships among classes. Their applications include the description of any kind of web content for multiple purposes, such as content rating, labelling for search engines, site maps, collaborative services, and e-commerce applications (e.g. to express price, availability, etc. of shopping items). Yet, the lack of some particular features (such as the local scope of properties, the disjointedness of classes, and other special characteristics) led to the development of a new language built on top of RDF and RDFS, specifically designed for processing Web information: OWL (Ontology Web Language, [16]). More precisely, three versions of OWL are available which provide different trade-offs between expressive power and efficient reasoning: OWL Lite, OWL DL (Description Logic) and OWL Full. OWL Lite supports users who just need a classification hierarchy and simple constraint features, while OWL DL is for users demanding the maximum expressiveness without losing computational completeness and decidability of reasoning systems; OWL Full is meant for users who need the maximum expressiveness and syntactic freedom of RDF, though with no computational guarantees.
However, just describing resources is not enough in the perspective of discovering, invoking, composing and monitoring web resources which offer services: this is why a specialisation of OWL for service description, called OWL-S (Ontology Web Language for Services), has also been defined. Figure 1 shows the (top-level) ontology of OWL-S in terms of an RDF graph – a kind of graph used to represent the relationships among resources, property and property values, where nodes (ovals) represent resources or property values, and arcs represent properties. According to that ontology, the discovery, selection and exploitation of a service calls for a suitable description of (i) what the service does, reported by the Service Profile; (ii) how it works, explained in the Service Model ; and (iii) how to access it, detailed in the Service Grounding.
Service Profile — The service profile includes a description of what can be accomplished by the
service, its limitations in terms of applicability and quality of service, and what is required
from the service requester in order to use the service [
OWL-S defines a subclass of the service model, namely the process model, which provides
further details about the number of inputs, outputs, preconditions and effects. Three types of
processes can be defined: atomic, simple, and composite processes [
Service Grounding — Service grounding basically specifies how to access a service, linking Web
Services’ semantic and syntactic description levels: in particular, its main task is to transform
the semantic data to XML messages to be sent over the network, and conversely to define
how the received XML messages should be interpreted as semantic data [15].1
So, it typically defines the communication protocol, the message formats and the serialisation
techniques adopted for each semantic type of input or output specified in the service model.
Since the current definition of OWL-S does not account for any means to express grounding
information, the WSDL [
In the next subsection we will discuss how OWL-S can be brought to the artifact world, i.e. exploited to discover and invoke not only Web Services, but also the services provided by artifacts. 3.2
In order to enable agents to identify and use the services provided by artifacts – which is the key for building open MASs where intelligent agents dynamically look for artifacts and select the most adequate to their goals –, the artifacts’ features need to be expressed in some high-level language.
Such a high-level language should also make it possible for agent to adopt a uniform cognitive level for interaction.
1Web Services are usually described at two abstraction levels: one defining atomic operations in terms of input
/ output messages, the other mapping operations and their associated messages to physical endpoints (ports and
bindings). Ports declare the operations available with the corresponding inputs / outputs, while bindings declare
the transport mechanism (usually SOAP [
Usually, agents speak with each other via languages like FIPA-ACL [
Among the possible choices, OWL-S seems a good candidate for several reasons. First, most of
today’s services are available as Web Services, and OWL-S is specially designed for that purpose.
Moreover, Web Services can be “implemented” by agents and artifacts as in simpA-WS [
The mapping between the artifact features and OWL-S could be represented through an RDF Graph as depicted in Figure 2.
The service profile can be used to represent what the service offered by artifacts does, i.e. the function description; a fragment of the OWL-S file relating to the service profile is shown in Figure 3. The profile class represents the general profile of a service whose text description is contained in the property called textDescription. The profile description can be accompanied by a list of properties called serviceParameters: the actual parameter name, represented by serviceParameterName, can be just a literal, or the URI of the process parameter (a property). Of course, only one text description per profile is admitted, as stated by the value 1 in the howl : cardinalityi tag.
As stated in the previous section, OWL-S introduces the process model as its own special subclass of service model: so, the service model is expressed here as a process model. Correspondingly, Figure 4 defines inputs, outputs, preconditions and results for each process model. The Parameter class is the union of the Input and the Output classes; in the same way, results are represented in as a class, too. hasPrecondition, instead, is a property of Process. Finally, the usage interface that describes how to access the artifact is represented through the service grounding, which takes the form of a collection of AtomicProcessGrounding instances (see Figure 5) – one for each atomic process in the process model: this class relates elements of an OWL-S atomic process to a WSDL specification (or any other specification). Each instance of AtomicProcessGrounding must have exactly one value for owlsProcess: the other properties depend on the specifics of the grounding type. The MessageMap class maps the OWL-S parameters onto the parameters of the grounded operation. In particular, InputMessageMap maps inputs to grounding specification (see Figure 6), while OutputMessageMap maps outputs to grounding specification (see Figure 7); the owlsParamater property specifies the OWL-S parameter. According to the model shown in Figure 2, the usage interface also includes other artifact properties such as inspectability, controllability, malleability and linkability. These properties enable agents to access artifact after selecting the service. Therefore, their OWL-S representation depends on the language chosen for grounding. 3.4
Let us report here some preliminary considerations about the use OWL-S for describing artifacts. As a first aspect, using OWL-S to describe what the service provided by artifact does and how it works in terms of preconditions, inputs, outputs and results is relatively simple: indeed, all we have to do is to make the information that agents are usually supposed to know semantically readable. However, the OWL-S description of how the service is actually carried out is not straightforward, mainly because of the OWL-S’ inability to describe the information related to the physical functioning of the service: this forces to include another language – WSDL being the most natural choice in the Web service context – to add that kind of expressiveness. Yet, WSDL is definitely not the most adequate choice for describing the services offered by artifacts, since it requires information that simply do not fit the artifact case – e.g. the data and message types to be transmitted, the supported operations, how the message is going to be transmitted, where the service is located, etc. – because it cannot be generalised to any services provided by artifacts, given that the technical details depend on the specific implementation.
On the artifact side, it should be pointed out that there is currently no semantic language similar to WSDL to describe the implementation details of a service: so, further investigation is needed in order to evaluate possible candidates, or possibly define some new ad hoc language.
Among the existing composing languages, BPEL [
As outlined in the previous section, OWL-S makes it possible to express the artifact features (the function description, describing what the service does; the usage interface, describing how to access it; and the operating instructions, explaining how the service works) via the service profile, the service model and the service grounding, respectively.
However, while expressing the service offered by an artifact via the OWL-S service profile notion is relatively simple from the conceptual viewpoint, mapping the usage interface and the operating instructions onto the service model and the service grounding notions calls for some hypotheses on both the artifact model and its supporting infrastructure – i.e., about the environment where the artifact itself lives and is called to operate.
To this end, in the following we adopt TuCSoN tuple centres [
TuCSoN2 is an example of agent coordination infrastructure supporting a notion of social artifact,
namely a coordination artifact called tuple centre. Tuple centres are programmable tuple spaces,
that agents access by writing, reading, and consuming tuples – that is, ordered collections of
2TuCSoN technology is available as an open-source project at the TuCSoN Web site http://tucson.sourceforge.net.
heterogeneous information chunks – via simple communication operations (out, to insert a tuple;
rd, to read a tuple; in, to remove a tuple; tuples are accessed associatively. While the behaviour
of a tuple space in response to communication events is fixed, the behaviour of a tuple centre can
be programmed by defining a set of specification tuples (expressed in the ReSpecT language [
In case of the flight tracking service, a tuple centre can be used to mediate the interaction between the user requesting an information (delay and location) about a given flight and the agent charged of retrieving this information.
As a service provided by an artifact, the flight tracking service can be described through: • a function description — here providing information about the delay and the location of a selected flight; • a usage interface — that is, the set of communication operations: here, out, to insert a tuple in the tuple centre; rd, to read a tuple from a tuple centre; in, to remove a tuple from the tuple centre; • operating instructions — that is, the procedure to be followed by the user in order to obtain the desired flight information; here, the user should first request the information by inserting a request tuple such as flight request(flightNumber), then retrieve the desired information by reading a response tuple such as flight status(flightNumber,Delay,Location).
In the OWL-S model3, the tuple centre offering the flight tracking service is characterised by a function description (what the service does), is described by some operating instructions (how the service works), and supports a usage interface (how to access to the service).
In turn, while the function description is provided through a service profile which contains a simple text description (see Figure 8.a), the service model can be described in terms of inputs, outputs, preconditions and effects. Figure 8.b depicts a fragment of the corresponding OWL-S document which specifies the input (FlightNumber), the condition under which the information will be provided (FlightNumberExists) and the effect (InfoProvided).
Finally, in order to represent the usage interface, we need a language similar to WSDL for describing both the type of actions (in, out, rd) and the correct sequence for using them and 3For the sake of shortness, here we show only a sketch of the full OWL-S documents (a specialisation of the generic OWL-S documents presented in Section 3.3). so obtain the information required. As explained in the previous section, further investigation is needed in order to evaluate possible candidates among the existing languages or possibly define a new ad hoc language. 5
The approach examined in this paper combines Semantic Web and the theory of coordination with
the aim of describing the services provided by artifacts via OWL-S. There are also other Web
Service composition languages, such as BPEL4WS [
Business Process Execution Language for Web Services (BPEL4WS) enables the specification of executable business processes, covering also Web Services, and business process protocols in terms of their execution logic or control flow. Executable business processes specify the behaviour of individual participants within Web Service interactions and can be invoked directly, whereas business process protocols abstract from internal behaviour to describe the messages exchanged by the various Web Services within an interaction. The main drawback of BPEL’s approach is that it enables only the composition of Web Services, while OWL-S also supports Web Services’ publication and discovery.
Many other approaches could be used to express how a service is implemented in terms of
action protocol (the remaining part of operating instructions) and usage interface. For instance,
one could think of a semantic language for describing services offered by an artifact based on
the research area on semantic tuple spaces [
Moreover, it could be interesting to study not only OWL-S but also the Web Service Modelling
Ontology (WSMO) [
By drawing an analogy between the OWL-S model and the artifact notion, in this paper we exploited OWL-S for describing the services offered by artifacts. We first presented the notion of artifacts for MAS and how the services provided by such artifacts could be described; then, we presented a preliminary proposal for describing the services provided by artifacts based on OWL-S and a simple example of such a proposal. One conclusion is that OWL-S can be exploited rather easily to express the function description – that is, what the service does – and the operating instructions – that is, its preconditions, effects, inputs and outputs – but can not be directly exploited, in its current version, for describing the usage interface which is strictly related to the implementation of the service
Accordingly, future work will be devoted on the one hand to explore semantics languages for the description of usage interface; on the other, to compare OWL-S and WSMO for artifact description, both from an abstract viewpoint and in concrete examples of artifacts.
[15] Jaceky´ Kopecky, Dumitru Roman, Matthew Moran, and Dieter Fensel. Semantic web services grounding. aict-iciw, 0:127, 19–25 February 2006. International Conference on Internet and Web Applications and International Conference on Internet and Web Applications and Services. [16] Deborah L. McGuinness and Frank van Harmelen. OWL Web Ontology Language Overview.
http://www.w3.org/tr/owl-features, 2004. [17] Andrea Omicini. Formal ReSpecT in the A&A perspective. In Carlos Canal and Mirko Viroli, editors, 5th International Workshop on Foundations of Coordination Languages and Software Architectures (FOCLASA’06), pages 93–115, CONCUR 2006, Bonn, Germany, 31 August 2006. University of M´alaga, Spain. Proceedings.