RE:

Jacek,

Dr. Martin is unhappy to see that I messed up his original thread so I
replied to you separately. What I mentioned previously is that adding
semantic annotations into WSDL is a way to explain the meaning of WSDL,
other than the meaning of Web services. Given the example of ESRI's Address
Finder Web services, by now it has three versions with different WSDL
interface definition. However, the meaning of this service keeps the same in
three different versions. So if you add semantic annotations into WSDL, it
just describes the meaning of the interface, not the meaning of the service,
especially considering most of the interface definitions in WSDL have
nothing related to the *meaning* of this service. In this case, your
semantic annotations will be different since the interfaces are different,
but the *meaning* of the service has been the same in three different
versions.

My suggestion is to separate service semantics from the service development.
In this way, we can share the service semantics among different service
providers. For example, geocode.us also provides a FREE address geocoding
Web service but has different business logic from ESRI's paid service. In
this case, the fundamental service semantics are the same. You can see from
these examples as well as those abstract cases of addition services that,
service semantics are neutral and independent with no relation with
interface definition in WSDL.

Moreover, given the example of calculations services, the meaning of the
input varialbes in addition/multiplication and subtraction/division is
different. In addition/multiplication function interfaces:

function addition/multiplication (double x, double y):double z

since x+y=y+x and x*y=y*x, you can then ignore the order of the input
varialbes.

However, in subtraction/division functions, you have to consider how to let
the requester know that your service will do something like x-y or x/y other
than y-x or y/x. When we put all four functions in one service WSDL
document, as Dr. Martin was concerned, how can we tell the questers that
this 'x' is different from that 'x', considering we can develop such
function and services in different ways?

By separating service semantics from interface description, we can ignore
such issues and focus on the *meaning* of the services. What programmers
need to do is to associate their programming interfaces with service
description documents. In this case, whatever and however they change their
business logics or interfaces like ESRI's three different version of
services, if the service semantics are the same, requesters do not need to
change anything at the client's side based on the service description
document, which can also be shared by either SOAP or REST services.

In conclusion, I think the meaning of WSDL is not the meaning of the
service. Adding semantic annotations into WSDL is helpful to understand WSDL
but not the meaning of the service which can be neutral and shared by all
service providers who provide the same kind of services and functions, like
ESRI and geocode.us, and be deployed by either SOAP or REST services.

Best wishes,

Xuan

P.S. 

Please check the following living Web services in different versions, the
latest ESRI's Address Finder Web Service's WSDL file at
http://www.arcwebservices.com/services/v2006/AddressFinder.wsdl 

and its 2nd version at:
http://arcweb.esri.com/services/v2/AddressFinder.wsdl

