[DAML-S] Processes As Properties (PAP)

This is a fairly rough and "thinking aloud" (while procrastinating 
during an all nighter).

We have processes as classes, and processes as instances, but no one's 
articulated one of the standard ways to represent programs, plans, etc. 
in DLs -- processes as properties. I shall now do so.

Desiderata in a Process Ontology
---------------------------------------------

So, what might we want from the Process Model *ontology*?
	1) Ease, naturalness, and bulletproofness of represenation. I.e., we 
can work with it. This 	     might include syntactic friendliness, but 
that's perhaps the least important.
	2) Expressive efficiency, i.e., we should express as much as we can 
given the limitations
	    of the formalism selected (in this case OWL/DAML+OIL).
	3) Expressive forward compatibility, i.e., we shouldn't overabuse the 
expressive power
	    of our current language at the cost of making any extensions in a 
more expressive
	    formalism painful or even impossible. Best would to have a some 
idea how the
	    extensions should go.
	4) Reasoning support, i.e., we should know what sorts of reasoning 
services are required
	    or usable, and how to effectively produce representations that 
make good use of them.
	    One example of where DAML-S had problems is with the Ian problem 
wrt matchmaking.
	    Some services we might desire: Plan/process generation, 
verification, type checking,
	    deadlock and resource analysis, or classification.
	5) Nailed semantics. The ontology should actually (help) *determine* 
the meaning of the
	    model, sufficient both for reasoning about the models (both by 
humans and programs)
	    and for *implementing* the process model (or specific processes).

There's some tension between a process *model* (language) and a process 
*ontology*, though, not a strong one (that I'm comfortable with). 
Currently, the *semantics* of the model is given almost entirely out of 
band from the ontology (IMHO). At least the interesting semantics.

Processes as Properties
---------------------------------

The fundamental notion is that properties represent transitions between 
*states* (represented by individuals). *Classes*, then, become 
preconditions of the transition (i.e., what has to be *true of* the 
state before the transition can occur). In the standard mapping, this 
restricts the precondition language to *propositions*, e.g., 
(haveGoodCredit & wantToBuyHarryPotterBooks) (propositional and, or and 
not correspond to owl:intersectionOf, owl:unionOf, and 
owl:complementOf).

Suppose we have an AtomicProcess buyHarryPotterBooks. (I'm not clear 
why, but Harry Potter seems to be the canonical example. I guess, at 
some point, I should resist this!) The preconditions of this process 
are as above. We can represent this in OWL as (using faux n3 notation, 
not dotting every i, etc.):

	:buyHarryPotterBooks a owl:ObjectProperty;
		rdfs:domain :BHPBPreconditions;
		rdfs:range :BoughtHarryPotterBooks.
	:BHPBPreconditions a owl:Class;
		owl:intersectionOf
			(:HaveGoodCredit,
			 :WantToBuyHarryPotterBooks).

Suppose I want to chain this with another AtomicProcess, 
:shipHarryPotterBooks, represented as:

	:shipHarryPotterBooks a owl:ObjectProperty:
		rdfs:domain :SHPBPreconditions;
		rdfs:range :ReceivedHarryPotterBooks.

	:SHPBPreconditions a owl:Class;
		owl:intersectionOf (:BoughtHarryPotterBooks,
						owl:complementOf(:ReceivedHarryPotterBooks).

If :SHPBPreconditions are a subclass of  :BoughtHarryPotterBooks, which 
they are, then I can verify that
	:x :BuyHarryPotterBooks :y :ShipHarryPotterBooks z.

Ugh. These preconditions, etc. aren't the happiest, but I hope the idea 
is clear.

If we assume :x, :y, and :z represent fairly particular situations, 
with some particular details, we can still represent the sequence in 
general as another class expression (apologies for the slightly bogus 
owl):

	:BuyAndShipHP a owl:Class;
		rdfs:subClassOf
			[a owl:Restriction;
			owl:onProperty :buyHarryPotterBooks;
			owl:cardinality "1";
			owl:allValuesFrom [a owl:restriction
				owl:onProperty :shipHarryPotterBooks;
				owl:cardinality "1"]].

:x will be a member of this class.

This is a bit cumbersome, but perhaps more expressive than I worried, 
given the lack of role constructors which generally are used to 
represent control constructs like sequence (role chaining), if then 
else, etc. I suspect, though I have to think about it, that adding the 
more expressive constructs (which could be straightforwardly done) 
wouldn't invalidate this more primitive representation, but rather 
subsume it in a natural way.

Thus, far, the hideous pain of this method is the lack of 
parameterizability. Both the preconditoins and the processes themselves 
are brutually primitive, as exemplified by their names. Clearly, we 
want generic :buyBooks and :shipBooks processes that have a parameter, 
preferably one shared with the preconditions.

So, at this point, there are two paths: 1) move to a more expressive 
formalism wherein the enrich descriptions are straightforward 
elaborations of the above descriptions, or 2) try to force a bit more 
expressivity out of OWL. While I see a clear path for the control 
constructs, I'm not as clear on this issue. So I'll punt on that for 
the moment and try for 2.

