W3C home > Mailing lists > Public > www-ws@w3.org > October 2003

Re: [owl-s] Re: My version of my proposal

From: Bijan Parsia <bparsia@isr.umd.edu>
Date: Thu, 9 Oct 2003 18:11:54 -0400
To: www-ws@w3.org
Message-Id: <9716DD00-FAA5-11D7-9477-0003939E0B44@isr.umd.edu>

On Thursday, October 9, 2003, at 02:06  PM, Mark Burstein wrote:

> (Responding to Bijan's desire to see this discussed on www-ws)
> Below is an example I constructed following Bijan's model (see 
> included msg at bottom) using as a starting point the DAML-S group's 
> proposed BravoProcess owl-s example.
> I see several issues/arguments to be made:
> 1. This approach is still trying to mix what is essentially a process 
> as instance description with a mechanism geared to processes as 
> classes (or at least the parameters of such processes described as 
> classes).

Mine isn't, unless you mean that I use classes at all, or that I'm 
trying to express a relationship between one "description" and "many" 
things. Technically speaking, I'm not trying to represent processes as 
OWL classes. I am trying to capture some of the process/trace idea. I 
didn't start out that way, but it seemed worth essaying if it also 
solves the first problem.

>   For example,  AcctName_In in my example below is a dummy instance of 
> AcctNameInput created solely to tie it to the ProcessAsInstance (PAI) 
> description of LogIn without having a property point to a Class.

Er... there are several of those...do you mean in your version of my 
example? I'll assume that.

I don't believe that's the *sole* reason, though that was the initial 
motivation. Moving to PAI doesn't mean giving up classes or the use of 
classes, i hope. I mean, just go back to RDF, then.  There's lots of 
things we could still use classes for, e.g., process instances vs. 
process occurances, general constraints on sorts of processes (e.g., 
information only services as being restricted to card 0 on effects), 

>  (Maybe there is another way to do this, but I don't see it.)  At some 
> level then, this seems to me not much better than just pointing to an 
> anonymous instance of the AcctName class, which (the actual parameter 
> range restriction we want to indicate). Both do the same thing to 
> avoid OWL Full.

I don't see the "same thingness". Mine has an actual, clear, in owl 
semantics that is recognized by a standard reasoner. It's analogous to 
how we deal with Inputs in the first place, so seems stylistically 
similar. It's verbose but that's because *it says more*.

> 2. Much of the rest of the machinery is really to support the 
> classification of parameter values in execution traces, which I would 
> argue is
> a somewhat separate issue from the PAI language for process 
> descriptions, which, while perhaps not a surface language, is no 
> longer describing
> the structure of classes of process instances (traces) either.

But it more generally enforces typing, I think. For example, and I need 
to provide details, but if you try to match an input with another that 
is a member of a parameterType (encoded my way) that is disjoint with 
theirs, you should get an inconsistency. We can classify inputs based 
on parameter type. Etc. (I hope)

> I think we should discuss Bijan's proposal as PART OF a model of how 
> to represent execution traces, but not as a part of PAI.

Well, I think they're both. The latter was gravy to me :) My encoding 
says, that an Input has a certain paramtertype (expressed as a 
restriction on the types of possible values for that input). I thought 
that's what parameterType *was*.

>  I would claim that we shouldn't need to include these extra class 
> definitions within each process model built using PAI - even if we 
> believe that yet another surface language will be needed.

I think we can punt on it altogether (until we have a more powerful 
formalism), or we can uses somthing like mine. Using OWL Full is like a 
punting (in this case). Or, it's a challenge to someone to show an OWL 
Full reasoner doing the right thing. I even thought a bit about that, 
and it's hard.

> In moving to PAI, I would say we have "given in" to the idea that we 
> are not going to do much reasoning directly on the process 
> descriptions using OWL DL reasoners.

I think my example was a counterexample to this idea.

> We are really moving more to an RDF encoding of processes AS 
> descriptions, much like we might have if we RDF-ized WSDL or BPEL. We 
> are no longer defining classes that could represent execution trace 
> descriptions.

No, but I manage to represent that all the same. It's not complete, I 
grant, but it works for this case at least and I've not had a chance to 
work it for the res.

> If what we really have is effectively an RDF encoding of a process 
> description, I would argue this may not be the right place to worry 
> about avoiding OWL Full, so we might as well have inputs have 
> parameterTypes that point to Classes (effectively parameter ranges).

This ignores the worry, expressed by me in telecon, that this might 
inhibit moving to other, more expressive than OWL Full formalisms. 
Check out the HUGE issues with the semantic layering. It's *hard*. Do 
we really want to go to what is at least a second order syntax? For 
this? Instead of typed variables or some such?

>  If there is one piece of the language that should NOT be distorted, 
> it should be the relationship between types and process parameters (or 
> types and channels - our mechanism for 'local process variables'). 
> This is the bridge to reasoning we WOULD like to see in OWL, namely 
> the formation of queries and inferences about what values can be 
> provided as inputs to particular processes.

I though I gave that, actually. It's part of what I was aiming for. 
Indeed, if you know that foo is an Airport, you can conclude that foo 
is a possible value of that Input.

>   The special purpose reasoners that do get built to interpret process 
> descriptions will want to do several specific kinds of things in my 
> mind: 1) Identify sets of parameters and their type restrictions

Seems doable on my scheme.

> 2)  Identify conditions and effects  and 3) identify control and data 
> flow relationships.

I'm not sanguine about this, but perhaps not as hopeless as when I gave 
up on PAP. I'll also notice that moving to PAI will let us use the ABox 
query technique that Ian Horrocks  & Sergio Tessaris developed:
and the earlier paper:

We will have this implemented in Pellet, shortly. (I hope :))

> To support the first one, the relationship between each parameter and 
> the constraints on its allowed values should be easily found.

And so it is. I believe. It's easy to traverse the restrictions. And 
for any arbitrary type, you can easily determine if it violates the 
restrictions (try to make the parameter a member of a contrary 
restriction...I may need to add some cardinalities to make this work).


I'm really not yet sure of the limits of this (general) technique, but 
it seems quite workable.

Bijan Parsia.
Received on Thursday, 9 October 2003 18:11:28 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:37:10 UTC