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

[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 Monday, 23 February 2004 21:54:11 UTC