Workshop on Frameworks for Semantics in Web Services (Day2)

10 Jun 2005

Steve Battle & David Martin


Steve Battle: today we're looking at the different technologies available out there

Presentation by John Domingue: Web Service Modeling Ontology (WSMO) - An Ontology for Semantic Web Services

John: you can go to the WSMO web site to see all the people involved

John conducting a hands-up poll about how much people know about WSMO

... most people know a little bit about WSMO
... Thanks to W3C for acknowledging the submission before this workshop

slide 3, WSMO working groups: there's WSMO, the conceptual model, the focus of the presentation
... then there's WSML, the language, and WSMX, the execution environment implementation

slide 4: underlying principles

John: web compliance - using URIs, grounding to Web services
... we're based on ontologies, we separate the different roles ontologically
... WSMO focuses on describing of a service, not its implementation
... we have execution semantics, architecture, APIs in WSMX
... we subscribe to the distinction between service and Web service, the latter being the computational aspects of the former

slide 5: top-level notions

John: first ontologies, it's clear why
... then goals representing the users
... then Web services - the functional aspects and the usage aspects
... finally mediators as first class citizens

slide 6: non-functional properties

John: assigned to any entity in WSMO, we use DC, extend that set
... we also use FOAF etc.

slide 7 lists our non-functional properties

slide 8: top level notions in more detail

slide 9: ontologies

John: in some sense this is mundane - non-functional properties, imports, mediators...
... the ontology elements are: concepts, their attributes, relations, functions (special types of relations), instances of concepts, axioms for logical expressions

slide 10, 11: Web services

John: again non-functional properties (NFP)
... capability is the functional description of the Web service
... then aspects of the implementation - choreography: how a client can interact with the Web services
... and orchestration, specifying how a Web service may invoke other services

slide 12: capability specification

John: it is the functional description of the Web services
... again has NFPs, imported ontologies
... two types of mediators: OO mediators for importing ontologies with mismatch resolution; WG mediators to lik to goals
... pre-conditions describe the inputs and outputs
... assumptions are about things you cannot talk about directly
... post-conditions describe the state after
... effects describe the real-world effects

slide 13: choreography & orchestration

John: Virtual Travel Agency example
... the VTA service choreography describes the conversation of the client and the service
... orch links to two other services, both have choreographies

slide 14: service interface description model

slide 15: goals

John: ontological decoupling of user and web service
... we can structure and reuse requests
... for example search, personalization, booking a holiday etc.
... requests may not be satisfiable: "I want to marry Britney Spears", no Web service can do that

slide 17: goal specification

John: goal may request a particular interface or capability

slide 19: mediation

John: mediators resolve heterogeneity mismatches
... mediators can be arbitrary web services, they play the role of mediators

slide 20: mediators overview

slide 21: mediator structure

John: mediator has source components and target components which it mediates between
... and mediation service which does the mediation

slide 22: relation to standards

slide 23: WSML

John: it's a family of languages
... WSML core restricts RDFS like OWL does
... WSML DL is pretty much the same as OWL-DL
... WSML rule (WRL) will be submitted to W3C soon

slide 24: use cases

John: various EU projects

slide 25: 1 minute demo postponed for the break

slide 26: summary

John: w3c gave comments on the WSMO submission, can we give a reply?
... WSMO is web-compliant
... represented in WSML family of languages
... we have goals, web services and mediators

Steve: please try to keep questions short

???: can you present a roadmap for WSMO tooling, especially reasoner?

Axel Polleres, DERI: the current strategy is to cooperate with existing reasoner implementors and building wrappers that handle WSML

???: so when?

Dieter Fensel, DERI: let's talk off-line

???: can we have a short overview of how WSMO relates to OWL-S

Steve Battle (chairing): let's have it later (in the discussion slot)

Yasmine Charif: where do you locate IRS-III in the WSMO big picture?

John: IRS-III is WSMO-compliant, will be compliant with WSMX APIs

Rich Hull, Bell Labs Research: wanna put comments on the table
... major question: very interesting ideas that cover a lot of territory, but how much is a vision and how much is worked out in detail?
... specifically: is there a framework for talking about the relationship between capabilities and choreographies? Like "this capability is met by this choreography"
... 2nd q: how are sequences of messages represented in capabilities?
... 3rd q: slide 12, you mention assumptions as things that cannot be checked, effect are the changes to the world, can that be checked?

