W3C home > Mailing lists > Public > public-sws-ig@w3.org > November 2005

RE: Where are the semantics in the semantic Web?

From: Shi, Xuan <xshi@GEO.WVU.edu>
Date: Sun, 27 Nov 2005 13:29:25 -0500
Message-ID: <D81F456794C18B4DA3E2ABC47DBBEEF2094E57@onyx.geo.wvu.edu>
To: "'Bijan Parsia '" <bparsia@isr.umd.edu>, "Shi, Xuan" <xshi@GEO.WVU.edu>
Cc: "''drew.mcdermott@yale.edu ' '" <drew.mcdermott@yale.edu>, "''public-sws-ig@w3.org ' '" <public-sws-ig@w3.org>


-----Original Message-----
From: Bijan Parsia
To: Shi, Xuan
Cc: 'drew.mcdermott@yale.edu '; 'public-sws-ig@w3.org '
Sent: 11/26/05 6:04 PM
Subject: Re: Where are the semantics in the semantic Web?

On Nov 26, 2005, at 4:09 PM, Shi, Xuan wrote:
>> -----Original Message-----
>> From: Bijan Parsia
>> To: drew.mcdermott@yale.edu
>> Cc: public-sws-ig@w3.org
>> Sent: 11/25/05 4:53 PM
>> Subject: Re: Where are the semantics in the semantic Web?
>> On Nov 25, 2005, at 3:34 PM, Drew McDermott wrote:
>>>> [Shi, Xuan]
>>>> But where are your viewpoints and suggestions to my discussion in
>>>> http://lists.w3.org/Archives/Public/public-sws-ig/2005Nov/0089.html
>>> I think your proposals make perfect sense.  You want to replace WSDL
>>> descriptions with descriptions of web services with standard names 
>>> and
>>> standard argument-result protocols.
>> [snip]
>> Er...can't you do that *with* WSDL? WSDL describes service names and
>> argument results protocols. The abstract description can be bound to
>> many protocols and wire formats and be realized by many endpoints.
>> So, er...what's the diff?
>> Cheers,
>> Bijan.
> You may wish to read W3C's document "Web Services Architecture"

What makes you think I haven't? I was on the working group.

> at
> http://www.w3.org/TR/ws-arch/ and find the definition about service
> description and semantics.

Why don't you answer my question? If Drew's characterization of your 
view is incorrect, that's fine. Just say so.

> Here is the quotation for your reference:
> 1.4.3 Service Description
> The mechanics of the message exchange are documented in a Web service
> description (WSD). (See Figure 1-1) The WSD is a machine-processable
> specification of the Web service's interface, written in WSDL. It 
> defines
> the message formats, datatypes, transport protocols, and transport
> serialization formats that should be used between the requester agent 
> and
> the provider agent.  ... ...

This sounds like what Drew presented as your view:

"""You want to replace WSDL
descriptions with descriptions of web services with standard names and
standard argument-result protocols."""

> 1.4.4 Semantics
> The semantics of a Web service is the shared expectation about the 
> behavior
> of the service, in particular in response to messages that are sent to

> it.
> In effect, this is the "contract" between the requester entity and the
> provider entity regarding the purpose and consequences of the 
> interaction.
> ...... While the service description represents a contract governing 
> the
> mechanics of interacting with a particular service, the semantics 
> represents
> a contract governing the meaning and purpose of that interaction. 
> ......
> So why do we need to add "semantics" for Web services? Because those
> "message formats, datatypes, transport protocols, and transport
> serialization formats" do NOT "represents a contract governing the 
> meaning
> and purpose of that interaction".

Of course not, but they could serve as a basis for such. So you want to 
augment them with natural language descriptions? And other people would 
like to augment them with descriptions in formal languages.

> The efforts of adding semantic annotations on to the abstract WSDL
> interface, objects, elements, etc. may lead to the semantic chaos as
> mentioned in
> http://lists.w3.org/Archives/Public/public-sws-ig/2005Nov/0089.html
> sellTicket = buyTicket
> buyTicket = buyAirlineTicket
> sellTicket = buyAirlineTicket
> ... ... ... ...
> So you see the result and difference?

Not really. I don't buy your semantic chaos for a second. Really, it 
seems to be much ado about nothing at all. From the above email:

"""Actually, we can use either OWL-S or WSMO to describe such service
semantics. That's my suggestion to OWL-S and WSMO: remove any 
with WSDL grounding and merge diffferent parts into one single document
since people may wish to search the requirement of the input/output
variables. In this way, such service description can be used by either 
Web service or REST Web service.""""

