W3C home > Mailing lists > Public > public-sws-ig@w3.org > November 2003

[OWL-S] Re: the precondition property in OWL-S 1.0

From: Bijan Parsia <bparsia@isr.umd.edu>
Date: Tue, 11 Nov 2003 07:55:30 -0500
Cc: public-sws-ig@w3.org
To: Austin Tate <a.tate@ed.ac.uk>
Message-Id: <5479FC08-1446-11D8-A350-0003936A0B26@isr.umd.edu>

On Tuesday, November 11, 2003, at 05:55 AM, Austin Tate wrote:

>
> At 17:55 10/11/2003 -0500, Drew McDermott wrote:
>> It's not clear what your argument is.  Your suggestions for properties
>> make sense, and may be the best set for interfacing to a
>> constraint-based planner.  But if someone is concerned about some
>> aspect of an activity that relates to the other 72 properties, what
>> harm can it do to let them use more properties?
>> Different applications could look at different subsets of properties
>> and be pretty much oblivious to each other's concerns.
>
>
> Good point Drew ... and yes definitely there should be separate 
> properties for things that relay are semantically different.   But 
> each time we add a property we should have a discussion on whether its 
> REALLY a separate property or whether its just a special case of a 
> more general type.

These are necessarily distinct? I'm fine, for example, with a general 
"hasParameter" superproperty (or even, ickily, "hasIOPE"), but I need 
*some* way to distinguish what's a precondition from what's an effect. 
My choices seem to be either have distinct properties, or have distinct 
classes (i.e., either hasPrecondition vs. hasEffect, or hasIOPE 
instanceOfPreconditionClass vs. hasIOPE instanceOfEffectClass). (This 
is assuming we maintain the basic structure of OWL-S. If, for example, 
we move to some sort of conditional to represent the relationship 
between preconditions and effects, things are different. We have no 
good conditional on the table to do this (e.g., OWL Rules' conditional 
is insufficient given that it's just the material conditional; 
generally, I believe, you don't want to be able to contrapose 
preconditions and effects, but I could be wrong...)).

> I was really trying to reduce the number of distinct properties by 
> coalescing all the various things that we can relate to a broader 
> notion of constraints on the activity.
>
> My concern was that we had separate properties for preconditions, 
> effects, inputs, outputs, etc. and I can assume we will need to add 
> more variants of these to cover world state range constraints, 
> resource constraints, spatial/location constraints, quality 
> constraints, you name it.

Really? Those seem distinct from IOPEs in so far as they are 
constraints with different subject domains, rather than different times 
of evaluation.

>   So I was really arguing for ONE property called "(activity) 
> constraints" that itself had ALL those things that can be considered 
> as such to be specializations.

Well, if that's all....easily done. Perhaps already done in OWL-S 1.0. 
Hmm. Even in OWL-S 0.9:
	<owl:ObjectProperty rdf:ID="input">
  		<owl:subPropertyOf rdf:resource="#parameter" />
	</owl:ObjectProperty>

We can, of course, haggle on the name of the superproperty.

>  Then systems could communicate, manipulate or in some cases reason 
> about the whole set of constraints  - in some cases without being able 
> to handle the details of what they mean.

That sounds interesting, but somewhat implausible without the temporal 
distinctions.
[snip]

Cheers,
Bijan Parsia.
Received on Tuesday, 11 November 2003 07:54:20 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 16 March 2008 00:10:53 GMT