John: replying to 3rd q: the ontology is not a perfect description of the service, ontological description that a book exists doesn't mean the book will physically get to you when you buy it; it helps

Rick Hull: how much of this is done?

John: WSMO has started in 2004 ...with a lot of background (from 2001)

Avi Bernstein: [missed]

John: within mediators there are mapping rules and a mapping rule language

???: we don't know how to do the mapping, there are several possibilities

John: there are documents in the wsmo website, I had 20 minutes
... we have several types of mediators

Bijan Parsia: The OWL-S experience

<TerryP> Bijan Parsia, UMD College Park / MindSwap

<AmitSheth> since time ran out, I will put my question here-- I noticed that there is some discussion in reposne to W3C team's question WSDL

<AmitSheth> but will current infrastructure WSDL be adequate ?

<AmitSheth> I mean WSDL-UDDI etc, or does WSMO's capability go far beyond what could be reasonably implemented using current state of the standardards and tools

Bijan: I've been working on things with OWL-S (or DAML-S) for about three years
... the OWL-S coalition has all sorts of people
... we came late to the OWL-S game in terms of development
... we want to have an end-to-end system that does something with Semantic WS
... it works, it does something, I'll talk about what we've learned

slide 2: brief conceptual overview

Bijan: OWL-S is a collection of ontologies in OWL-DL
... a loose upper ontology, description oriented
... focus on capabilities, functional properties and "other", non-functional
... and behavior, modeled with a process/action paradigm, roots in situation calculus
... the primary composition model is planning (at least for me)

Slide 3 ...OWL-S Concepts
... Service, Profile, Process Model & Grounding
... grounding touches on WSDL (others looked at uPnP)

Slide 4: A World Above [how the components fit together]
... Profile defines set of IOPEs and non-func properties
... Process defines Atomic Processes, which relate to WSDL operations

Slide 5: Ascension
... Need lots of background knowledge (both model and theories)
... does have some redundent stuff
... can be written by hand, but writing tools is straight forward
... descriptions don't have to be that rich to get something interesting out

Slide 6: Description Enablers
... several wizard-like tools out there (e.g. WSDL2OWL-S)
... also Machine Learning approaches to generate descriptions (e.g. ASSAM)

Slide 7: (One kind of) Composition
... simple, forward-chaining plan, using iopes towards a goal (sequence of WSDL operations)
... so planning results in a simple sequence of executable actions
... so we're producing a particular instance of the program with the desired effect
... we can focus on simple I/O chaining
... precondition/effect evaluation
... template instantiation

slide 8: exercising the framework
... when a plan is done, the system just goes ahead and runs it
... and it usually just works

slide 9: (semi)automatic composition
... the system gives you the first cut at what could be done next, what's possible
... implemented in Task Computing (Fujitsu), works pretty well
... we have JSHOP-DL that does it all fully automatically

slide 10: some lessons
... OWL-S can be used, the SW is maturing
... you don't need a lot
... but the conceptual model seems fairly robust

slide 11: more lessons
... type systems are interesting, but I'm not sure
... we represent real-world changes using preconditions and effects
... like a store of info about "what's going on"
... preconditions and effects are queries and updates in that store
... this is one of the key aspect of semantics in SWS

Axel Polleres, DERI Ibk: OWL-S is a great ontology, I think, but it has a principal flaw of putting additional semantics in OWL-DL
... it would be better to separate the things
... the semantics for processes, for example
... you talked about WSDL2OWL-S tools, very essential IMO, but it is not completely solved, though it's crucial

Bijan: it's not about bridging the gap between technologies, it's like writing comments, real facts about the service, true and useful, that's hard
... the feedback is stretched out, in WSDL feedback about it working or not is immediate, but with SWS, getting people to write the descriptions requires giving them hope

Harald Meyer: is the process model necessary?
... wouldn't reusing BPEL be better rather than reinventing the wheel?

Bijan: we are more like abstract bpel, which is though hard to use as a basis for composition

<TerryP> which came first? BPEL or OWL-S ... OWL-S (was DAML-S then)

Bijan: we can produce BPEL from the semantic descriptions
... is BPEL winning? It's not clear, I've heard doubt and skepticism about BPEL's future
... people can be using programming languages to write services, they don't necessarily need BPEL, the question is how to integrate WS in programming languages

