W3C home > Mailing lists > Public > public-sws-ig@w3.org > March 2006

RE: Semantics of WSDL vs. semantics of service

From: Shi, Xuan <xshi@GEO.WVU.edu>
Date: Mon, 20 Mar 2006 23:03:36 -0500
Message-ID: <D81F456794C18B4DA3E2ABC47DBBEEF2094FCC@www.geo.wvu.edu>
To: "'Harry Halpin '" <hhalpin@ibiblio.org>, "'public-sws-ig@w3.org '" <public-sws-ig@w3.org>
Cc: "Shi, Xuan" <xshi@GEO.WVU.edu>

Harry,

On the contrary, I think my approach is much more closer to Semantic Web
than WSDL/SOAP. Here are the reasons:

1. Semantic Web is implemented over HTTP while WSDL/SOAP has to use SOAP
over HTTP. It's a duplication as we can bridge semantic Web with Web
services under the same protocol as I demonstrated already.

2. Semantic Web targets at defining the *semantics* within an HTML document.
If we reduce all type signatures to a single string input and single string
output in WSDL, we can then get rid of the framework (WSDL/SOAP) but focus
on the *semantics* of the message we exchange between the service provider
and service requester, i.e. the *semantics* within an XML document.

Here you see, in semantic Web, we exchange HTML document. In semantic Web
services, we exchange XML document. You can use your RDF/OWL tool to define
the meaning of your service, not the interface signiture of your service.
Since HTML and XML share the same ancestor SGML, it is easy for you or
someone else to find a way to set up a mechanism of standardized semantic
definition that can be used in either/both HTML or/and XML document. In this
way, we bridge the semantic Web and Web services under the same Internet
protocol within the same semantic description framework. 

In Jacek's typical example as <symbol>exmp</symbol> vs. <CompanyName>, if
you deal with the type signatures in WSDL, you try to use RDF/OWL to tell
requester about the Semantics of WSDL, however, the semantics of the service
is about <CompanyName>. So if you deal with the semantics of WSDL, you are
far away from the goal of semantic Web and semantic Web services.

Best regards,

Xuan

-----Original Message-----
From: Harry Halpin
To: public-sws-ig@w3.org
Sent: 3/20/06 3:36 PM
Subject: Re: Semantics of WSDL vs. semantics of service


One of the many goals of applying the Semantic Web to Web Services is to
provide a richer type signature for Web Services, while Xuan Shi is
proposing the opposite of this, reducing all type signatures to a single
string input and single string output. If one were using the Semantic
Web for input/output type signatures of Web Services, one could take an
address and returned a map ala (getMap(Address):Map). "Map" and
"Address" could then be defined by RDF. It seems Xuan Shi would rather
us have a single service (doService(String):String). One simplified
construal of Semantic Web Services instead could be viewed as
doService(XSDataType:RDFtype) -> XSDataType:RDFtype. One advantage of
the Semantic Web approach for type signatures is that one could then
find services via their type signature, while for Xuan Shi all services
have the same type signatures. Xuan Shi's proposal has nothing to do
with the Semantic Web as defined by W3C standards.