One part of OWL that's untouched, in some sense, are 
DatatypeProperties. It seems a bit odd to consider a data *value* as a 
"state" (and you can't transistion out of it, anyway), so it seems like 
we might be able to use DatatypeProperties for something else. How 
about inputs and outputs?

Let me assume for the moment that we're only representing inputs and 
outputs that take XML Schema datatype values. This is not  a *huge* 
deal as this roughly corresponds to the vast majority of WSDL out there 
and likely to be out there. (We do have a mechanism for converting XML 
Schema values to OWL instances, but I'm suggesting *not* to do that.)

So, maybe something like:
	buyBook:bookTitle a DatatypeProperty;
		rdfs:subPropertyOf owl-s:Input;
		rdfs:range &xsd;string.
	buyBook:invoiceNumber a DatatypeProperty;
		rdfs:subPropertyOf owl-s:output;
		rdfs:range &xsd;nonNegativeInteger.
	shipBook:invoiceNumber a DatatypeProperty;
		rdfs:subPropertyOf owl-s:input;
		rdfs:range &xsd;nonNegativeInteger.

		:BuyAndShipBook a owl:Class;
		rdfs:subClassOf
			[a owl:Restriction;
				owl:onProperty :buyBook;
				owl:cardinality "1";
			owl:allValuesFrom [
			    intersectionOf
				([a owl:restriction
					owl:onProperty :shipBook;
					owl:cardinality "1"];
				[a owl:Restriction
					owl:onProperty buyBook:invoiceNumber;
					owl:cardinality "1"]
				[a owl:Restriction;
					owl:onProperty shipBook:invoiceNumber
					owl:cardinality "1"]);
		rdfs:subClassOf
			[a owl:Restriction #This puts the bookTitle parameter on the 
*intial* state
				owl:onProperty buyBook:bookTitle;
				owl:cardinality "1"];

This class would apply to the initial state of a computation. One 
conforming example:

	:x a :BuyAndShipBook;
		buyBook:bookTitle "Harry Potter and the Something Something";
		:buyBook :y.
	:y :shipBook :z;
	    	buyBook:invoiceNumber "12345";
		shipBook:invoiceNumber "12345".
.
If I made buyBook:invoiceNumber and shipBook:invoiceNumber equivalent 
properties (or subproperties of the same property), then the 
cardinality constraint would force them to have the same value. This 
might lead to undesirable proliferation or properties, but hey. If we 
allow distinct classes of properties (such that transition/processes 
properties are distinct from input/output properties), then we could be 
a *little* sneakier by restricting them to hasValue the same individual 
that has an rdf:value of a certain type.  (I'm not sure about this, 
actually, but hey, it's 3:15am :)) And if we do that, then perhaps we 
can lift the class membership restriction on preconditions.

One could imagine, I think, changing this a little to represent petri 
nets. I'm unaware of any literature on Petri nets in dls, but I didn't 
look either :)

Evalution
-------------
Clearly this isn't a fully worked out proposal. I've made it in an 
effort to stretch my head as to the range of possible modeling 
techniques for Processes. I don't think this nearly exhausts it, but it 
seems interesting similar and different from the PAC and PAI proposals, 
though it bears some similarities to both. Some advantages:
	1) It preserves a natural process/trace connection.
	2) It's somewhat less nasty to write or think about than PAC, though 
perhaps not quite as 	     friendly (in some respects) as PAI. It may 
be more friendly in other respects than PAI. The 	     problem of 
nesting still occurs.
	3) It seems possible to represent in OWL DL.
	4) It seems possible to represent (and *specify*) sequence, choice, 
and perhaps loops. More
	    can be done with straightforward enhancements to OWL.
	5) It can (might be able to) represent the dataflow.
	6) It seems like classifying such process descriptions might be 
useful, though I'm unable to
	    give a concrete example at the moment.

Some disadvantages:
	1) Sequences aren't closed without more work.
	2) Still a bias toward propositionality, which is wretched, though 
there are some further
	     tricks I've not explored.
	3) We're all Sick Of Class Expressions, especially complex ones.
	4) Unclear that the tricks fit in with more expressive formalisms.
	5) Might still require OWLFullness, for some parts.

Other things I'm sure.
(Thanks to Evren Sirin for some comments and brainstorming.)

Cheers,
Bijan Parsia.

Received on Thursday, 21 August 2003 19:21:19 UTC