Benjamin Grosof: the most interesting parts are profile and grounding
... but the process model is pretty toy, uses a DL straitjacket, kind of a half-way point, a no-man's land, and that's not only my view
... that's why people moved on to SWSI and WSMO
... the process model also lacks formal semantics
... so what besides the profile and grounding deserves to be pulled out of OWL-S?

Bijan: disagree with the characterization of the process model

Benjamin: the profile is limited to DL but doesn't have KR semantics

Bijan: disagree again, it uses situation calculus, the semantics are vague and squinty, but they are there
... if we're interested in automating composition, as opposed to improving efficiency of writing programs, then the process model is fairly rich

Katia Sycara: we have an IDE on semwebcentral that supports a programmer in constructing OWL-S services
... you can start from Java or OWL-S, it's based on Eclipse
... so that's for the people interested in tools - OWL-S IDE semwebcentral.org/projects/ide
... we use the process model semantics for formal verification, so it is there

Meena Nagarajan, University of Georgia, Web Service Semantics - WSDL-S

Meena: I'd like to thank W3C for giving us this opportunity

slide 2: scope, proposal and the bigger picture

Meena: during development, annotations can be added to web service descriptions
... during discovery a service template can describe the requirements
... discoverer will come up with candidate web services
... composition will find meaningful compositions
... to achieve all this, we augment WSDL with extensions that refer to extenalized model
... we only describe the functionality, not behavior
... we're analogous to grounding and profile, but without process model

slide 3: guiding principles

Meena: any approach should be upward compatible
... we believe it's good to keep the annotation mechanism separate from the particular semantic languages

slide 4: guiding principles

Meena: reuse of interfaces and data types is common
... we should annotate those semantically
... we need rich mappings between schemas and semantics

slide 5: WSDL-S

Meena: evolutionary and compatible upgrade
... multiple ontologies can be used together in annotation

slide 6: semantic annotations on WSDL elements

Meena: modelReference and schemaMapping on types and elements
... preconditions and effects on operations
... category for publishing to UDDI
... action to indicate the functionality

slide 7: example WSDL file with annotations

Meena: we see a modelReference

slide 8: annotating operations

Meena: preconditions and effects as usual
... we are agnostic to how you represent the preconditions and effects, we only provide a hook
... category is again agnostic to taxonomy etc.
... action is still under consideration, indicates what the operation does

slide 9: annotating types

Meena: simple correspondences can occur

slide 10: complex correspondences

Meena: usually correspondences aren't simple
... in these cases we need some sort of mapping

slide 11: using modelReference and schemaMapping

Meena: there are a number of ways these can be used
... the address complex type and the address class, there is a semantic match
... model reference at the complex level or at the leaf level

slide 13: representing mappings

Meena: there are a number of ways of representing mappings
... we used XSLT and XQuery for simplicity
... but we do acknowledge there are other options
... since it's externalized, you can use whatever you need

slide 14: WSDL-S in perspective

slide 15: WSDL-S evolution

slide 18: WSDL-S in action

Meena: real-world proteomics experiment
... their WSDL has been extended by WSDL-S, published in UDDI (which can contain WSDL-S)

slide 19: WSDL-S collaborations

Meena: Meteor-S collaborates with WSMO (in a preliminary stage now)
... WSDL-S for grounding

slide 20: WSDL-S annotator tool

Meena: point-and-click interface to create mappings
... we also have WSDL-S API

slide 21: Why?

Meena: we need to keep things simple, WSDL-S is upwardly compatible with WSDL
... keeping the semantic model outside WSDL has benefits
... tools can be upgraded easily
... Questions? Comments?

Mark Nottingham, BEA: I like this approach, it's a nice way to do it
... does action annotation relate to WS-Addressing action or WSDL action?
... if no, you might choose a different name
... also, why XSLT to map between XML Schema and RDF? WSDL allows you to put the RDF Schema directly in there

Meenakshi: we are dealing with XML objects and we want to externalize the semantic annotations

Rama Akkiraju (IBM): we're talking about existing Web services that use XML Schema

Amit Sheth: we can also demonstrate the mapping to UML

Hugo Haas, W3C: also question about action
... there has been discussion in W3C about intent of messages, there may be confusion
... we are trying to make messages self-describing, carrying their semantics in action
... you put action on operation level
... we had proposals to carry operation name in the message

