Minutes of SWSA Telecon of February 17, 2004

Andreus Eberhart, Juan Miguel, Mike Dean, Amit Sheth, Mike Huhns, Michal
Zarembe, Chris Bussler (and Carole Goble came in late but was so quiet we didn't hear her.)

MB: We need to come to agreement on the overall direction of the committee.
Last week we discussed two different approaches, one following our existing
track would be to identify the classes of interactions and protocols for
that would support the functions identified in our matrix. The other would
be to develop a (minimalist) constrained interface that utilizes semantics
- perhaps by looking at the shortcomings of FIPA, WSDL and SOAP.

AE: The most fruitful approach - look at conventional web services, look at
the things we want to change and improve there. One big problem is the
current approach is based on API standardization implemented by various
partners. You need to look for partners that implement the standard before
you can interact. These standards requires programmers writing code. This
doesn't scale.

MB: Another issue impacting dynamic interoperability is lifecycle -
interfaces and the domain semantics continuously change. A hurdle to
ongoing interoperability is the ability to adapt dynamically to shifting
message content.

MH: We should also be compatible with SWSL. If they are developing a
language for processes We could address the question - what components
would be needed to support such a language. e.g. translation service. Need
to be able to at least match the language.

MB: We are already trying to be consistent with their major requirement
areas. But yes, we need to continue to be aware of what they are doing.

CB: People identify behavior without implementation. Some machinery must be
described in an abstract way.

We need to be brave enough to propose a fairly specific model of how it could work. 

MB: One issue there is whether we want to specify architectures for the
agents themselves or just an "interoperability architecture" using Frank's
term - that leaves the implementation of the individual agents unspecified
but talks about how they interact. 

CB: We can do propose a specific model while focusing on relationships
between middle agents, by addressing the protocol issues and calling out
which middle agents can utilize them.

MB: Another is how much we must specify about how the semantic web itself
works in order to do that. If semantic interoperability is a key issue,
then means of accessing ontologies and rules for translation is a critical
issue. As this machinery doesn't exist, we may need to identify some of it.

AS: There are workflow architecture committees. Is the question how this changes with semantics?

CB: We try to say there is a common denominator that everyone can specialize. 
This is being the brave part. 

AS: So this would be different than the workflow coalition? 

CB: They never had a language with a semantics that said this is what it
means. Given this language they can execute newly discovered workflows potentially. 

AS: Two types of semantics - Semantics of interaction, second is domain
semantics.  First covers contract principles, qos, etc.  You are focused on
former.  Perhaps we have to fix ontologies for the former, then wrt those,
we can describe latter.

CB: This is what the language committee is trying to do. 

AS: They are doing semantics for process composition, but starting from
that, there are a number of other issues, qos, negotiation, contracting,
security. These things must also be supported.

MB: They have identified some of those as requirements as well. I don't
know what their plan to address them will be.

CB: we need all of this to make it work, but we can't keep defining the
whole space - Why can't we take the language as it is, and define an
architecture. At some point we need to get down to an architecture and then
come back up to add these.

AS: We should formalize and develop ontologies for such things as QoS -
here is the semantics, any architecture supporting this semantics would
require these functions.