- From: Terry Payne <trp@ecs.soton.ac.uk>
- Date: Tue, 24 Feb 2004 02:54:06 +0000
- To: public-sws-ig@w3.org
[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