Re: In Support of Explicit Standardised Types

Drew McDermott wrote:

>>[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?").
>
>  
>
Ultimate;y the meaning is derived from the existence of an 
interoperability standard (de jure, de facto, or at least an expectation 
of a common operating environment). Thus the ontology is of the 
standards that actually make the services useful, with additional 
descriptions of the functions to allow you to discover that the standard 
is what you need to find supported bt real services.  IMHO all the fluff 
about creating descriptions of ad-hoc interfaces  accessing  
ill-defined  functions and even less well defined content is just going 
to be yet another wreck o the roadside. However, the ability to register 
well known service types within an ontology seems like a simple, 
scalable and usage driven solution to the same problem.

Received on Friday, 21 May 2004 21:27:10 UTC