Re: In Support of Explicit Standardised Types

> [Gregory Huczynski]

> 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. 
> ...
> 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.

As Gerhard Wickler said in response to your posting, a service's
having a standard type (e.g., 'Printer') and its having preconditions
and effects (e.g., "the document gets printed") are not mutually
exclusive.  It certainly seems that a type would help narrow down the
domain of discourse.  But a type alone isn't going to answer questions
such as "How do I get the printed output?", "How do I pay for the
printing?", "At what hours is the printer available?"  (One might
argue that the types of inputs and outputs to the service makes it
possible to infer what the answers to such questions are, but I don't
see how.)

You're completely correct that being able to phrase such questions
depends on agreement among humans on a formal language or ontology.
But perhaps we can benefit from the fact that the vocabulary decouples
into service-type-dependent pieces (output = documents) and
service-type-independent pieces ("How do I get the output from ...?",
"How do I pay for ...", "At what hours is ... available?").

-- 
                                   -- Drew McDermott
                                      Yale Computer Science Department

Received on Thursday, 20 May 2004 13:47:46 UTC