Re: OWL-S preconditions - practical issues

On Jun 24, 2004, at 11:33 AM, Dónal Murtagh wrote:

>
>>> However, there doesn't appear to be any consensus about how
>> bindings
>>> should be specified.
>>
>> There is, in broad detail. At least, we hashed it around a few times,
>> even on this list, I believe. There will be something. The basic
>> outlines are similar to PDDL. The exact syntax was still in the air
>> last I checked.
>
> Any idea where I can find more details about this?

See Drew's reply. It will be in the technical overview.

[snip]
>> It's the other way round. If there *is* such an input, it binds the
>> variable in the precondition. If not, it (IIRC) must have only one
>> possible binding and is bound against the world state.
>>
>
> er, what's IIRC?

Abbreviation for "If I Recall Correctly".

>>> Another matter which wasn't addressed during the recent
>> discussion is
>>> how a preconditon is tested/executed/evaluated - once the condition
>>> itself and its bindings have been correctly specified?
>>
>> Well, it wasn't asked, either. Some of that will be application
>> dependent. It does depend on the specification of a KB (or
>> the like) to
>> evaluate the preconditions against (even after known bindings are
>> made).
>
> If I recall correctly, you suggested that Pellet's conjunctive ABox
> query answering module could be used to evaluate such preconditions.

Yes.

> Is
> this true, and if so, what syntax should they be expressed in if Pellet
> were to be used for this purpose?

We will support, via the OWL-S API, the standard OWL-S precondition 
language, which will be "SWRLlike" as mentioned before.

We'll have RDQL syntax support as well...so I guess you could use that 
if you really wanted to.

>>> Finally, for the purpose of service composition it is necessary to
>>> find processes which are compatible from the point of view of their
>>> preconditions and effects. For example, a process which has
>> an effect
>>> such as:
>> [snip]
>>> could never be executed immediately before a process which has a
>>> precondition such as that shown earlier, assuming #cc is
>> bound to the
>>> same instance in both cases. The point is that the compatibility of
>>> some preconditions and effects can be determined without binding
>>> information and it might be useful to distinguish these from
>>> preconditons and effects whose compatibility cannot be determined
>>> without binding information.
>>
>> In what way? I mean, with some syntax? I would think you (the system)
>> could (would) just analyze it.
>
> What I'd really like to know is whether there exists a tool which can
> determine whether two conditional expressions are compatible.

I was thinking that a planner could do this. Of course, it wouldn't do 
precisely what you were asking for, since it doesn't determine 
compatibility in the general case of the *expressions*. But for the 
purposes of finding compatible *processes* for *composition* it seems 
sufficiently useful.

Cheers,
Bijan Parsia.

Received on Thursday, 24 June 2004 11:50:00 UTC