Steve Battle: today we're looking at the different technologies available out there
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
<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: 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: 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: 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
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