<AmitSheth> we expect we will have ability to model different aspects of Web processes using ontologies/conceptual models: functions, nonfunctiomal/QoS, execution-- and we expect to handle that with mappings

Hugo: but we concluded we need to identify the message, not only the operation
... so do you have actions at message level?

Meena: no, but we're still considering action

hugoh: we'll need to discuss off-line

Harry Halpin: we have references between XML and ontologies
... but we're doing two things - we could just integrate them, carrying the ontology around as the messages are passed around

public: no

Harry: so if we pass through the ontological data...?

Rama: the behavior of the service would be modeled in the effect

Harry: I'm just wondering if we could drop the going back and forth betwen XML and ontological data

???: we define nothing about message passing protocols

???2: if a service uses ontologies internally, that is being hidden as a paradigm of WS
... so it's great if all this semantic stuff can be used internally, but it need not surface

Bijan: this isn't too distinct with how OWL-S interacts with WSDL, you modify the WSDL document and point out, OWL-S points in a WSDL
... XSLT can be used to map between these things; is there a deeper difference?

Axel: this work is very interesting, it addresses the point of what is missing in OWL-S
... the lifting and lowering between schema and ontology is more elaborate in WSDL-S than in OWL-S

Bijan: nope, we do the same thing, really

Rama: WSDL-S is not meant as competition of OWL-S
... instead, we just bring all this data in the WSDL file
... we fold the profile data in WSDL

AmitSheth: we wanted to make something that a WS developer would find easy to understand
... it has limitations

Bijan: this is a natural choice to make, we made it too

Benjamin: what are the uses of the annotations?
... are there limitations as compared to the other approaches?

AmitSheth: we should not compare these things

Benjamin: what tasks does WSDL-S support?

AmitSheth: this annotation is helpful for publishing, discovery, composition, creating composition mappings
... we have a case study where we actually do data transformations in workflows
... WSDL-S simplifies it

Sheila McIlraith, FLOWS: A First Order Logic Ontology for Web Services

Sheila: this represents the work of the whole SWSL committee

slide: situation FLOWS
... SWSI is a joint initiative
... developed SWS Framework, it has three efforts - ontology, language and usecases
... I'll talk about the ontology effort, in particular SWSO-FOL (FLOWS)
... FLOWS falls at the foundation level, and partly to the programmer on the street, not the person on the street level
... procedural-style description formalisms can be used, FLOWS will provide semantics for that
... our position
... unambiguously computer interpretable description, the process model and the effects
... we believe an expressive language is necessary, we propose FOL, in particular PSL (ISO standard) - process specification language
... many of use were on the OWL-S committees, FLOWS results from all that experience
... goal
... this is an old slide of mine: we want to automate discovery, invocation, selection, composition, interoperation, execution monitoring, simulation, verification, exception handling
... discovery we all pretty well agree on; in some cases we may need a process model to do more explicit discovery
... for example: "find a book seller that, if they don't have the book, will recommend other places"
... for invocation we need inputs, outputs
... for selection, composition and interoperation we need information gathering, synthesis
... one of the key claims is that we need to represent side effects, not just inputs and outputs
... for example debiting the credit card, sending the purchase to the buyer
... this requires a representation of the process flow and also the effects as well as inputs, outputs
... simulation and verification have not been discussed much here
... I want to be sure that I know what happens
... representational desiderata
... this might be used as a straw proposal in any framework development
... we may not agree, but they are good discussion points
... we want to be able to talk about the processes
... we want to leverage existing technologies
... FLOWS is meant to be a foundational language that will be common for all the used things (BPEL, WS-CDL, ebXML etc.)
... FLOWS doesn't do it, but we might also want to represent messages and data flows explicitly
... the descriptions of WS will be partial, we still need to be able to use that
... lessons learned
... we worked with OWL, I was active in OWL-S, OWL is not sufficiently expressive
... there are reasons for limits in OWL but it became problematic
... the typical process models are not so good at conditional effects on the world, non-functional constraints, the relationships between objects in a domain
... pros and cons of FOL
... I won't go through this but we've put a lot of thought in to this, may be discussed later
... what is FLOWS?
... an interesting part of FLOWS is its process model
... building on standards (PSL) developed for manifacturing
... PSL core extends situation calculus, it's a verified ontology
... illustration of PSL model theory
... we can reason about the state of the world between atomic activities
... FLOWS process model
... FLOWS core is PSL-Core plus services, atomic processes, composition, message, channel
... FLOWS extensions allow many types of constraints
... FLOWS-core
... we have notion of Web service, with non-func properties
... atomic process is the building block of the process model - domain specific processes, service-specific ones
... finally, the notion of messages also first-class, can be put on channels
... driving home some points
... two ways to use FLOWS: you can model your WS in FLOWS
... or you can use FLOWS to describe the semantics of your UML, ASM, Petri nets etc.
... this was the goal of PSL in manufacturing
... we use it for Web services
... the programmer on the street is not going to use FOL
... we provide "control constructs" to simplify
... Reasoning in FOL is hard but we don't necessarily need that
... Reasoning in FOL is intractable: problems are intractable, not the language, if your problem is not tractable, a language will not help
... FLOWS/PSL is too hard to learn and write - we view FLOWS/PSL as the assembly language, it's there but people need not know it
... there's too much detail in FLOWS, so if you don't need it, you don't have to use it

