Rich service semantics vs. simple WSDL interface

This may be my last discussion thread in the year as I will not participate
in the discussion as frequently as in this month. 

While I discussed such issue with some people off-list, I think it's useful
to all for consideration and discussion.

I want to create a mapping Web service that allow requesters to add their
own or third-party datasets onto the base map I offered with the control to
change the color, label, symbology, etc. of certain/any data layers/features
in the map. Thus at least I need to add the following knowledge into the
service description:

1. Knowledge about source data and information (raster, vector, TIN, etc.) 
2. Knowledge about map product (map, legend, north arrow, scale bar/text,
framework, text description, logo/image, etc.)
3. Knowledge about mapping process (add/remove data layers, page setup,
symbol, label, color, size, position & confliction, inset map, map elements,
etc.)
4. Knowledge about service interaction (server-definition vs.
client-specification, map coverage vs. data coverage, QoS, error message,
etc.)

In this way, by reading service description document, requesters can
understand what and how they can perform and expect from service invocation.
So how can I add such rich semantic descriptions onto the abstract WSDL
interface(s)? It's in this process that we need to develop an ontology of
color class and many more to standardize the mutual understanding and
description on the same concept. In such semantic descriptions, what's the
role of Desrciption Logic in this process?

While many people have a favor for logical inference, I think I used a
straightforward way for service composition as described in the paper
"Rebuilding the Semantic Web Service Architecture". Service provider should
provide a detailed description and guidance on both input/output varialbes.
When service requesters read the service description document, they then
understand how to compose a service request based on the specified service
request template described inside the service description document. 

In this way, service composition is such a simple process as cut-copy-paste
while service requesters just need to specify the values of the required
input variables before they send out the request. There is no logic in this
process since everything is declared in such a service contract. Thus I
think we can do the same thing in a straightforward way without any tricks.
To make the description more accurate and specific for the purpose of
service discovery and matchmaking, we then need to use RDF/OWL to define the
terminologies used in the service description document. But to service
requesters, it's still such a simple process as cut-copy-paste to compose a
service request.

At last, let's consider if we need logical description in such a simple
process. I think everyone in this group undertand the meaning of the
following HTTP codes:

HTTP 2xx, HTTP 4xx, HTTP 5xx, etc.

We understand the meaning (semantics) of such message by Desrciption Logic
or by standard/agreement? Then can we say standardization can be an
alternative way for SWS?

Received on Monday, 28 November 2005 16:20:00 UTC