RE: Semantics of WSDL vs. semantics of service

Jacek,

Thanks for your explanation. If you agree that semantic annotations have no
direct relation with WSDL elements, then why don't you create a separated
and independent document to describe the *meaning* of your services? That's
just my suggestion which was proposed as the so-called OSRR approach for
SWS. I also demonstrated already that such approach can be deployed by
either SOAP or REST services without question.

Service semantics have no relation with WSDL-which can be deprecated as I
demonstrated in many other posted messages in this SWS-IG list. WSDL is full
of coding details about the abstract OOP interfaces for programmers. Those
three versions of ESRI's Address Finder Web Services as well as those
abstract cases for varied calculations are typical examples. 

That's why I asked you why and how could you explain the differences between
the two "matchType" elements in WSDL documents by RDF/OWL? It's meaningless
with regard to the service semantics. They are designed for programmers to
check whether something match whatever types for programming without any
relationship with the *meaning* of Web services. You can find many other
elements in WSDL documents of Address Finder Web Services that are all
meaningless to the service semantics, such as in the version 2006, you can
find such elements as:

<xsd:element name="desc1" nillable="true" type="xsd:string" /> 
<xsd:element name="desc2" nillable="true" type="xsd:string" /> 

in its version 2, "desc1" and "desc2" were called as:

<xsd:element name="description1" nillable="true" type="xsd:string" /> 
<xsd:element name="description2" nillable="true" type="xsd:string" />

Actually these two elements, however, do have specific *meaning* beyond
these tags. How could you know them? You have to check their Web sites to
see what they mean in programming, but not about the services.

Here you see again that the interfaces of WSDL keep changing but the meaning
of Web services keeps the same. Since geocode.us has a more simple business
model, its service interface is much simpler than ESRI's. However, the
meaning of address geocoding Web services can be the same for all service
providers. If your semantic annotations are based on WSDL, then you can see
a semantic chaos since WSDL documents are different. 

Although you claimed that you do not want to explain the meaning of the
elements in WSDL and your purpose is to tell something about the operation
that is performed when the appropriate message is sent, since your message
is based on WSDL document, then how can you ignore WSDL but focus on the
message exchanged? If that's true, then you just demonstrated that OSRR is
appropriate for SWS since OSRR only deals with the message for exchange
without any consideration about the framework (WSDL/SOAP) to deliver the
message.

I will be very grateful to you if you can add semantic annotations into the
WSDL documents of ESRI's Address Finder Web Services so that we can have
further discussion at the same base. You can just add a few annotations into
such living Web services to demonstrate such approach can help requesters to
understand the *meaning* of the service, not the meaning of WSDL elements,
and, the meaning of the same address geocoding services in these two
different versions are the same. You can find the WSDL documents at:

http://www.arcwebservices.com/services/v2006/AddressFinder.wsdl
http://arcweb.esri.com/services/v2/AddressFinder.wsdl

Thanks again for your time and discussion. 

Xuan


-----Original Message-----
From: Jacek Kopecky
To: Shi, Xuan
Cc: ''public-sws-ig@w3c.org ' '
Sent: 3/15/06 7:40 AM
Subject: Re: Semantics of WSDL vs. semantics of service

Xuan,

you seem to misunderstand the purpose of the semantic annotations in
WSDL. They are not meant to indicate what the <operation> element means,
instead they intend to tell you something about the operation that is
performed when the appropriate message (whose structure is described
within the <operation> element) is sent.

There is an actual service behind a WSDL file (this is a simplification,
there is a service behind a WSDL <service> construct, and maybe there's
functionality behind a WSDL <interface> construct), and the semantic
annotations intend to point to the semantics of the actual service.

Are you saying making such pointers is not possible or useful?

A bit more below.

Jacek

On Mon, 2006-03-13 at 11:42 -0500, Shi, Xuan wrote:
> 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.

I said earlier that the semantic annotations will *not* be different on
the different interfaces, exactly because the meaning of the service is
the same. The semantic annotations will show that the semantics are the
same. That's the purpose.

Received on Wednesday, 15 March 2006 16:36:28 UTC