Re: OWL-S version 1.1 now available

Hi Ian -

I also appreciate your comments.  I agree, in general, with respect to 
your formatting and readability suggestions, and I will follow them in 
the next incarnation of this document.  We won't be able to make any 
fixes to this particular version (1.1), however, because nowadays we are 
trying to be good engineers and actually freeze the materials once the 
release has been announced :-).  However, I'm very soon going to set up 
a development workspace for the 1.2 release, and I'll certainly be happy 
to make these changes in that location.

Here is one more quick response -

Ian Dickinson wrote:

> 
> 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 
> context!
> 
> * 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
> 
> Sequence
>    : 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.

These are only there because, well, time is finite.  This document was 
derived from an HTML document generated by a program called latex2html, 
which made heavy use of inline images.  I completely agree that these 
are unnecessary, but in the rush of millions of details it seemed pretty 
low priority to eliminate them.  I didn't realize that they wouldn't 
render properly in firefox.  Now that that is known, it becomes a much 
higher priority.

(However, at the same time, I'm a little surprised that the use of 
inline images violates useability and accessibility guidelines.  That 
seems unfortunate, because it's not hard to imagine situations where 
you'd want to use inline images that were not unnecessary.)

> 
> * 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 
> "&xsd;integer"
> 
> * 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.

Very good point.  I don't know the answer to this either, but we'll look 
in to it.

Anyway, thanks again.  I'll give another reply when I actually make 
these changes to the 1.2 version; that is, if there are any substantive 
remarks to be made.

Regards,
David

> 
> * 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.
> Regards,
> Ian
> 
> Ian Dickinson
> HP Labs Bristol, UK
>

Received on Saturday, 20 November 2004 00:49:54 UTC