> [David Martin]
> Disclaimer: this summary represents my perspective and reflects my
> desire to avoid specifying (what I'm calling) "disambiguation
> declarations" in OWL-S knowledge bases. Other members of the OWL-S
> Coalition may have a different perspective.
I may be a little late paying my Coalition dues recently, and my OWL-S
magazine subscription has lapsed, but for what it's worth I agree with
David. There should be some clear sense in which a spec can be read
at the "document level," meaning that anything not mentioned in the
document can be assumed not to exist, and that, in certain contexts,
any two objects not declared to be equal in the document can be
assumed to be unequal.
Rationale:
* OWL-S competitors (e.g., BPEL) get to make use of such
pragmatic assumptions; why shoot ourselves in the foot?
* Programmers are going to write code as if the "document level"
existed. For instance, I came across a "howto" in some online journal
that talked about how to write code for the RDF and XML versions of
RSS (a notation for describing newsfeeds). The author made all sorts
of weird assumptions about the RDF, including the order in which it
would appear. He was clearly trying to pretend that the RDF version
was just a slightly hairier version of the XML version. The phrase
"closed-world assumption" had evidently never caused his brow to
furrow. We can poo-poo this all we want, but it would be better to
release an official "document level" semantics for RDF that codifies
the practice, so that unofficial versions don't proliferate.
* The argument has been made that when a proper surface notation is
devised, the clutter that David describes can be left out of it, and
inserted when translating to RDF. There are two bugs in this
argument: (a) anyone writing a program manipulating the RDF notation
is going to have to wrestle with the clutter; (b) it will be hard to
manipulate the RDF notation by hand without breaking it.
* Further elaboration of (a): The "rigorous" view of RDF assumes that
the norm is for the UNA and CWA to be false. In fact, 99.9% of the
time they will be true for notations such as OWL-S. So in practice a
program manipulating an OWL-S file the "right" way will simply check
for the presence and accuracy of the boilerplate asserting that the
list of inputs to a process is what it appears to be. If it isn't, it
will generate an error message and exit, because the average program
is just not equipped to reason about processes whose inputs and
outputs are underdetermined. If the boilerplate checks out, then the
program will proceed just like the program that ignores the
boilerplate. The net result is that we have one program (the
surface-to-deep translator) generating this junk, and another program
(the process reasoner) checking its accuracy and throwing it away.
Some human (Bijan Parsia has generously volunteered) will have to make
sure that these two pieces of useless code are correct and in synch.
The sane course of action is to insist that OWL-S be used only to
describe well-behaved processes. If someone wants to describe a
process about which only a few facts are known, they have to declare
it as a nonstandard document that may use the OWL-S ontology, but is
not to be taken as a routine process description.
--
-- Drew McDermott
Yale Computer Science Department