Minutes of July 13, 2004 Mark, Massimo, Chris, Mike H., Stuart MB: Lets review of Stages of SWS development as discussed at F2F: Dimensions/Issues: discovery, invocation, mapping, exception handling: Stage 1: Simple service invocation and response handling - User directed manual discovery - User directed composition - Ensuring semantic interoperability during invocation and responses exception handling - Mapping: predefined, lossless, simple translation engines Stage 2: SWS with Automated Discovery and Mapping - Goal characterization for matchmaker querying and service selection reasoning - Mapping: add mapping infrastructure (registries), partial mapping Stage 3: Complex Discovery Models and Negotiation/Contracting - Proxy/Broker based interaction protocols - Includes forwarding of QoS and Privacy requirements - Negotiation dialogs for refining discovery, establishing service requirements MB: I'm assuming that fully automated discovery will be limited in early stages. Grid doesn't need it, UC, will used localized form of it where available services might well be all discovered and displayed as menu. B2B would only do it over closed groups where shared ontologies and some pre-existing partnering has occurred. CB : It will happen in some cases, where the data is well specified (established parts catalogs), and interfaces pre-determined (Rosetta, SAP..) MB: Similarly composition will be semi-manual. In B2B exception would be for things like splitting orders across suppliers. CB: Again depends on the scenario, different suppliers might require longer negotiations, protocol interactions. Order outstanding, then cancelation - might be complicated sequence of interactions. Supply chain scenarios also could involve negotiations at different steps. Could be long lasting service interactions rather than simple service calls. eg, Purchasing from an sap system - sap system internally does composition for a product. Externally looks like a simple request, or vice versa, composition done by client. ALso scenarios where different kinds of interactions used at different stages: RFQ over Rosetta, then purchase using EDI. MB: There is a distinction between Discovery and Composition here: Discovery being done at abstract level then protocols selected from published service descriptions - I don't think of this as composition. Rather just use of semantic abstraction for service selection, enactment. Part of the issue here is use of shared ontologies and ontology language - UDDI for example doesn't emphasize shared ontologies, but mostly allows each service to describe itself in a user readable way. MP: UDDI started to have uniform format for taxonomies of services. They are starting to look at OWL - so far just classes no properties. Only thing that will change is minor changes to UDDI protocol is whether you If you want a more flexible model for specifying ontologies. So far UDDI mostly being used for managing intranets. There you have your own corporate taxonomies. ChrisB: Rosettanet has a technical dictionary - specs of valid entries in the documents. Currently done using spreadsheets - not even hierarchical. EDI at least allows shared use of relations. Rosetta has a Standards organization with reps from member companies. MB: Rosetta PIPs/documents really describe message formats. product taxonomies described in these dictionaries. CB: But the dictionaries are not hierarchical, dont use shared relations between object classes. EDI more intesting - guideline document each provider publishes explains their changes to use to shared terms and relations can be shared - described separately from the classes. But still not hierarchical. There is also UBL - Unversal Business Language. MB: We need to emphasize the use of shared ontology LANGUAGES, rather than idiosyncratic dictionaries. Question is how to make the architectural elements act as a forcing function for use of shared ontology languages. CB: Partly need to emphasize protocols for requesting service-specific ontology elements of published service models. Describing how to access changes to commonly shared concepts. MB: This relates to SW notion of service descriptions with explicit references to ontologies by URIs, and to documents describing mappings onto shared terms.