In Support of Explicit Standardised Types

Hi,

I've been thinking a lot recently about exactly what information would 
be required by an application / agent to autonomously discover and use 
a service instance that it had never met before. As a clarifying 
example, imagine we lived in a world of ubiquitous services in which 
Alice is visiting a comp sci department to give a presentation. On 
arriving in the department, she decides to print out a paper copy of 
the slides, just in case the whizzy digital projector breaks down. So, 
there's Alice, surrounded by a sea of departmental Semantic Web 
services, wanting a printer. What happens?

With current technology, Alice's application sends a printer service 
request to the local matchmaker as an OWL service profile. From what I 
understand, matchmaking will primarily occur through matching on the 
IOPE aspect of the profile. However, at the moment, it seems that 
matching is only happening on the inputs and outputs, as the 
precondition and effects aspects haven't been defined yet. Assuming IO 
matching, let's imagine a very simple printer service - it takes in a 
Document (grounded as an array of bytes) and returns a 
Success-Confirmation (grounded as a boolean) when the document is 
printed. However, let's also imagine that there are 2 other types of 
service available that have the same IO profile - a projector service 
(displays the document through a particular projector), and a speech 
service (reads document aloud through a particular speaker). So, the 
matchmaker narrows down all considered services to printers, projectors 
and speakers which conform to the Document-Confirmation IO profile, and 
returns a list to Alice's application. At this point, Alice's 
application has a problem - all the filtered services have the required 
inputs and outputs, but only some actually print documents. In essence, 
inputs and outputs aren't enough to define the specific functionality 
of a service. How can the application correctly choose a printer?

Here are some potential courses of action:

1. The application asks Alice to choose. That's fine, but in an ideal 
world we don't want to bother Alice. Anyway, in other scenarios, the 
application might need to act autonomously without end-user 
intervention.
2. The preconditions and effects aspects of the IOPE profile are 
defined, and complete matching is done. So, the matchmaker can ideally 
filter down to only those services that have the effect of printing a 
document.
3. Different explicit ``type'' concepts have been previously defined, 
which represent printers, projectors and speakers. All services are 
tagged with a type. Alice's application is aware of these types, and 
requests that the matchmaker also narrow on type printer inside the 
service profile.

 From what I understand, options 2 and 3 are referred to in the 
literature as explicit and implicit service representations 
respectively, and that the current thinking is that implicit 
representations are a better direction for Semantic Web services. In 
``Automated Discovery, Interaction and Composition of Semantic Web 
Services'', Sycara et al state that ``we believe that implicit 
representations are the only way to represent Web service capabilities 
which has the potential to generalise to all services on the Web''..

However, here I'm a bit confused. If the implicit representation 
approach is taken, the functional semantics of a service will be 
precisely defined through its Inputs,Outputs, Preconditions and 
Effects. So, the matchmaker could narrow down to printers that matched 
the IOPE profile specified by Alice's application. But, what advantages 
does this approach have over using an explicit printer type? Alice's 
application needs a printer. As such, it will need to be previously 
programmed/supplied with the notion of printer, either as a specific 
printer type concept, or as an IOPE profile that represents a printer. 
Alice expects her application to always behave in a particular way - 
that is, print documents. The only way Alice's application can be 
guaranteed to do this is if there has been previous agreement on how a 
printer service behaves, and what it will look like in service profile 
terms. So, when Alice's application finds an unknown service in an 
unknown environment (like the comp sci department) that conforms to the 
standardised printer service profile, it _knows_ that it's dealing with 
a printer: not a projector or speaker that happens to share the same 
inputs and outputs.

So, to my mind, you're always going to need prefined types in order to 
guarantee expected behaviour in a dynamically discovered service. The 
type could be explicit like a tag, or implicit, like an IOPE profile. 
But, given they do the same thing, why do we need to go the extra mile 
and define a complete IOPE profile? Defining IOPE will require 
standardised ontology definitions for service inputs, outputs, 
preconditions and effects. That's at least four service concepts 
needing to be argued over, rather than one type concept. Now, there is 
an advantage in defining inputs and outputs, as you can do nifty things 
outside of service discovery involving directed service composition 
(see ``Composition-driven Filtering and Selecting of Semantic Web 
Services'' by Sirin et al). However, I'm not so sure about 
preconditions and effects - if they're only being used in service 
discovery, then using standardised type tags would seem easier to 
define. Couldn't preconditions and effects be considered somewhat 
superfluous?

Perhaps the main argument that could be levelled at explicit types is 
that it would be hard to obtain agreement on the standardisation of 
service types (e.g. something labelled 
PrintersConsortiumOntology.Printer1 will behave like this, and will 
manipulate its inputs in this way, generating this output). Moreover, 
services might be developed with nigh-on identical functionality, but 
with a different explicit type. This would mean that an application 
might miss using a service, if it was classified with an different type 
that the application wasn't aware of. But the exact same problems would 
be faced with complete IOPE profiles, only at a higher level of 
abstraction, at the level of inputs and outputs and preconditions and 
effects. Standardisation is still required for the different IOPE 
concepts, and if a semantically-identical service is described with a 
subtly different IOPE profile than the one used by the application, it 
won't be match (the variation problem could be addressed in both cases 
by specifying some notion of equivalence between concepts in an 
ontology).

Perhaps in the distant future, Alice's application would have enough 
human-style intelligence to understand _on its own_, from analysing the 
description of a service, that it's found a blob of software 
functionality that prints documents. It might then work out how to use 
the printer service, and send the document to it, happy in the 
knowledge that it has _definitely_ printed Alice's document, as she 
required. However, we are some distance from this level of machine 
intelligence. We can develop a framework for providing rich, semantic 
descriptions of services, which enable some level of automated service 
discovery, composition and operation. But, at the end of the day, we 
still require human standardisation of the different concepts that 
describe the services. Isn't that the point of an ontology? So, to my 
mind, I'm not sure about how preconditions and effects fit into 
automated service discovery, and what problem they solve over explicit 
types. Either way, for Alice's application to be able to choose 
autonomously a service that does the right thing (prints), humans will 
have to standardise on the concepts (whether explicit or implicit) that 
define a printer service. To me, using explicit types for service 
discovery and input and output profiles for service compositions seems 
the path of least resistance, compared with ``implicit'' preconditions 
and effects.

 From the perspective of autonomous service discovery and usage, 
standardisation on the description / definition of services, and the 
consequence notion of type, doesn't seem to be something that can be 
avoided. Richer semantic descriptions of services may prove useful, but 
still require human standardisation of ontological concepts for an 
application to be able to use a service autonomously, and guarantee 
that it provides the required functionality. Other areas apart from the 
semantic web are facing the same problem of standardisation of service 
types. For example, proponents of Jini tried to standardise on Java 
service interfaces for services that provided particular functionality. 
Moreover, other styles of approach are being investigated, apart from 
ontologies, for handing variation in the typing and description of 
semantically-identical services (see ``Application-Service 
Interoperation without Standardised Interfaces'' by Shankar Ponnekanti 
and Armando Fox).

Well, that's my two cents / tuppence worth ;-) Hope it provides an 
interesting discussion point!

Gregory Huczynski

Received on Friday, 14 May 2004 09:42:15 UTC