The "findLocationByAddress" function of the Address Finder Web services in
version 2006 was called "findAddress" in the 2nd version of Address Finder
Web services. Please check both documents and see if at least 3/4 of the
interface defitions in the WSDL document are meaningless and have nothing
about the *meaning* of this function and service - they are actually the
product of object oriented programming, such as the two matchType elements
(do you want to explain in RDF/OWL what's the difference between them?),
locationInfo, or GeocodeInfo, bla, bla, bla... These are all coding details
for programmers to retrieve the value of geocoding result, but have NO
relation with the *meaning* of Web service.


-----Original Message-----
From: Jacek Kopecky
To: Shi, Xuan
Cc: 'David Martin '; 'public-sws-ig@w3c.org '
Sent: 3/13/06 9:52 AM
Subject: RE: question about "Semantic Annotations for WSDL"

Xuan, 

I disagree with your point that WSDL has NO relation to the semantics of
the service. If the service does something (like addition), the WSDL
will likely have at least one operation that accepts a set of numbers
(in some way) and produces one number. Granted, an addition operation
modeled in multiple environments will be syntactically different, even
very different. 

But I believe that you must acknowledge that the WSDL is built from the
semantics of the service. Therefore, provided we can describe the
semantics and give a URI to them, we can also point from WSDL to that
URI using modelReference (WSDL-S construct), and in an ideal situation
two different WSDLs for addition operation will both point to the same
addition operation semantic description, and an automated tool can
assume that the operations are functionally interchangeable.

Resolving the syntactical differences between the two WSDLs is done by
what we call grounding from the semantic level to the XML level in WSDL,
and it will not be trivial, of course, but it's being worked on and I'm
not aware of any show-stopper problems. With proper grounding, it should
be possible for one agent to be able to invoke either of the addition
services (or any newly discovered ones) automatically if it wants to
perform addition.

Do you still think that WSDL annotations pointing to semantics cannot be
useful? If not, do you have any alternatives?

Best regards,

Jacek

On Mon, 2006-02-27 at 22:07 -0500, Shi, Xuan wrote:
> Dear Dr. Martin,
> 
> If you and this group would like to discuss the semantics of WSDL
other than
> the semantics of Web service, then you can ignore the following lines
> because I will demonstrate again that the meaning of the
element/component
> within WSDL interface document is NOT the meaning of Web service.
> 
> Given a simple example, a Web service provides a function of addition
> calculation. How many different ways can we try to build such a
function? I
> can give a list of functional interfaces as I discussed before, and
you may
> wish to add more:
> 
> Function addition (integer X, integer Y):integer Z
> Function addition (double X, double Y):double Z
> Function addition (integer X[2]):integer Z
> Function addition (double X[2]):double Z
> Function addition (number X, number Y):number Z
> Function addition (object O):integer Z (O has properties X, Y, or O
has
> X[2])
> Function addition (string req):string resp (by SRR document)
> ... ...
> 
> What's the meaning of this service and function? The meaning of
service and
> function has any relationship with WSDL interface, process,
precondition,
> effect, etc.? 
> 
> As a common sense, the meaning of ALL such Web services is the same:
it will
> add two numbers and return the result back to requester. When you add
> semantic annotations into WSDL, can you describe the meaning of this
Web
> service?
> 
> Let's change the function name into subtraction, multiplication,
and/or
> division. Then all elements in the WSDL document are the same except
the
> name of the function. Should you want to clarify that the X variables
used
> in every different function are all the same or not? It seems you
still care
> more about the name of the element inside a WSDL document, not the
meaning
> of Web service.
> 
> Let's design another Web service that will perform mixed calculation
by
> using the above four Web services. While we can design the interface
of such
> a service and function in many many different ways, the meaning of
this Web
> service is: if requesters send a number sentence to provider, the
provider
> will send back the result of the mixed calculation.
> 
> Do you think the provider should tell requester that the provider will
> aggregate one or more Web services (addition, subtraction,
multiplication,
> division) in the OWL-S approach, or how the provider will mediate the
four
> Web services in WSMO approach, to generate the result? 
> 
> In conclusion, the meaning of Web services has NO relation with both
of the
> WSDL interface and the aggregation/mediation process. Then I don't
think
> it's worthy to add semantic annotations for WSDL since such activity
cannot
> lead to the goal of semantic Web services.
> 
> Best wishes,
> 
> Xuan
> 
> 
> 
> -----Original Message-----
> From: David Martin
> To: public-sws-ig@w3c.org
> Sent: 2/27/06 6:59 PM
> Subject: question about "Semantic Annotations for WSDL"
> 
> Here is an important question about the proposed "Semantic Annotations
> for WSDL" working group, about which I'd love to see some discussion.
> 
> The current draft charter is here:
>    http://www.w3.org/2005/10/sa-ws-charter.html
> 
> Question:
>      Does the envisioned approach provide a foundation that will be
>      useful in working with, or evolving to, a more comprehensive
>      framework, or simply a detour that will ultimately fall out of
use
>      (if Web service semantics become important)?
> 
> What's behind this question is the observation that, from a
> WSDL-centric perspective, the semantic artifacts referenced by a WSDL
> spec will be disconnected.  That is, from the point of view of a WSDL
> tool, they won't exist in the same declarative scope. (Indeed, in this
> approach there is *no* notion of declarative scope for the semantic
> artifacts, from the WSDL perspective.)
> 
> One way to illustrate this concern is simply by observing that
> preconditions and effects associated with services will frequently
> have variables in common.  To have a coherent representational scheme,
> it is of fundamental importance to spell out the relationship between
> variable X mentioned in a precondition and variable X mentioned in an
> effect expression.  From the perspective of a WSDL tool, there won't
> be any basis for establishing or working with such a relationship.  So

> the concern here is that a WSDL tool ultimately won't be able to do
much
> 
> with the semantic declarations that are referenced.
> 
> Of course, the semantic framework underlying those declarations may
> provide the basis that ties the semantic declarations together, and a
> WSDL tool could build in some understanding about one or more of the
> semantic frameworks that may be used in connection with WSDL.  But the
> point is that it's not a WSDL tool anymore - it's a WSDL tool plus a
> {UML or OWL-S or WSMO or SWSF or METEOR-S or ODESWS or ...} tool.  And
> as far as I can tell, there won't be any meaningful connection between
> the two tools.  The concern is that the proposed approach does not
> appear to provide any path by which such a meaningful connection might
> eventually be achieved.
> 
> Cheers,
> David Martin
> SRI International
> 
>

Received on Monday, 13 March 2006 16:42:38 UTC