Dominik Kuropka (Uni of Potsdam): at which level do you intend to describe entities of ontologies? like travel arrangements for the workshop?

Sheila: it's up to you how you describe your domain
... for composition, you do not need to enumerate all individuals, you only need the ones you care about, so it's not so bad

Dominik: I'd be interested to see a use-case scenario
... our experience shows that solving such basic things as organizing travel can be solved high-level but the results are not good or optimized, but for good results you'll drown in detail, we don't know what's a good level

Sheila: I'll send you a paper discussing that
... the modeling is not hard, for the computation you don't need to search through all of that

Sheila's colleague: we distinguish between the top-level ontology and the domain ontologies
... so your issue can be of choosing the appropriate domain ontology, we can link to any
... as for composition of WS that would take into account the various paths for "best solution", you need to think about the sequence of activities - we stress sequential behavior in our ontology

Rama: on process models
... you said we need to account for partial description
... but are there services whose description would go into implementation detail?

Sheila: for example amazon's workflow can be viewed as internal
... the internal workings need not be exposed, but companies may want to model it internally for various benefits

Rama: we may disagree on what's internal workings

Avi Bernstein: in some cases internal workings are part of advertisement of the services
... sometimes telling people what you do and how you do it is important for the users

Rick Hull: it might be significant to know when credit card is charged

Florian Probst, Uni of Munster: how can you be sure you have a clear description in FOL?
... no description will be unambiguous

Sheila: I never have guarantees, but I can see the intention and it might be sufficient

Florian: how do you make sure I'll understand the description?

Sheila: how do you do it now?

Steve: let's have 10min coffee break to get back on schedule

<AmitSheth> The question I did not get a chance to ask: there is a huge amount of workflow -- esp on workflow patterns-- would be good to look at that

Mikhail Roshchin: Web Services Annotation and Reasoning

Mikhail: we started with software components, not web services
... software applications require syntactic representation
... semantic approaches don't cover business life-cycle
... motivation - expectations
... we have identified requirements from service providers and requesters
... we have three different opinions on what should be used to describe WS - OWL-S, WSMO, FOL
... current work - framework conception
... current work - the connector conception
... if you're interested, there are references
... current work - logic-on-demand conception
... some of us want to use DL, other FLogic, other FOL
... some approaches lack KR features, temporal etc.
... how logic-on-demand should work
... semantic description has to have features from DL, FOL etc.
... idea - dynamic annotation
... we have meta-model level (WSMO, OWL-S), but they are not very detailed
... idea - cooperation
... customer requrements should be input to dynamic annotation
... idea - the key points
... big picture - service description reference model
... we have different semantic micro-models
... using their own formalisms
... they are connected to the ontology level
... they can be connected to external ontologies
... thus we can annotate our service
... use case - dynamic annotation
... price is not an easy feature for description
... it can depend on a number of chained factors
... we need rule languages for describing this
... also fuzzy logics can be used
... perspectives - what to do
... interesting approaches are representing UML diagrams in DL or FOL and they should be used
... siemens is going to use known approaches, not develop anything new
... we want to combine and propose the use of different kinds of semantic levels for different features

