Re: Incomplete descriptions (was Re: Multiple inputs and multiple outputs)

[Bijan Parsia wrote:]

> > [Monika Solanki wrote:]
> >
> >> Drew McDermott wrote:
> >>
> >>>   [Yuzhong Qu" <yzqu@seu.edu.cn>]
> [snip]
> >>>       But, how do you know the exact number of inputs? You just know
> >>>       what you know, maybe there is another statement about a new
> >>>       input (another input may be specified in other place) due to
> >>>       the openness of the Semantic Web (it's not a closed world).
> 
> That another input may be *described* somewhere else doesn't mean that 
> that description is *correct*. The service has the inputs it has.
> 
> While it is true that merely having 3 input properties doesn't *tell* 
> you that there's only 3 input properties, there are ways to nail that 
> down (cardinality constraints, nominals).

So, we should use some constructs (such as cardinality or minimal cardinality) to specify the exact (or, minimal) number of the inputs. 

Or, we should restructure some of the stuff.


> >>> Good point.  We really need a fixed list of inputs and another of 
> >>> outputs.
> 
> It's not clear to me. There are certainly points where we *want* to 
> nail down the number of inputs. But not always. (Profile vs. Process 
> model, for example).
> 
> >>> [It would be interesting denial-of-service attack to tell a service
> >>> that it needed another input and have it then stall because no one is
> >>> supplying it. :)]
> 
> Hmm. I see the smilely, but I'm unconvinced that the DOS is possible.
> 
> >> Although this may be an interesting theoretical argument, I do not 
> >> quite
> >> agree to the fact, that for a particular process,  there may be inputs
> >> which might not be visible and are needed. I do not even envisage 
> >> such a
> >> condition, because the process model is not the only model that 
> >> handles
> >> these parameters. Infact the process model is just an abstract
> >> representation. We have to remember that there is a grounding model as
> >> well, which will take care of these details.for concrete process
> >> execution. If the specification of these multiple inputs located at
> >> multiple places is made visible in the grounding, then I do not see 
> >> any
> >> problem.
> >>
> >> More comments on this welcome.
> >
> > Yes, this is a theoretical issue, but it's about the principle. I 
> > insist on my point.
> >
> > What would happen when an agent (e.g. an agent doing the matching job) 
> > just gets some part of the stuff?
> 
> This is a different issue, yes?

 Fairly right. But it's somewhat related.

> > As we know, every agent just gets what it can get, the agent can't 
> > make sure that it has captured all of the related  stuff (e.g. 
> > multiple input/output issue).
> 
> Sure it can! You just need to supply sufficient info.

See below.

> > How could an agent make sure that it knows all of the related 
> > knowledge distributed over the Internet/world?
> 
> It only needs to make sure it knows what it needs to know. So, lets 
> assume for the momen that I've gotten hold of my three, distinct 
> inputs, and know that there are only three. Given that I know that 
> *these* three are distinct, I've gotten hold of all and only my inputs. 
> Now, there may be *further descriptions* of these three that I don't 
> know about. Great. If I don't *need* to (say, for invocation purpose) 
> know about the rest of the description, then I can stop.

So, some mechanism should be provided in DAML-S to reduce the possibilty of such embarrassment.

Currently, there is no such device (recommended in DAML-S) to specify that there are only three "inputs" required.

> > In the realm of the Semantic Web, an agent just knows what it knows, 
> > so does the human being.
> 
> Most people don't know what they know :)
> 
> Cheers,
> Bijan Parsia.
> 
 
Regards,

Yuzhong Qu

Received on Tuesday, 30 September 2003 04:33:15 UTC