Re: Question about OWL-S sequence

Quoting Drew McDermott <drew.mcdermott@yale.edu>:

> > [Jeff Dalton]
> 
> > Why can't I use the URIs of process occurrences to put
> > them in multiple sequences and use them to specify the partial
> > order.  For example, if I wanted A before B, B before C, and B
> > before D, I could use something like this:
> > 
> >   (unordered
> >     (sequence URI-for-A URI-for-B)
> >     (sequence URI-for-B URI-for-C)
> >     (sequence URI-for-B URI-for-D))
> > 
> > What is it in OWL-S that disallows that approach?
> 
> I don't know.  We're in the zone one often winds up in when using
> ontology to implement syntax.  Suppose I wanted to write a sentence
> using the same occurrence of the word "winds" as in the first sentence
> of this paragraph.  Not the same word, the same _occurrence_.

Why is that the right analogy?  In a natural language, we often
refer more than once to the very same thing, for instance by
giving it a name, or by using an unambiguous referring phrase.

Once I have a way to refer to particular process occurrences, I can
specify a number of different constraits on those very same occurrences.

"Monday, you're going to talk separately with Alice, Bill, Carol,
and David.  You have to talk with Alice before Bill, Bill before
Carol, and Bill before David."  That specifies a partial order
for those "talk with X" process occurrences.

You also seemed to suggest something similar yourself when you
wrote:

  There is no way to specify an arbitrary partial order.  It wouldn't
  be hard to add one, given that every process occurrence can be
  referred to by its URI.

Perhaps "process occurrence" is the wrong phrase for me to use,
because when you explained that phrase, it sounded like it might
refer to instances of the expressions "(perform ...)" rather
than to the performances of the processes:

  We now encourage the term  _process
  occurrence_ to mean the occurrence of a 'perform' for that
  process in another, complex process.

-- Jeff

Received on Monday, 10 May 2004 10:02:38 UTC