Panel discussion session - lessons learned

Steve: do we have a sense of convergence? Or do we have just different directions?
... the five technologies are listed, any others?

AmitSheth: there's METEOR-S
... WSDL-S is a minimal subset for interoperability
... and we have all kinds of things - graphical editor etc.

Rich: for structuring the discussion
... we may distinguish between the upper-level ontologies and domain ontologies, or categorize the technologies in these terms
... with FLOWS, we think of it on the foundational level
... whereas WSMO chor is for the programmer on the street
... we might layer the techs in this way

<AmitSheth> I disagree with characteirzation that WSDL-S is focused on domain ontology

<AmitSheth> we can have ontology of non-functional items, incorporating QoS, for example

Stuart Williams, HP: some of the labels seem to cover multiple technologies

Rama: WSDL-S is not a domain ontology

AmitSheth: WSDL-S uses four different types of ontologies

Steve: what are the strenghts?

Katia: all the technologies cover most of these things

Rich: are we going to talk about everything in this session? Or "ontologies for service description"?

Paul Giangarra: I haven't seen any mapping between these technologies to the plethora of WS specs

Katia: is there a mapping between the WS-* to each other?

Paul Giangarra: the WS-* stack changes, there may be underlying logic to it, but for process issues, business execution, there is tremendous coverage already
... the tools are concentrating on that not on the technologies we have here
... so we have to talk about the relationship

bijan: the WS-* specs are evidence about what WS people think is necessary to specify
... from a deep glance, the kinds of things we are trying to do here are not lining up with what the WS people are solving
... we can be ahead or we can be on the weeds having fun but the daisies are starting to die

Paul Giangarra: in VHS vs. Betamax, the superior format lost

IBM: we may want to look at WS-I

Harry: let's first talk about domain ontologies, then process ontology, than the big picture (scribe is unsure)

Axel: I don't think it's enough to annotate inputs and outputs only, that is the basis but we want to talk about frameworks for SWS
... we need a conceptual framework, describing all aspects in a complete way

AmitSheth: in WSDL-S we can use all kinds of ontologies, difficulties are gonna come up in the mappings
... so we can do anything that can be expressed in ontologies

Katia: for relation to WS-*, in OWL-S the idea was to leverage them, putting semantics "on top" conceptually, i.e. to compete but not to compete

Ken: a lot of this is built on top of WSDL, and it fits in with other specs, too

bijan: most of WS-* is not yet done, right? It's still evolving, it represents a set of things that people think needs to be modeled
... if we don't have insight in these things, what makes our orthogonal approach right or useful? We may need a reality check.
... so we should go see what people are trying to say and help them say that
... ws-policy is a great example of this, semantic tech would be so useful and still it's not dominating the field

Ken: mentioning WS-I is a red-herring on that slide

Ken: there are static aspects and dynamic aspects
... static aspects are DL, data integration etc.
... dynamic aspects are like UML ? diagrams

AmitSheth: the dynamic aspects may not be linked to domain ontologies

Rick: so we may want to distinguish between static vs. dynamic without mentioning domain ontologies

Rama: invocation could but need not be a part of the process model

hugoh: as for missing ws-* links
... there are two kinds of things in ws-* specs
... things like policy, discovery may be interesting to compare with sws techs
... but we need to have links to existing standards like WSDL
... the semantic WS work will not be ready for some time and we don't know where WS-I will be at that time
... for example MS indigo will support SOAP 1.2 that is not in WS-I profile
... now for choreography: there seems to be misunderstanding in what W3C and WSMO understand as choreography
... maybe ppl on the panel should tell us what their specs do and what they don't, what is considered critical, how it's prioritized etc.

bijan: we may not be the best fitted for determining the criticality

skw: you should ask the WS community

Jeff Mischkinsky, Oracle: comments about references to WS-splat specs
... out of 30 specs referenced from one source, 7 are approved, 2 are submitted and in development
... the other ones are in an unknown state
... so how can we map SWS tech to these specs that are in flux?
... we cannot wait for WS-I, it's a trailing-edge organization, it may be important eventually, but it's the back end of the process

Rama: based on industry experience, discovery is not a critical aspect, it's the invocation
... i.e. you know what service you wanna call but if semantics can help integration, that would be the low-hanging fruit

jeffm: disco and invocation are seperable problems and it should be separated