Let's separate out the irrelevant: "One document" doesn't matter at 
all. There is no contrast between a "WSDL" web service and a "REST" web 
service because there is no such thing as a "WSDL service": WSDL is a 
*description* language and is quite capable (well, quite intended) to 
be able to describe "RESTful" services (see the HTTP binding; see the 
SPARQL protocol). With so much trivial nonsense, is there sense in what 
remains? Not that I see. I completely fail to see the harm in keeping 
groundings to WSDL. I don't really believe that the "sellTicket" above 
is the same as the others, but it's hard to tell from your brief 
description. But suppose it is. So what? They have different names. Big 
deal. If the capability description has them come out equivalent, then 
*yes* I want to know that. If their invocation conditions are 
different, then I'd like to know that too. Where's the chaos, much less 
the "semantic" chaos (are you using Drew's defintion, so this is good, 
helpful, friendly chaos?)?

(Clearly they aren't the same in all respects, but who said that we had 
to say that they were?)


""'2. the following WSDL (by SOAP) and REST (by HTTP/POST) Web services 
the same service request document and perform exactly the same function 
generate exactly the same result. 

I don't know what I'm supposed to see here. But I'll go by your 
description above. Their input and output messages are the same, and 
the function performed is the same, but the protocol is different. You 
don't need any annotation to WSDL to describe this. WSDL 2.0 can 
describe these services right now. There will be one interface with two 
bindings supported by two endpoints. Oooo, chaos. (not)

"""Please remember W3C defined Web service as "A Web service is a 
system designed to support interoperable machine-to-machine interaction 
a network". So we should develop something that can be used by either

WSDL and SOAP are not tied at the hip. They are distinct. WSDL can 
describe Plain Ole HTTP services as well.

""or any other ways for the interoperable machine-to-machine
interaction over a network."""

I think you are seriously confused. Sorry.

""" Adding semantic annotation onto WSDL cannot
match such requirement but may lead to semantic chaos and we should 
this potential problem.""""

And this is typical of your amazing leaps from nonexistent ground to 
hyperbolic conclusion.

Figure out what WSDL itself can do first.


P.S. I take this meets your challenge to "explain the logical conflicts 
as I mentioned in this thread." My response: there is no conflict, 
logical or otherwise. At least that I can see. If you are going to try 
again, I'd prefer you stayed achingly concrete and show the specific 
harms you envision, i.e., in terms of an actual error that would occur. 
Also, I strongly recommend you read up on WSDL (2.0) first, otherwise 
this will be quite pointless.

Check out the SPARQL Protocol:

Below is my discussion with Tim Berners-Lee which may be of interest to you
and many other people in the group. Hopefully Tim would not mind the release
for the purpose of public discussion.


> However, natural language can be hardwired so that computer can  
> process. 
> because what computer can do is based on what and how human design the 
> procedure. Thus if everything is well designed and defined, then 
> semantically markuped natural language can be a formal language  
> since it is 
> machine-processible. 

Well, yes, but that is rather beside the point. 
The core idea is the set of formal languages. 

Yes, you can make languages which are constrained version of a  
natural language syntax which has a mapping to a formal language, but  
the original language is not really a natural language then. 

Yes, you can mark up a bit of natural language to say what you think  
it means in a formal language, but you won't have a definitive formal  
definition of what it means, just an opinion. 

> Can we then say that machine processable, semantically markuped  
> natural 
> language is in the context of semantic Web according to your defition? 

If its meaning is defined to be the meaning of the formal markup,  
then yes. 

> Or 
> can we say RDF is a sort of semantically markuped natural language  
> since the 
> meaning of R-D-F as well as its content and definition are all  
> based on 
> semantic agreement defined in a natural language (English)? 

Tempting, but not useful. If you follow that path, all systems are  
defined in terms 
of English and therefore rest for their meaning on english words,  
which of course 
are imprecise, ambiguous, and time-varying in their meaning. 

In fact, though, formal systems, and also standards like vocabularies  
say iCalendar or online bank statement interchange, because they have  
defined by a mass of english which has been haggled over by various  
and interpreted by all kinds o published software and so on, have a much 
more well defined meaning than any one english definition would 
lead one to believe.  So, no, I would not say RDF is semantically 
marked up natural language in general. 

> Below is an example used in GIS Web mapping application for your kind 
> attention. Since it's machine-processable but also is a semantically 
> markuped natural language, can we say it belongs to the domain of SW 
> definition as this AXL file is designed for machine-processable  
> while human 
> understandable? 

Below you wrote: 

> <LAYER> 
>      <DATASET type="featureclass" name="roads_all_ahtd" visible="true" 
> workspace="shp_ws-0" /> 
>      <COORDSYS id="4269" /> 
> </LAYER> 

What does that mean?  This is not a natural language to me - it has  
no sentence structure, for example. 
Received on Sunday, 27 November 2005 18:29:16 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:54:15 UTC