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

Re: Is there any logical conflict between the semantics in SW and that in SWS ?

From: Bijan Parsia <bparsia@isr.umd.edu>
Date: Sun, 27 Nov 2005 13:44:55 -0500
Message-Id: <ff6203f93adc5215d12ca90b3c47c661@isr.umd.edu>
Cc: SWS-IG <public-sws-ig@w3.org>
To: "Shi, Xuan" <xshi@GEO.WVU.edu>

On Nov 27, 2005, at 1:12 PM, Shi, Xuan wrote:
> We may have certain agreement on our discussion if you would read our  
> paper
> "Rebuilding the Semantic Web Service Architecture" at the Web site:
> http://sunsite.informatik.rwth-aachen.de/Publications/CEUR-WS//Vol 
> -140/ item
> #3. The examples discussed in this paper demonstrated that machines  
> have the
> ability to correctly intepret services WITHOUT human (programmer)
> intervention, i.e. automatic service discovery, matchmaking,  
> composition,
> and invocation. By adding or removing the Web services in the listbox  
> in
> that example, computer can "understand" whether it can perform certain  
> tasks
> and/or dynamically invoke the required service (if exists) for certain
> purpose.

I don't see how this supports any of your stronger conclusions, esp.  
about sematnic chaos. But let's look at your paper;

page 3:

"Semantics of web services are tied to names given to functions and  
arguments in  WSDL. They are not derived from any standardized  

What would it be to derive them from a standardized ontology? Or just  
from an ontology? Do you mean that there should be a prior ontology of  
services that we align our descriptions with? Who curates this? Why  
only one? Why one grand one? Why a prior or standardized one? Am I  
reading too much into this sentence?

" This fact is a source  for confusion, as meaning of the services has  
to be guessed. "

I don't understand this *at all*. So I name a service and I type it's  
arguments. I write down these facts in a natural language for the  
users. To use my service, they must read my documentation and act  
accordingly. It's error prone and a PITA. So, I express these facts in  
an interface definition language like, oh, say, WSDL. It does the job I  
want it to do, e.g., generate stubs for usage. Now I want to make my  
service more broadly accessible and I want to document it better. So I  
write a description in natural language including all sorts of yummy  
stuff, like what the purpose is, how much we charge for it, the fact  
that it requires prior registration and a credit card number, etc. Ok,  
that's nice. But I have the same problem as before: It requires a lot  
of human intervention even on the crappy bits. So, I try to express at  
least some of these facts in a formal language, say OWL, but it could  
be F-Logic, or whatever. I need a bit more than OWL alone, since I want  
to express preconditions and effects, but ok. I do this. Other people  
have a better time dealing with my stuff if I connect my description to  
other people's, typically via some common ontologies.

The only thing I see (from a quick skim) is that you want homogenous  
invocations, a la REST, with elaborate semantics embedded in the  
messages exchanged (self describing). Well, ok, this is hardly a  
revolution. But it has absolutely no traction whatsoever. So it seems  
like a non-starter to me.

> However, remember Uschold implied that what and how machine can process
> depends on what and how human designs the procedures. To enable such
> automation in semantic Web services, we need agreements or standards  
> for
> implementation.

I don't see anyone denying this at all.

> The idea of separating service description from any technology for  
> service
> development originated from the concept of knowledge engineering in the
> domain of AI.

Not really. I mean, SOA like abstraction has been around for a while.

>  I cannot understand why people with AI background cannot see
> its root.

Even if we could, doesn't mean we'd agree that it was a good idea.

> Maybe I used an old book "Artificial Intelligence - A Modern
> Approach" published by Prentice Hall in 1995 ISBN # 0-13-103805-2. On  
> page
> 219,

I have it and like it. 3rd edition is v. nice.

>  it describes the difference between knowledge engineering and
> programming.

Yes, patronizing us really helps build good will. Can you try to absorb  
some of the push back? Understand it? Respond critically?

> Here it's the same analogy in semantic Web services. Service  
> description is
> a process of knowledge engineering while service development is a
> programming process while WSDL contains the coding details as the  
> result.

Not really. At least, I don't think so. There are different levels of  
abstraction we're dealing with.WSDL may, in some sense, be "closer to  
the metal", but it's pretty abstract.

>  I
> hope Dr. Parsia

I'm not a doctor.

> could calm down

That I am irate doesn't mean that I'm not on point. I don't see you  
responding at all to my reponses.

>  and see the difference and let us know if
> such an analogy is correct or not, and if such separation will enable  
> the
> service description document being implemented by multiple ways besides

And since you still conflate WSDL and SOAP I see little evidence that  
discussion is happening.

Received on Sunday, 27 November 2005 18:44:55 UTC

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