JohnD: there's two communities - users and web service providers, only we can connect them

<AmitSheth> rep from oracle proposed two different parts--possibly separately

Rick: there's an interesting thread - WS change the world in a given application area, to understand that app area we need ontologies, but we may need ontology mediation because there will be mismatches
... but is this a problem of the SWS community or of the banking community for banking ontologies?

<carine> ontologies for domains that have services are actually more relevant to the SW activity

bijan: re to Jeff, we may not need to align to WS-*, but they are providing us with evidence of what's needed
... we need a little neat package that will help the WS people, that will generate uptake and perhaps joy

Benjamin: a lot of these things came from research, some are newer, some older, perhaps superceded; SWSL addresses partial policies and contracts, very badly handled by WS
... we need the ability to reuse non-functional information for different things: advertising, discovery, contract negotiation etc.
... this blows out of the water all those ws-* things
... they are reaching for the left knee of the elefant whereas we see the elefant

???: WS-I has given us the least common denominator, but there's no new work chartered in WS-I

???: we need to understand how WS are used by machines, define the minimum stack for interoperability, a coherent stack

<TerryP> UDDI vs sneakernet

... most people are passing WSDL by sneaker-net, so few use UDDI, and they find the services at development time, then selection from candidate services is necessary ... semantics are going to be important in the NFP area
... we don't have the semantics for these things

katia: on the slide, what does process model (analysis) mean?

skw: one may need to frame things as problems being addressed, not technologies being available

Harry: XML is not the magical data integration technology, can SW tech do that?
... I'd like more opinions on what is critical to what SWS try to accomplish
... distributed programs talking to each other over the Web

Bijan: we only have hand-wavy answers
... we don't have an agreed single focused problem

Harry: XML doesn't provide identity, SemWeb could, how can we use it to describe how data is processed?

Rick: what Harry said is: XML is great for data transfer, not great for integration
... this is one aspect of SWS, but not the core aspect
... the semantics of data is very important, but that's not the focus of SWS
... now responding to Bijan: how do we figure what we should be doing? let's go see what people are describing?
... but there is a chicken-egg problem, as those people may not know they want to describe some things because they haven't been looking at the big picture involving semantics

Bijan: the chicken-egg problem may be misleading as it assumes there is a chicken, but the SWS players here don't seem to have built compelling real things

Rama: before we hurry and try to standardize something, let's try to apply our technologies

AmitSheth: yes, to real-world web services

Fabien: the slides are becoming bags of all the keywords we have here
... some of the problems are not specific to SWS
... we should focus not on distributed knowledge base but on services
... and we cannot, for instance, talk about process model before we have a model of interface

Rick: let's see XML - it came from frustration of data transfer, and it took a while before it achieved its status, we might want to wait a bit with SWS technologies
... the list we have on the slide is just the beginning, we might have a table of cruciality and what can be done quickly (somebody get together over lunch)
... as for interfaces before process models; I'd like first to know the big picture

Ken: we haven't seen SWS used over large-scale WS deployments, maybe because there are so few large-scale WS deployments?

AmitSheth: I'd distinguish between SW services and SW processes

<AmitSheth> need to distinguish between service and process

<AmitSheth> so let's understand how we associate/support semantics with/for services before we go into processes which has lot more complexities

<AmitSheth> because process involve multiple autonomius services, more ontologies, more concerns, more nonfunctional issues, so to start of with much larger problem is risky

JohnD: WSMO has multiple kinds of mediation, for data mediation we can indeed defer to SW people, but other mediations (process, protocol) are SWS-specific
... in a year I will have a real example of SWS benefits

<carine> the question is not only about benefits here

Bijan: in response to the XML analogy, it was history revisionist; we're trying to live off of something here that's not big enough to support itself yet

Rama: WSDL-S started by trying to see what semantic technologies could be directly applied to WSDL

Rick: in SWS arena we have technologies we're drawing on (corba, planning, kr), for XML one of the key ingredients was a whole lot of luck, and we'll need it, but I'd not focus on ways we can fail and stop the endeavour

Mikhail: there's still the unsolved problem of ensuring common understanding

<carine> end of session - LUNCH BREAK

Minutes formatted by David Booth's scribe.perl version 1.126 (CVS log)
$Date: 2005/06/14 16:21:02 $