240 likes | 463 Views
Bringing Semantics to Web Services with OWL-S. . 指導教授:吳秀陽 報告人:陳建博 學號: 69621501. 1. Introduction. 2. Overview of OWL-S. 3. The service Profile. 4. The Process model. 5. The Grounding subontology. 6. Technology based on OWL-S. 7. Conclusion. Outline.
E N D
Bringing Semantics to Web Services with OWL-S .指導教授:吳秀陽 報告人:陳建博 學號:69621501
1.Introduction 2.Overview of OWL-S 3.The serviceProfile 4.TheProcessmodel 5. TheGroundingsubontology 6. Technology based on OWL-S 7. Conclusion Outline
1. Introduction– Why Semantic Web Services need ? • Current Web Services provide a basis for interoperability between services, and emphasize the specification of communication technique. • Existing program language like Java, PHP, C# can automatically produce code from its datatypes to their WSDL. • Without a semantic description of what happens when a Web Service is used, a human programmer is still to figure out from reading the natural-language description. • Semantic Web Services is a research field that endeavor to automation of information use and dynamicinteroperability are the primary objectives.
1. Introduction– How Semantic Web Service evolve ? • Key steps of the Semantic Web has been the development of standard languages such as URI, XML(S), RDF(S), OWL ….. • The central question is : “Can we use Semantic Web techniques to automate dealing with Web Service?” • The following subtask is expected Semantic Web to do in W3C: • Automatic Web service discovery. • Automatic Web service invocation. • Automatic Web service composition and interoperation. • OWL-S is an interface between Semantic Web and Web Service, and provides a framework for describing both the functions and advertisements for Web Services.
2. Overview of OWL-S– Brief • OWL-S(“OWL for Services”) is a set of notations based on the Semantic Web ontology Language OWL. • The principal objectives of OWL-S Coalition are: • To provide a general-purpose representational framework in which to describe Web Services. • To support automation of service management and use by software agents. • To build on existing Web Service standards and existing Semantic Web standards. • Although some Web infrastructure and reasoning tools for complete solutions are still ongoing work, one likely have a form-based interface between human and software agent.
2. Overview of OWL-S– Overall structure • The OWL-S ontology includes three primary sub-ontologies: • Service Profile – what the service does • Process model – how the service is used • Grounding – how to interact with the service • The service profile and process model are thought of as abstract characterizations of a service. • The grounding makes it possible to interact with a service by providing the necessary concrete details related to message format, transport protocol, etc. • Each service described using OWL-S is represented by an instance of the OWL class.
2. Overview of OWL-S– Top level of the service ontology Figure 1: Top-level of the service ontology
2. Overview of OWL-S– IOPEs mode • Inputs: The inputs are the object descriptions that the service works on. • Outputs: The outputs are the object descriptions that it produces. • Preconditions: A precondition is proposition that must be true in order for the service to operate effectively. • Effects: An effect is a proposition that will become true when the service completes. • Results: Results consist of effect and output specifications.
2. Overview of OWL-S– IOPE Illustration • For example, a simple on-line transaction service that requires a user to have an account and a credit card. • The Inputs might be User and CreditCard. • The Preconditions requires the user to actually have an account and a valid credit card. hasAcctID(User, AcctID)& validity(CreditCard, Valid) • The Effects and Outputs vary depending on whether the credit card is valid or not. If it is valid, then let’s suppose the sevice will replenish one’s account or no change in account when it’s not valid.
2. Overview of OWL-S– IOPE Example (cont.) • There are two possible separate results.Valid = OK |-> output(Outcome <= Success) & AcctBalance(25) Valid = Not-OK |-> output(Outcome<=Failure) • OK and Not-OK are values defined as elements of an OWL Class AccoduntValidity.<owl:Class rdf:ID=“AccountValidity”> <owl:oneOf rdf:parseType=“Collection”> <AccountValidity rdf:ID=“OK”/> <AccountValidity rdf:ID=“Not-OK”/> </owl:oneOf></owl:Class>
3. The service Profile – capability-based • The OWL-S profile provides a set of concepts to specify explicit description of services capabilities, with the goal of supporting capability-based discovery. • The OWL-S profile allows providers to advertise their services do, and requester to specify what capabilities the expect from the services they need to use. • By exploiting the structure of OWL-Sprofiles and references to OWL concepts, a discovery process can find those services that most satisfy the needs of a requester. • Inputs, outputs, preconditions, and results are referred to the Service Profile.
3. The service Profile – Describe aspect • functional aspect describe the information transformation from the inputs, expects to the outputs it generates, from a set of preconditions that need to be satisfied, to effects that are produced. (IOPEs mode) • classification aspect describe the type of service as specified in a taxonomy of business (or other suitable domain-specified ontologies). • non-functional aspect describe the distinctions between services that do the same thing but in different ways or with different performance.
3. The service Profile – Top-level structure of Profile Figure 2: Top-level structure of the OWL-S Profile
4. The Process model – Process types • The process model to give a detailed perspective on how to interact with a service. • It can be viewed as a process like describe what constraints must be satisfied and what pattern of interactions are required to make use of the service. • Two sorts of processes can be invoked: • atomic process – it corresponds to a single interchange of inputs and outputs between a consumer and a provider. • compositeprocess– consist of a set of component processes linked together by control flow and data flow structure. • simpleprocess– abstract type, non-invocable views of atomic or composite processes.
4. The Process model – How to describe process model • A process is not a program to be executed. It is a specification of the ways a client may interact with a service. • The concepts used to describe a process are terms in the OWL-S ontology. • The OWL-S definition of Process has a set of associated features (IOPEs) linked to the concept by OWL properties (hasInput, hasOutput, etc.). • Composite processes are related to their control structure using the composedOf property, and other properties, are used to show the relationships between control structure. • Some properties that relate to Profile and Grounding.
4. The Process model – Top-level structure of Process Model Figure 3: Top-level structure of the OWL-S process model
5. The Grounding subontology • The grounding is used to specify how the concrete information exchanges between service requester and provider. • A grounding maps each OWL-S atomic process to a WSDLoperation, and each OWL-S process input/output to elements of input/outputmessages of WSDL operation. • The purpose is to enable the translation between semantic I/O descriptions and WSDL I/O messages for transmission. • The grounding provides a bridge between syntax- and protocol-oriented WSDL and semantics-oriented OWL.
5. The Grounding subontology (cont.) • A grounding can be supplied at runtime, allowed for dynamic binding to a service provider. • An grounding involves a complementary use of the OWL-S and WSDL languages, because they do not cover the same conceptual space. • WSDL specifies message types using XMLS, whereas OWL-S allows for the definition of abstract types as OWL classes based on description logic. • The grounding uses OWLclasses as the abstract types of messages declared WSDL , and then relies on WSDL binding constructs to specify the formatting of the messages.
5. The Grounding – relationship between OWL-s & WSDL Figure 4: Relationship between OWL-S and WSDL
5. The Grounding subontology – Partial code Process Operation Input Message Grounding Output Message
6. Technology based on OWL-S – Interaction model Figure 5: Typical OWL-S Semantic Web Service interaction model
6. Technology based on OWL-S – Tools and extensions • OWL-S Editor a plug-in to the popular ontology development tools Protégé. http://owlseditor.semwebcentral.org/ • OWL-S development environment (CODE) supports developers of Semantic Web Services, include WSDL2OWL-S, editor for creating and editing OWL-S profiles, process, models and groundings based on Eclipse. http://projects.semwebcentral.org/projects/owl-s-ide/ • OWL-S Matchmaker system – extended for policy matching • OWL-S Virtual Machine (VM) – extended to enforce policies and security mechanisms.
7. Conclusion • OWL-S, a representational framework that provides for more complete specifications of the capabilities and behavior of Web Service. • OWL-S consists of three parts, service profile (what it does), process models (how it work), groundings (how to access it). • OWL-S has a wide variety of tools, and has been extended by researchers to support various specific requirements. • OWL-S could still be improved in a number of ways: • No way of describing desirable security. • QoS, exception handing …
References: • “Bringing Semantics to Web Services with OWL-S”, David Margin, Mark Burstein, Drew Mcdermott, Sheila Mcllraith, Massimo Paolucci, Katia Sycara, Deborah L, McGuinness, Evren Sirin, Naveen Srinivasan, July 2007,Springer • OWL-S: Semantic Markup for Web Services http://www.w3.org/Submission/OWL-S/ • DAML/OWL-S http://www.daml.org/services/owl-s/