Minutes of SWSA Telecon of 03 June 03

Chris Bussler, Mark Burstein, Mike Dean, Stuart Williams, Carole Goble

We began by reviewing Mark's revised mission statement, based on the emails
of this last week:

"The mission of the Semantic Web Services Initiative Architecture committee
(SWSA) is to develop architectural and protocol abstractions forming a
reference architecture to support Semantic Web Service technologies.  The
Architecture committee will motivate these concepts through use cases that
demonstrate the benefits of using machine interpretable semantics to
facilitate dynamic interoperability, composability, and substitutability
among web services and for agent-based services in other distributed
environments.  We will promote the development of standard methodological
and theoretical underpinnings through discussions, publications,
reference implementations and coordination with standards bodies."


Stuart's said his prior message (and Katia's response) was aimed at making
sure that we were clear what the delta was that we provided over WS. Mark
argued that "demonstrate the benevits of using .. semantics to
facilitate.."  covers this. Any one who wants to take one more go at it
before we call it good enough is welcome, but let's declare it done by the
end of this week.

We then moved to discussing how to go about the populating of an abstract
architecture to support SWS. As it seems that the functionality we will
require cannot be mandated to live in particular "agents" in this abstract
model (different realized architectures may cluster them differently) we
moved to cataloging functions that we think will be needed. 

Carole is emailing around some links to Grid architecture documents that we
should all review with an eye toward elements that would need to be
semantically enabled, and what infrastructural services would therefore be
required.  We will discuss docs these next week. 

After enumerating a (non-exhaustive) set of functions, we organized it into
two categories. Those that are related to agent/service lifecycle and those that are related to semantic discovery/composition/interoperability. 

semantic functions
----------
service invokation (request/query/negotiation/agreement)
message mediation (message translation & elaboration)
process mediation
candidate service identification (matchmaking)
candidate service selection (from candidates)
process composition
task management / task status
ontology management (for communities sharing ontologies)
community management (partnering services)

lifecycle functions
----------
registration & nameservices
service (operational) status
authentication
instantiation (e.g. service factories)
service migration (between hosts)

Mark and Stuart debated whether task status for composite processes was an
issue - Stuart argued that from the point of view of a requester a
composite process managed by a service provider would look atomic.  Mark
argued that this might not be the case using the example of a failed
transaction where a credit card was debited and then the service provider
died before providing the service. The requester would then interact
directly with the credit card service for compensation even though the
credit card debiting would have been part of the original service's
composite process. An alternate model here is use of middle agents that
monitor atomic task completion for distributed composite processes. This
argues for the role of a task status 'function' that (again) can be
localized in different ways.


Next week: discussion of semantic middle functions in a Grid environment. 
We also need to complete a set of milestones for the coming months in order to
complete a draft charter this month.