Re: OWL-S process preconditions

There's been a smattering of discussion about use of literals for
conditions in Owl-S, and I'm not sure how to summarize it.  Anyway,
Gerhard Wickler asked --

> The difficult part then will be to define the formal semantics of 
> preconditions and effects. How are you planning to do that? Are you 
> thinking of an approach similar to reification in RDF?

And Jason Kopecky said something similar --

> Hi all, I've only been lurking here, but on this point I have a newbie
> question: wouldn't reification be a better tool than reparsing of
> literals? The amount of work for the implementations would be the same
> but it would seem to me to be much cleaner from the data modeling point
> of view - for instance when serialized as n-triples, the literal
> approach would keep XML syntax intermixed with the n-triples, whereas
> reification would have everything as n-triples.

To which Gerhard somewhat oddly replied --

> Good point. I agree that having RDF/XML as the content language (using 
> reification) looks like a good idea, especially because it answers my 
> semantics question, but I suspect two major problems here:
> 
> 1. RDF/XML has no notion of variables in triples. Of course, this could 
> be fixed somehow, but some of the cleanlyness of this appraoch would be 
> lost along the way.
> 
> 2. RDF/XML *essentially* allows for conjunctions of (positive ground) 
> triples, which does not provide for much expressiveness.

At some point Bijan Parsia jumped in with some common sense, but
perhaps phrased a bit obscurely :).  Let me express it my way:

Starting with the issue of "formal semantics": If we allow several
different notations for preconditions and effects, then they will all
come with their own formal semantics, no?  Then there will be two
additional issues:  How do the variable values get transmitted across
the language border, and what does it mean for a formula to be a
condition or effect of an action?  I can't for the life of me see what
either of these questions has to do with reification in RDF.

The last of Gerhard's message cited above sounds very dated.  The SWRL
language (and others, like DRS) is specifically aimed at (a) using RDF
to encode rules, reifying the atomic formulas; (b) adopting a
convention for variables; and (c) using its encoding technique to get
around the inexpressivity of RDF.  Making all this work requires
suspending the normal interpretation rules for RDF and replacing them
with versions that take variable values into effect and treat And,
Ors, Nots, and Foralls the right way.  Unfortunately, when you're done
all you've succeeded in doing is finding a long-winded way to pretend
to use RDF, although it does have the virtue that certain things, like
resources references, survive the shake-and-bake processing described.

There are two reasons we Owl-S people decided to wrap the magic word
"Literal" around formulas: (1) We decided that on balance more was to
be gained by letting a hundred flowers bloom.  If you want everything
to look like RDF or XML, you can do that.  If you would rather write
the same thing in predicate calculus, why shouldn't you be able to?
It's trivial to derive the RDF from the logic if you have some use for
it later. (2) As Bijan said, there is a slight chance that a SWRL
processor, finding a SWRL formula floating in a sea of triples, might
mistake it for a rule and assert it.  Putting it inside a literal
prevents that.

-- 
                                             -- Drew McDermott
                                                Yale University CS Dept.

Received on Tuesday, 22 June 2004 11:52:13 UTC