Minutes of SWSA telecon of 03 June 17

Mark, Massimo, Tim

What do we assume about core WS arch components?

Tim: If you walk into room, tell you what is available after initial
handshake and ID.  Specify protocol for Query/Answer about available
services of type X - response could be "are you a member of xyz?" to even
find out about available local services. 

In general, if a service seeker asks to see all the services of type x, service
provider may, in general, only shows ones you are allowed to see. This
includes matchmaking services. Matchmaker may query requester for access
rights.

Mark: Here, as elsewhere (like credit card authorization), you may need
membership/access rights that are managed by a 3rd party "membership"
service. The server does some validation-like transaction with the
membership server, and then grants some service priviledges. This is a
general use-case pattern.

Massimo - how to manage negotiation generally?  For example, how to agree
on a price, or use a coupon for a discount.

Tim: FIPA has combinabable set of dialog elements, perhaps these should be
reviewed. 

Mark: DAML-S lets services establish/define fixed protocols, but not so
easy to do flexible ones. It would be good to have a more general model
whereby a response to a request might be ANOTHER PROCESS MODEL, sort of
like a continuation protocol, or answering a question with a
question. Analogy is to filling in a form and getting another one based on
what you did. It is not necessarily the case that the whole sequence is
mapped out in advance. DAML-S doesn't address this.

Tim: What about supporting a Tell/Ask protocol that
registries/providers/seekers could engage in, rather than fixed protocols.
You ask a question (rdf triples) I send an answer (pairings of variables
and bindings) or don't know.

Mark: There are more general issues here with clarification questions.  For
example, if a matchmaker represents a wide variety of services, it may need
to ask questions to differentiate between large numbers of candidates to
avoid Google-like responses (you have 10,000 matches...). The kind of
followup might be based on the class of service sought, so can't be part of
a fixed protocol, except in a very general way.  We could use a process model
that can describe the potential effect of a process being invoked as
triggering a request for more information BEFORE THE ORIGINAL REQUEST IS
COMPLETED. I don't know if the SWSL committee will be able to handle this. 

Next week:
Need to draft work plan for the next 6-12 months. This is due 7/1.