Re: SWSL: Minutes for the SWSL Telecon - 21st January, 2004 #37

Hi Steve,
We do keep an eye on WS-CHOR and would certainly like to coordinate our
work with yours.


	regards
	  --michael  


> Dear all,
> 
> given the minutes below and the discussion topic of finite state 
> machines and conversations and should we store the behavioural 
> footprint it seems very sensible for you folks to track us folks (we 
> obviously track you). The WS-CHOR group has taken a behaviouralist 
> approach to the description of the external observable behaviour of 
> participating web services. We have recently had Prof Robin Milner and 
> Dr. Nobuku Yoshida and Dr. Kohei Honda join our group. These esteemed 
> academics represent some of the very top people in process algebra 
> (Robin invented pi-calculus). They are working with us on modeling some 
> of the use cases formally so that we can understand better the 
> requirements and the direction we need to go it to produce a 
> Choreography Description Language (CDL). We already have a model 
> overview of the CDL on our web page.
> 
> We would welcome some cross fertilization. We shall be at the plenary 
> and our F2F is the Mon/Tue of that week.
> 
> Best Regards
> 
> Steve Ross-Talbot
> Chief Scientist, Enigmatec Corporation
> co-chair W3C Web Services Choreography
> chair W3C Web Services
> 
> 
> O: +44 207 397 8207
> C: +44 7855 268 848
> www.enigmatec.net
> 
> 
> On 24 Feb 2004, at 02:54, Terry Payne wrote:
> 
> >
> > [Note - these are past minutes from recent SWSL telecons]
> >
> > =============================================
> > Minutes SWSL telecon - 21st January, 2004 #37
> > =============================================
> >
> > Participants:
> >   David Martin
> >   Michael Keifer
> >   Terry Payne (& Roxana Belecheanu)
> >   Bijan Parsia
> >   Rick Hull
> >   Daniela Bernardi
> >   Steve Battle
> >
> >
> > Notetaker: TP
> > Next: TP
> >
> > Action Items
> > ------------
> > 1) Steve Battle - make a proposal for a new version of the general
> > requirement including objective of using OWL-S as a starting point (see
> > below).
> >
> > 2) Look at the Service Oriented Model as proposed by Web Services
> > Architecture Group; each subgroup should identify where they fit and
> > provide more details.
> > See http://www.w3.org/TR/2003/WD-ws-arch-20030808/
> >
> > Minutes
> > -------
> > Item 1: Date for next F2F
> >
> > MK: Rick Hull offered to host at Bell labs.
> > RH: Can reserve hotel rooms - aprox 25 people?
> > DM: Rick sent a message to Admin list proposing to host at Bell Labs,
> > however details need to be confirmed asap.
> >   NOTE - MK didn't receive this message
> >        - check that messages are being received...
> >
> > MK: Any idea whether DAML-PI will be before or after?
> > DM: They are thinking of holding DAML-PI after, either Mon-Wed
> > or Tues-Thu
> > MK: 22-23 or 23-24 would be good (the latter is better).  Is the 22nd a
> > developers day???  If DAML is held on the 25-27th then that would be 
> > good
> >
> > TP: My preference would be to hold meeting before WWW
> >
> > DM: any preference on ordering?
> > ... F2F before WWW?
> >
> > DM: If DAML in Manhattan, then F2F shouldn't be sandwiched in between.
> >
> > Item 2: Minutes
> >
> > MK will post Minutes to the interest group in the coming days.
> >
> > Item 3: Steve's Comments on Requirements
> >
> > SB: Process Modelling appears to be focussed on workflow, whereas 
> > DAML-S
> > has focus on "conversations".  Process Model can be described as a 
> > finite
> > state machine.  Define a set of behavioural constraints.
> > MK: Workflows can be non-deterministic etc
> > SB: True - conversations are weaker...
> > RH: Similar to FSA and behavioural signatures - declarative 
> > specification
> > (sometimes abstract) but internal details hidden).  I have a colleague 
> > who
> > is looking at guarded specifications - Mentor system (Gerhard's group).
> > RH: The workflow describes what is behind the scenes
> > RH: Behavioural Signatures - should they be in the profile?  Can also
> > help with modelling and composition.
> > MK: Yeah - behavioural signatures are part of the process
> > SB: OWL-S describes behavioural signatures!
> > RH: Mebbie we should simplify the notion of this for the novice reader
> > RH: e.g. temporal constraints vs behavioural signatures, and then 
> > there is
> > mentor - state chart base vs work flow base
> > SB: Work needs to be done to see if State Chart Base and Work Flow Base
> > can share semantics or not?
> > MK: Some (or all) conversations can be modeled as workflows
> > SB: have sent a link
> > http://www.hpl.hp.com/techreports/2003/HPL-2003-208.html
> > Add to the requirements that we should cover this view.
> > MK: So we add this as well as a use case
> > RH: This would be a good thing!
> > MK: Contact Michael G about this - send to mailing list
> > SB: A second point - What is the relationship to OWL-S?
> > SB: We view that OWL-S semantics should be a starting point (and 
> > clarify
> > semantics) - again should be explicitly stated
> > MK: Have agreed to identify the gaps between requirements and OWL-S and
> > use OWL-S as a starting point to reach our requirements.
> > SB: Should be a non functional requirement (explicit) in Section 2 -
> > general requirements.  Point 3 General requirement should be
> > relabelled as "Non-Functional" requirements.
> > RH: This was for general points that do not fit the other sections.
> > SB: I think of general requirements as non-functional requirements.
> > DM: That notion hasn't been used consistently so far...
> > SB: that distinction is used in industry
> > MK: I view this more as a call to action rather than a requirement
> > SB: I just suggest that we should use OWL-S as a starting point.
> > RH: Requirements are a reflection of all the action points :)
> > would want SWSL to be an extension of OWL-S
> > MK: Yes but would want to go further than this...
> > MK: Would like people to volunteer to do different parts of the
> > requirements.  An action item is for people to take responsibility of
> > finding gaps between functional requirements and OWL-S.  E.G. to see 
> > where
> > it fall short of our requirements.
> > SB: Needs to be a requirement to be done
> > BP: There is a difference between taking OWL-S as a starting point or a
> > foundation...
> > SB: Where possible use the existing lang as is.
> > TP: Want to push OWL-S out and standardised...
> > MK: That is in the mission statement, right?
> > BP: Is OWL-S a good fit for certain things for what people want?
> > TP: We're not going to get a 100% solution out soon though
> > MK: OWL-S is insufficient, for example in defining the full semantics 
> > of
> > matchmaking.
> > Also look at complete examples that cannot be modelled - see example in
> > F2F and last summer.  How do you represent other issues
> > BP: Could you repost the example?
> > MK: Soon, when mail issues are sorted.
> > BP: OWL-S should consider this as a group.
> > ALL: Agreed :)
> >
> > SB: Could what we produce be seen as OWL-S2.0 - there would be some
> > lineage here...
> > BP: What counts as sufficiently similar?
> > SB: Can you trace the lineage back?
> > TP: Will there be a departure though from OWL?
> > MK: Probably to actually progress.  May stay here at syntax, but 
> > modelling
> > semantics will probably move on.  Different World views (DB people vs
> > Logicians)
> >
> > BP: OWL-Rules will not support non-monotonic reasoning.
> > MK: OWL does not support reasoning patterns that we might use.
> > Need defaults, for example...
> >
> > MK: extending OWL-S should be an objective rather than a requirement
> > DM: lets make this an objective in the requirements doc.  View it as a
> > starting point and move on.
> > MK: State this as a functional requirement in the intro.  
> > Non-functional
> > requirement...
> > BP: But how is this a requirement?
> > DM: a starting point and an objective is for future work to be based on
> > OWL-S
> > MK: in the introduction
> > DM: agreed
> > SB: in the general requirement
> > BP: in the introduction
> > SB: if in the into then it is not a requirement...
> > BP: its only an objective anyway!!!
> > MK: Steve - make a proposal for a new version of the general 
> > requirement
> > including this. [ACTION ITEM - Steve Battle]
> >
> > MK: action item to complete the conceptual model by the end of the 
> > month.
> > essentially an ER diagram.
> > W3 Architecture group have come up with a diagram that looks relevant 
> > but
> > not fully detailed.
> > Each of the subgroups should come up with a diagram for their
> > requirements.
> > Need to look at the architecture document at the SWSA site.
> > MK: David mailed this out in the past couple of days. The link is in 
> > the
> > agenda [http://www.w3.org/TR/2003/WD-ws-arch-20030808/]
> > MK: Some of the requirements should come from the arch-committee.
> > Even though this model may change when the arch-committee finalise 
> > their
> > requirements.  W3C Arch diagram is good to identify actors - again sent
> > by David.  Seems to be relevant to our conceptual model
> >
> > Look at the Service Oriented Model and expand [ACTION ITEM FOR ALL]
> > Each subgroup should identify where they fit and provide more details.
> >
> > _______________________________________________________________________
> > Terry R. Payne, PhD.		| http://www.ecs.soton.ac.uk/~trp/index.html
> > University of Southampton	| Voice: +44(0)23 8059 8343 [Fax: 8059 2865]
> > Southampton, SO17 1BJ, UK | Email: terry@acm.org / trp@ecs.soton.ac.uk
> >
> 
>

Received on Tuesday, 2 March 2004 16:34:13 UTC