I think the problem is that Xuan Shi is on the *wrong mailing list.*
This workshop is about *Semantic Web Services*, which means trying to
standardize the application of the Semantic Web paradigm and data
formats to Web Services. This is a baseline assumption. E-mail to this
list that doesn't operate by this base-line assumption is off-topic, as
much as sending e-mail about Windows XP to a GNU/Linux User Group.  This
does not mean Xuan Shi's ideas might not be a good idea, but that the
proper forum for his ideas perhaps be one of the WS-* listservs (and
there's a lot) that is not applying the Semantic Web to Web Services. My
recommendation for Xuan Shi takes his approach to another, non-Semantic
Web, Web Services group and propose his version there. If both a
Semantic Web and Xuan Shi's solution get standardized and deployed,
market uptake will determine which ones are actually used. Since my
e-mail box is flooded by these off-topic e-mails (and rather snarky
replies) and they are actively prohibiting useful discussion by their
sheer volume, could a list-serv moderator please step in and make sure 
the discussion remains on-topic.



Shi, Xuan wrote:

>Jacek,
>
>I know there's a plethora of functions that are provided by Web
services,
>and we have to consider data format issues, etc. as service providers.
What
>I stressed is that, the interface designed for requesters can be
different
>from that for the providers. When service requesters send a request to
>service providers through the standardized interface
>(doService(String):String), service providers will then differentiate
which
>data types are specified within the service description document.
>
>For example, in a stock quote service, I send you the following
elements in
>the XML document,
>
>  <s:element minOccurs="0" maxOccurs="1" name="CompanyName"
type="s:string"
>/> 
>  <s:element minOccurs="0" maxOccurs="1" name="StockTicker"
type="s:string"
>/> 
>  <s:element minOccurs="0" maxOccurs="1" name="StockQuote"
type="s:string"
>/> 
>  <s:element minOccurs="0" maxOccurs="1" name="LastUpdated"
type="s:string"
>/> 
>  <s:element minOccurs="0" maxOccurs="1" name="Change" type="s:string"
/> 
>  <s:element minOccurs="0" maxOccurs="1" name="OpenPrice"
type="s:string" />
>
>  <s:element minOccurs="0" maxOccurs="1" name="DayHighPrice"
type="s:string"
>/> 
>  <s:element minOccurs="0" maxOccurs="1" name="DayLowPrice"
type="s:string"
>/> 
>  <s:element minOccurs="0" maxOccurs="1" name="Volume" type="s:string"
/> 
>  <s:element minOccurs="0" maxOccurs="1" name="MarketCap"
type="s:string" />
>
>  <s:element minOccurs="0" maxOccurs="1" name="YearRange"
type="s:string" />
>
>  <s:element minOccurs="0" maxOccurs="1" name="ExDividendDate"
>type="s:string" /> 
>  <s:element minOccurs="0" maxOccurs="1" name="DividendYield"
>type="s:string" /> 
>  <s:element minOccurs="0" maxOccurs="1" name="DividendPerShare"
>type="s:string" />
>
>although, they are all in string data types, but once you process the
>request, you understand which one is a string, which one is an integer
or
>double data type, which one is a date data type, in your programming.
In
>this case, you handle all such conversions on your server side.
However, for
>the service requesters, they just need to send you such a request
document
>without considering the data type issues.
>
>As I demonstrated before, I can invoke both geocoding and data
conversion
>services through such a standardized interface. As a service provider,
I
>know which elements are string data types in the programming, and which
ones
>are double data types. The requesters do not need to care about such
issues.
>In that example, I showed that two different kind of functions in
different
>web services can be implemented by one interface. That's the same
analogy in
>comparing to the case of consuming electricity via standardized plug
and
>receptacle. In my dissertation research, I developed different kind of
Web
>services for geocoding, data conversion, data processing, spatial query
and
>analysis, integrated mapping, etc. ALL of them just have the same
interface
>(doService(String):String). 
>
>Please describe any of your use cases, and let's see if such a request
can
>be sent through (doService(String):String) interface to the service
>provider. As I told Carine before, the service description template is
>pre-defined by service provider. Supposed you are a service provider
and you
>pre-define a service description template. If I send you such a request
>following your pre-defined templage, can you handle such a request to
>differentiate whatever data types embedded in such a document to match
those
>in your programming language? I wish you could try it first to see if
it is
>feasible to develop standardized plug and receptacle interfaces for all
of
>your services and functions.
>
>Best wishes,
>
>Xuan
>
> 
>
>-----Original Message-----
>From: Jacek Kopecky
>To: Shi, Xuan
>Cc: 'Bijan Parsia '; 'Carine Bournez '; 'public-sws-ig@w3.org ';
'Battle,
>Steven '
>Sent: 3/20/06 11:47 AM
>Subject: RE: Semantics of WSDL vs. semantics of service
>
>Xuan, 
>
>the problem is that Web Service interfaces are not so well standardized
>as electrical plug interfaces, and that's because there's a plethora of
>functions that are provided by Web services, as opposed to the one
>function provided by the electricity company.
>
>In particular, I don't expect that the interface of my stock quote
>service should match the interface of your address lookup service. Even
>if the operation is the same (doService(String):String), we will differ
>on the data formats and on what we actually perform. WSDL describes the
>data formats and WSDL-S tries to point to a description of what we
>actually perform.
>
>I'm afraid you have a simplified or idealistic view on what Web
services
>(should) look like.
>
>Jacek
>
>On Mon, 2006-03-20 at 09:56 -0500, Shi, Xuan wrote:
>  
>
>>It seems you all just ignore the title of this thread as "Semantics of
>>    
>>
>WSDL
>  
>
>>vs. semantics of service" and Bijan just could not answer my question
>>    
>>
>to him
>  
>
>>as why do I need to care about how many bindings he
>>has for one operation? Or, why do I need to understand the semantics
>>    
>>
>of his
>  
>
>>WSDL document?
>>
>>Given a simple example, we are all the consumers or service requesters
>>    
>>
>of
>  
>
>>certain electricity company. Do we need to care about the
>>    
>>
>infrastructure and
>  
>
>>the framework of the electricity company before we consume such
>>    
>>
>service? Do
>  
>
>>we need to care about how many bindings the electricity company has,
>>    
>>
>and,
>  
>
>>how they switch to any other bindings to maintain its operations to
>>    
>>
>support
>  
>
>>the service it provides? Definitely not!
>>
>>As service providers, can we give more consideration for our service
>>requesters? We can consume the electricity in the same interoperable
>>appraoch because every plug and receptacle are all standardized. In
>>    
>>
>that
>  
>
>>way, the service requesters do not need to care about your complex
>>infrastructure, framework, logics, etc. People access "Web" services
>>    
>>
>in the
>  
>
>>same situation.
>>
>>So, please encapsulte all troubles into your server side development.
>>Service requesters only need one standardized receptacle so that they
>>    
>>
>can
>  
>
>>use any interoperable plug to consume the service with little
>>    
>>
>question. They
>  
>
>>don't need to know how many bindings you have to maintain your single
>>operation. We are service providers, not trouble makers.
>>
>>-----Original Message-----
>>From: Bijan Parsia
>>To: Jacek Kopecky
>>Cc: Carine Bournez; public-sws-ig@w3.org; Battle, Steven
>>Sent: 3/20/06 8:09 AM
>>Subject: Re: Semantics of WSDL vs. semantics of service
>>
>>
>>On Mar 20, 2006, at 5:39 AM, Jacek Kopecky wrote:
>>
>>    
>>
>>>Hi Steve,
>>>
>>>while the charter does not directly support embedded semantic
>>>annotations, I think the issue is still open and up for discussion
>>>      
>>>
>by
>  
>
>>>the WG.
>>>      
>>>
>>I went back and looked and the Scope section is a bit broken (as 
>>evidenced by Steve's quote):
>>
>>"""The Semantic Annotations for WSDL Working Group is chartered to 
>>define one or more properties of WSDL 2.0 components to point to 
>>additional semantics to concepts represented by those components, e.g.
>>    
>>
>
>  
>
>>interface, operation, endpoint. Additionally, the Working Group may 
>>define annotations to the schema structure to point to external 
>>semantics.""""
>>
>>"point to additional semantics to concepts" just doesn't parse. 
>>Additional semantics *for* concepts represented?
>>
>>I confess to hating the term "external semantics". C'mon.
>>
>>    
>>
>>>I for one see some use cases where embedding the annotations would
>>>      
>>>
>be
>  
>
>>>useful, and I can see at least two ways of embedding them: put a
>>>      
>>>
>whole
>  
>
>>>semantic description
>>>      
>>>
>>I go back to a fight I had in SWSL. What's a *non* semantic
>>    
>>
>description?
>  
>
>>> document somewhere in the WSDL document (like we
>>>put schemas in the <types> section) and then the annotations will
>>>      
>>>
>>point
>>    
>>
>>>into the document; or put the full annotations themselves on the
>>>      
>>>
>spot,
>  
>
>>>instead of referring to them.
>>>      
>>>
>>How are the "semantics" to be realized? Via some sort of statement 
>>(e.g., axioms in some formalism). So let's say I have a set of concept
>>    
>>
>
>  
>
>>and property names, but no further axiomization. And I want to say of 
>>some operation that is has at least one P relation to a C. Now since 
>>there *is* no other axiom, this characterized the terms entirely (thus
>>    
>>
>
>  
>
>>far). May I inline that? It seems like I should be able to. 
>>Alternatively, I could require that I always coin a name for these 
>>intermediate expressions (but why?).
>>
>>(Note that originally I interpreted the discussion as requiring *all 
>>parts* of the annotation to be outside the WSDL document, a la OWL-S. 
>>There are reasonable reasons for doing this (including supporting
>>    
>>
>third 
>  
>
>>party and alternative annotations seamlessly. Technically, I guess
>>    
>>
>this 
>  
>
>>is not ruled out by the current charter since the concrete syntax of 
>>the component properties could be or be required to be in a separate 
>>document.
>>
>>    
>>
>>>While the second option can be seen as out of scope as defined in
>>>      
>>>
>the
>  
>
>>>charter, at least the first option should be available to us. 8-)
>>>      
>>>
>>I find the Out of Scope more disturbing:
>>
>>"""discuss expression of Web services constraints and capabilities, 
>>including precondition and effect."""
>>
>>Why? And how can this be at all narrowed? I mean, from the scope, " 
>>could have different meanings: calculation of tax on a product, 
>>calculation of income tax, etc. " Aren't these expressions of 
>>capabilities? (I recognize that constraints and capabilties are a term
>>    
>>
>
>  
>
>>of art standing for "policy", but still.)
>>
>>Cheers,
>>Bijan.
>>
>>
>>    
>>
>
>  
>
Received on Tuesday, 21 March 2006 04:03:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:32:52 UTC