Re: sws matchmaker contest

In his article "It's the Programming, Stupid", IEEE Internet Computing, "Peer to Peer", May/June 2006, Dr. Petrie wrote "If semantic technology has a future - and I’m sure that it does - it’s in software engineering." In software engineering lifecycle (requirement analysis, specification, implementation, testing and maintenance), the location for ontology/semantic definition is in the process of "specification", not in the process of implementation, because the same one specification can be implemented in different ways.

In his discussion regarding the dynamic invocation of Web services many times, Dr. Burstein also said (2004) "various services that do the same kind of job but have different APIs". This statement means:

1. service semantics (what a service does) are not the same as service interfaces.
2. service semantics can be the same (do the same job) but service interfaces are different.

In Web services, the same kind of service (services do the same job) can also have different APIs - the outcome of software engineering implementation. 

When we talk about the semantics of Web services, we should focus on the "specification" of a kind of services - this is the ontology definition, the shared, common conceptualization of a domain knowledge, which can be implemented through different APIs, a.k.a. WSDL document.

The problem is, if there should be an ontology, or shared specification for Web services, why people don’t use it? The most common response in this community is to "reference" each individual ontology to a super-ontology. I have to say, "reference" to a super-ontology does NOT mean to "share", but on the contrary, this means we do NOT share because everyone just defines its own ontology and puts them together. Then we have the difficulty in service discovery and matchmaking.

Theoretically, matchmaking is a process within the so-called service registry system. In Web service architecture, a service requester (agent) looks for certain kinds of services through service registry system, which process the request and accomplish the task of service discovery and matchmaking. Unfortunately UDDI failed as many partners closed such testing systems. I just wonder whether those matchmaking contest or SWS challenge will result in a new kind of service registry system or not? Or SWS people want to change the rule to let service requesters to do service discovery and matchmaking themselves? But where can requesters find the location of Web services without a service registry system? From the Web again? Not kidding ...

If ontology is a formalized, shared specification of a conceptualization for the knowledge domain, SWS-IG should focus on the service semantics or specification, not service APIs or implementation. If we want to share an ontology, just use it directly, rather than "reference" to it. If we can find a way to enforce such a "shared" ontology through the new servce registry system, matchmaking may not be that hard because we "agree" to use the "shared" conceptualization, NOT generate and use any other different ontologies for the same kind of services any more. We can reach a semantic interoperability through agreement and standardization if we really want to share a service ontology, and W3C is just an organization that defines the standards for the Web.

In GIS community, interoperability problems were classified into three levels, i.e. technical, semantical and organizational/political. Technical interoperability is the easiest one and we already have WSDL as an "agreement" among different parties. Semantical issues can be identified and we can easily understand what kind of semantic problems we have, such as the semantic difference in defining an "address". However such semantic difference is limited. The biggest problem is at organizational/political level, or more frankly to say, your willingness - whether or not do you WANT to share, it’s almost not a problem of whether you can do it or not. Like the so-called "hotel reservation service", the service semantics are quite clear, we all know the specifications for such kind of service, but we just do NOT want to share the same service ontology beause as Jacek said, every service developer has the ABSOLUTE right to do what s/he wants to do.

So, we ourseleves generate the matchmaking problems in this community because we do NOT want to share the same service ontology and semantics. We would rather to "reference" to that common specification or super-ontology, but just do NOT use it. Under such situation, before you organize another contest and challege, ask yourself and ourselves, whether or not you are willing to deploy and use that formalized, shared specification of a conceptualization for the knowledge domain? If we do not want to share, we are creating more and more problems, not resovlving them, but we cannot generate the problme on the ond hand, and then try to solve this prolbem on the other hand.

Regards,

Xuan

Received on Thursday, 31 August 2006 10:32:29 UTC