W3C home > Mailing lists > Public > public-sws-ig@w3.org > March 2004

Re: [WSDL] Message Typing

From: David Martin <martin@AI.SRI.COM>
Date: Fri, 19 Mar 2004 16:50:08 -0800
Message-ID: <405B9540.7050507@ai.sri.com>
To: Drew McDermott <drew.mcdermott@yale.edu>
Cc: public-sws-ig@w3.org

Drew McDermott wrote:

> David Martin's message of 16 March concerns the problem of a web
> service expecting as input an element of some OWL class.  

Right.  That is, it will be nice if some Web services (those that are 
based on OWL technologies and reasoning techniques) can directly use OWL 
to specify the types of their inputs and outputs, rather than using XML 
schema definitions for that purpose, and having to support additional 
steps of mapping between OWL elements and XML Schema elements.

The problem
> (I think) is that in reality all a program can receive is a
> _description_ of an object, but we would like to abstract from any
> particular description and say "Input A must be a Person."
>>I'm afraid I haven't much time to think through these issues, but 
>>intuitively I have the strong feeling that it should be possible to 
>>arrive at some reasonably straightforward solution.  What about 
>>something along these lines:
>>An input type (of a Semantic Web service) is specified as
>>1) the URI of a named OWL class C, along with
>>2) a set of URIs for loadable OWL KBs in which that class is defined.
>>(Typically I think there would just be a single KB, but we're allowing 
>>for the case in which relevant declarations exist in several KBs.)
>>An input corresponding to that type is
>>3) a collection of OWL instances, of which one is identified as the 
>>"designated instance" DI.
>>Something like the following three conditions would be used to establish 
>>the validity of the input:
>>Let Knowledge Base K be the union of all the KBs mentioned in (2) along 
>>with the instances of (3).
>>C1) DI has to be properly classifiable as an instance of the class C, 
>>using standard DL classification techniques, in the context of K.
>>C2) By special convention, the restrictions in K that apply directly to 
>>DI must themselves be "concretely instantiated" in K.  (So, if there's a 
>>restriction that an instance of class C must have exactly 1 instance of 
>>property P, then exactly 1 such instance of P for DI must be present in K.)
>>C3) This special convention must also hold for the other instances in 
>>(3), besides DI.  [I list this separately because I'm less clear about 
>>it :-].
>>I'm not a DL expert, and the above is fuzzy in certain ways, and I've no 
>>doubt I'm omitting various details and subtleties of the problem (and 
>>I'm looking forward to hearing what they are :-).   I'm hoping to 
>>generate some discussion towards a pragmatic set of conventions that 
>>might ensure the usefulness of OWL for purposes such as the one at hand.
> Am I right, David, that this is an attempt to capture, in DL-ese, what
> it means for a set of data to be an adequate description of an object?

Right.  That is, it's an attempt to set up conventions by which a 
service provider can use OWL to say "here's the kind of description that 
input A should be", and that will tell a service requester what it needs 
to know to provide an adequate input.

> Assuming that's correct, then I have two questions:
> 1. What is the purpose of the collection of OWL instances mentioned in
>    "3)" of which DI is an element?

Those OWL instances *are* the input.  For example, if the input class 
(my element (1)) is Person, these instances might look like this (using 
careless shorthand OWL):

<Person id="Drew"><hasAddress resource="#DrewsAddress"/></Person>

<Address id="DrewsAddress">

The "Drew" instance would be the "designated instance", simply 
indicating that it's the instance of Person.

The point of the "special convention" that I mention is to address what 
seems to be the central issue of the "Decker problem".  If the 
definition of Person includes a restriction that says "a person has 
exactly one address", this special convention simply tells the service 
requester that the input has to include an instantiation of hasAddress. 
  I'm also imagining that mainstream OWL tools will implement a 
processing mode that checks to make sure that this special convention is 
satisfied, so that, for instance, the service provider can flip on that 
processing mode when it does type checking on its inputs.

So, what I have in mind is simple and straightforward (indeed, 
simplistic, but hopefully some kind of a starting point).  I'm just 
trying to get at something that might work for the great majority of 
simple commonplace services.

> 2. When you say "must themselves be 'concretely instantiated' in K,"
>    do you mean that the same set of conventions must be recursively
>    applied?  That is, if a person has exactly one head, then the
>    description of the person must contain a description of a head that
>    applies unambiguously only to that person's head?  If so, the
>    requirement seems a little extreme, and possibly ill-founded.

Let me answer that in a separate message, so as not to clutter this 
message too much.

> Let me make a suggestion that I think others have already made: Why
> not stipulate that at the process level we can use Owl classes as
> types of inputs, 

Yes, that's as we do now (in OWL-S), and I don't suggest to change that.

and that the grounding must then spell out exactly
> which information the web service requires in order to know which
> person is meant?

What I'm trying to accomplish here is to minimize what is required to 
spell this out, for cases where the service provider and requester are 
both "native speakers" of OWL.  For these cases, I'm hoping that the 
adoption of some conventions essentially will make it possible to use 
OWL for the "spelling out".  If a service provider and requester are 
native speakers of OWL, then it seems desirable to use OWL restrictions 
to spell out this information, and pass the inputs using one of the 
established serializations of OWL, rather than spelling it out using XML 
Schema, and then requiring additional specifications to show the 
correspondence between the XML Schema elements and the OWL elements.

Please let me know if more clarification is needed.

Received on Friday, 19 March 2004 19:49:10 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:54:12 UTC