

Re: OWL-S version 1.1 now available

From: Ian Dickinson <ian.dickinson@hp.com>
Date: Fri, 19 Nov 2004 23:04:59 +0000
Message-ID: <419E7C1B.9000704@hp.com>
To: public-sws-ig <public-sws-ig@w3.org>

Hello David,

David Martin wrote:
> A new release of OWL-S, version 1.1, is now available at
>   http://www.daml.org/services/owl-s/1.1/
> As noted on the release page, we encourage feedback from interested
> parties through the public-sws-ig@w3.org email list.
Well, since you asked, here are some thoughts from an initial 
read-through of the "OWL-S semantic markup for web services" white paper.

General comment is that this looks like a nice piece of work. Of course 
there are still things to do, but this is nevertheless a good step 
forwards from OWL-S 1.0.  Please take the following nit-picks in that 

* the text refers frequently to IOPE's, but the corresponding parameter 
is "hasResult".  Should that not therefore be IOPR? I notice, later on, 
that a some Results do have an effect, but I still claim it's confusing 
to a new reader.

* some of the figures, e.g. Figure 2, inappropriately use XML entity 
declarations - for example '&process;#Parameter'. Since these are not 
significant elements of the syntax, and only apply to an XML encoding 
(as opposed to, say, an N3 encoding), why not use the "namespace:name" 
q-name syntax instead?

* section 5.1 uses DRS as an example encoding of logical formulae but no 
reference is given for DRS

* section 5.2 "Conditioning Outputs and Effects" s/Conditioning/Conditional/

* also in section 5.2, the example isn't very credible because it 
implies the merchant has access to the customer's credit limit, and does 
the balance check themselves.  Wouldn't it be more realistic to say that 
the merchant requests the bank to authorise the payment?  Then you could 
concentrate on the real issue (two possible outcomes), rather than 
encoding the arithmetic for balance checking in the process 
specification, which otherwise rather muddies the distinction you are 
trying to suggest about the process model specifying rather than 
implementing the service.

* Figure 3 bleeds off the rhs of the page in A4 page setup

* in section 5.4, firefox (correctly) renders a <br /> after the <dt > 
element, so it appears as, for example

    : A list of control constructs ....

I suggest just removing the colons, they aren't necessary

* also in section 5.4, the Split+Join construct reads as "Split plus 
Join", but the class name, Split-Join reads confusingly as "Split minus 
Join".  I suggest just dropping the hyphens from the all names, 
especially as you already use inter-caps to distinguish word boundaries 
in other names

* also in section 5.4, there seems to be no syntactic difference between 
ControlConstructBag and ControlConstructList, so why not just make one a 
sub-class of the other?

* The example in section 5.5 starts out "Suppose we want a 
straightforward data flow: ...", and then goes on to outline a decidedly 
  *non* straightforward example!  In fact, I found it quite confusing. 
Part of the problem is that it's entirely abstract - I suggest replacing 
the example with something more realistic, as you do elsewhere in the 
other examples.

* also in section 5.5, there are some decidedly unnecessary inline 
images used to encode formulae.  Don't do this!  It violates all sorts 
of usability and accessibility guidelines, and it doesn't render 
properly in firefox. Maybe it does in IE, but in FF the vertical spacing 
is all out of whack.

* also in section 5.5, the example refers to the literal type 
"&xsd;Integer", which isn't a URI in the XSD namespace.  Should be 

* In section 6, you need to address how to map between URI's which OWL 
uses and WSDL doesn't, and XML q-name pairs which WSDL uses and OWL 
doesn't. I don't know if the TAG have resolved this yet, but I don't 
think there's a definitive mapping between them. If not, you should say 
how you expect this to happen.

* In Appendix B, the use of "shadow-rdf" is clumsy, and sounds a bit 
like grudgingly giving way on an issue you didn't really want to!  The 
namespace is .../generic/ObjectList.owl, so perhaps objList: or generic: 
would be more graceful namespace prefixes?

Hope that's helpful.

Ian Dickinson
HP Labs Bristol, UK
Received on Friday, 19 November 2004 23:05:42 GMT
