Semantic Web Technologies phần 8 pptx

seen as both specification and implementation language. SWSL-Rules language provides support for service-related tasks like discovery, contacting, policy specification, and so on. It is a layered-based languages as shown in Figure 10.6. The core of the SWSL-Rules language is represented by pure Horn sub-set of SWSL-Rules. This subset is extended by adding different features like (1) disjunction in the body and conjunction and implication in the head – this extension is called monoton ic Loyd-Topor (Mon LT) (Lloyd, 1987), (2) negation in the rule body interpreted as nation as failure – this extension is called NAF.Furthermore,theMon LT can be extended by adding quantifiers and implication in the rule body result- ing in what is called nonmonotonic Loyd-Topor (Nonmon LT) extension. Other envisioned extensions are towards: (1) Courteous rules (Courteous) whit two new features: restricted classical negation and prioritized rules, (2) HiLog – enables meta-programming, (3) Frames – add object oriented features like frame syntax, types, and inheritance, (4) Reification – allows rules to be referred and grouped. Finally, Equality can be possible extension as well. SWSL-FOL is a First-Order logic which includes features from HiLog and F-Logic. It has as well a layered structure which is depicted in Figure 10.7 Some of the extensions provided for SWSL-Rules apply for SWSL- FOL as well. The only restriction is that the initial languages should have monotonic semantics. The resulting extensions depicted in Figure 10.7 are SWSL-FOL þ Equality, SWSL-FOL þ HiLog, and SWSL-FOL þ Frame. Courteous Nonmon LT NAF Equallity Mon LT HiLog Reification Frames Horn Figure 10.6 The layered structure of swsl-rules (SWSF, 2005). THE SWSF APPROACH 217 10.5. THE IRS-III APPROACH IRS-III 13 (Domingue et al., 2004) is a framework and implemented plat- form which acts as a broker mediating between the goals of a user or client, and available deployed Web services. The IRS uses WSMO as its basic ontology and follows the WSMO design principles. Below we out- line additional principles which have influenced the IRS (Section 10.5.1). We then give an overview of the IRS-III architecture (in Section 10.5.2) and present the IRS extensions to WSMO (in Section 10.5.3). In the rest of the section we will use the terms ‘IRS’ and ‘IRS-III’ interchangeably. 10.5.1. Principles Underlying IRS-III IRS-III is based on the following design principles:  Supporting Capability Based Invocation: IRS-III enables clients (human users or application programs) to invoke a Web service simply by specifying a concrete desired capability. The IRS acts as a broker finding, composing, and invoking appropriate Web services in order to fulfill the request.  Ease of Use: IRS interfaces were designed so that much of the complexity surrounding the creation of SWS-based applications are hidden. For example, the IRS-III browser hides some of the complexity Figure 10.7 The layers of SWSL-FOL and their relationship to SWSL-Rules (SWSF, 2005). 13 http://kmi.open.ac.uk/projects/irs/ 218 SEMANTIC WEB SERVICES – APPROACHES AND PERSPECTIVES of underling ontology by bundling up related class definitions into a single tabbed dialog window.  One Click Publishing: A corollary of the above-design principle. There are many users who have an existing system which they would like to be made available but have no knowledge of the tools and processes involved in turning a stand alone program into a Web service. There- fore, IRS was created so that it supported ‘one click’ publishing of stand alone code written a standard programming language (cur- rently, we support Java and Lisp) and of applications available through a standard Web browser.  Agnostic to Service Implementation Platform: This principle is in part a consequent of the one click publishing principle. Within the design of the IRS there is no strong assumptions about the underlying service implementation platform. However, it is accepted the current dominance of the Web services stack of standards and consequently program components which are published through the IRS also appear as standard Web services with a SOAP-based end point.  Connected to the External Environment: When manipulating Web services, whether manually or automatically, one needs to be able to reason about their status. Often this information needs to be computed on-the-fly in a fashion which integrates the results smoothly with the internal reasoning. To support this we allow functions and relations to be defined which make extra-logical calls to external systems – for example, invoking a Web service. Although, this design principle has a negative effect on ability to make statements about the formal correct- ness of resulting semantic descriptions, it is necessary because our domain of discourse includes the status of Web services. For example, a user may request to exchange currencies using ‘today’s best rate.’ If our representation environment allows us to encode a current-rate relation which makes an external call to an appropriate Web service or Website then this will not only make life easier for the SWS developer, but also make the resulting descriptions more readable.  Open: The aim is to make IRS-III as open as possible. The IRS-III clients are based on Java APIs which are publicly accessible. More signifi- cantly, components of the IRS-III server are Semantic Web services represented within the IRS-III framework. This feature allows users to replace the main parts of the IRS broker with their own Web services to suit their own particular needs.  Inspectibility: In many parts of the life cycle of any software system, it is important that the developers are able to understand the design and behavior of the software being constructed. This is also true for SWS applications. This principle is concerned with making the semantic descriptions accessible in a human readable form. The descriptions could be within a plain text editor or within a purpose built browsing or editing environment. The key is that the content and form are easily understandable by SWS application builders. THE IRS-III APPROACH 219 10.5.2. The IRS-III Architecture In addition to fulfilling the design principles listed above – especially, supporting capability-based invocation – the IRS-III architecture has been created to link ontology-based descriptions with the components which support SWS activities. The IRS-III architecture is composed by the main following compo- nents: the IRS-III Server, the IRS-III Publisher, and the IRS-III Client, which communicate through a SOAP-based protocol, as shown in Figure 10.8 14 . At the heart of the server is the WSMO library where the WSMO definitions are stored using our representation language OCML (Motta, 1998). The library is structured into knowledge models for WSMO goals, Web services, and mediators. The structure of each knowledge model is similar but typically the applications consist of mediator models import- ing from relevant goal and Web service models. Following our design principle of inspectibility all information relevant to a Web service is stored explicitly within the library. Within WSMO a Web service is associated with an interface which contains an orchestration and choreography. Orchestration specifies the control and dataflow of a Web service which invokes other Web services 14 The IRS-III browser/editor and publishing platforms are currently available at http://kmi.open.ac.uk/projects/irs/ Figure 10.8. The IRS-III server architecture. 220 SEMANTIC WEB SERVICES – APPROACHES AND PERSPECTIVES (a composite Web service). Choreography specifies how to communicate with a Web service. The choreography component communicates with an invocation module able to generate the required messages in SOAP format. A mediation handler provides functionality to interpret WSMO med- iator descriptions including running data mediation rules, invoking mediation services, and connecting multiple mediators together. Follow- ing from the openness principle above orchestration, choreography, and mediation components are themselves Semantic Web services. At the lowest level the IRS-III Server uses an HTTP server written in lisp (Riva and Ramoni, 1996), which has been extended with a SOAP (XML Protocol Working Group, 2003) handler. Publishing with IRS-III entails associating a specific web service with a WSMO web service description. When a Web service is published in IRS- III all of the information necessary to call the service, the host, port, and path are stored within the choreography associated with the Web service. Additionally, updates are made to the appropriate publishing platform. The IRS contains publishing platforms to support the publishing of standalone Java and Lisp code, and of Web services. Web applications accessible as HTTP GET requests are handled internally by the IRS-III server. IRS was designed for ease of use, in fact a key feature of IRS-III is that Web service invocation is capability driven. The IRS-III Client supports this by providing a goal-centric invocation mechanism. An IRS user simply asks for a goal to be solved and the IRS broker locates an appropriate Web service semantic description and then invokes the underlying deployed Web service. 10.5.3. Extension to WSMO The IRS-III ontology is currently based on the WSMO conceptual model with a number differences mainly derived from the fact that in IRS-III the aim is to support capability driven Web service invocation. To achieve these goals, Web services are required to have input and output roles. In addition to the semantic type the soap binding for input and output roles is also stored. Consequently, a goal in IRS-III has the following extra slots has-input-role, has-output-role, has-input-role-soap-binding, and has-output- role-soap-binding. Goals are linked to Web services via mediators. More specifically, the WG Mediators found in the used-mediator slot of a Web service’s capability. If a mediator associated with a capability has a goal as a source, then the associated Web service is considered to be linked to the goal. Web services which are linked to goals ‘inherit’ the goal’s input and output roles. This means that input role definitions within a Web THE IRS-III APPROACH 221 service are used to either add extra input roles or to change an input role type. When a goal is invoked the IRS broker creates a set of possible contender Web services using the WG Mediators. A specific web service is then selected using an applicability function within the assumption slot of the Web service’s associated capability. As mentioned earlier the WG Mediators are used to transform between the goal and Web service input and output types during invocation. In WSMO the mediation service slot of a mediator may point to a goal that declaratively describes the mapping. Goals in a mediation service context play a slightly different role in IRS-III. Rather than describing a mapping goals are considered to have associated Web services and are therefore simply invoked. IRS clients are assumed to be able to formulate their request as a goal instance. This means that it is only required choreographies between the IRS and the deployed Web services. In IRS-III choreography execution thus occurs from a client perspective (Domingue et al., 2005), that is to say, to carry out a Web service invocation, the IRS executes a web service cl ient choreography which sends the appropriate messages to the deployed Web service. In contrast, currently, WSMO choreography describes all of the possible interactions that a Web service can have. 10.6. THE WSDL-S APPROACH WSDL-S (Akkiraju et al., 2005) proposes a mechanism to augment the Web service functional descriptions, as represented by WSDL (WSDL, 2005), with semantics. This work is a refinement of an initial proposal developed by the Meteor-S group, at the LSDIS Lab 15 ,Athens, Georgia. In this section we briefly present the principles WSDL-S is based on (in Section 10.6.1), and we shortly describe the extensibility elements used and the annotations that can be created (in Section 10.6.2). 10.6.1. Aims and Principles Starting from the assumption that a semantic model of the Web service already exists, WSDL-S describes a mechanism to link this semantic model with the syntactical functional description captured by WSDL. Using the extensibility elements of WSDL, a set of annotations can be created to semantically describe the inputs, outputs, and the operation of 15 See http://lsdis.cs.uga.edu/. 222 SEMANTIC WEB SERVICES – APPROACHES AND PERSPECTIVES a Web service. By this the semantic model is kept outside WSDL, making the approach agnostic to any ontology representation language (see Figure 10.9). The advantage of such an approach is that it is an incremental approach, building on top of an already existing standard and taking advantage the already existing expertise and tool support. In addition, the user can develop in WSDL in a compatible manner both the semantic and operational level aspects of Web services. WSDL-S work is guided by a set of principles, the most important of them being listed below:  Build on Existing Web Services’ standards: Standards represent a key point in creating integration solutions and as a consequence, WSDL-S promotes an upwardly compatible mechanism for adding semantics to Web services.  Annotations Should be Agnostic to the Semantics Representation Language: Different Web service providers could use different ways of representing the semantic descriptions of their services and further- more, the same Web service provider can choose more than one representation form in order to enable its discovery by multiple engines. Consequently, WSDL-S does not prescribe what semantic representation language should be used and allows the association of multiple annotations written in different semantic representation languages.  Support Annotation of XML Schema Data Type:AsXMLSchemaisan important data definition format and it is desirable to reuse the existing interfaces described in XML, WSDL-S supports the annota- tion of XML Schemas. These annotations are used for adding Figure 10.9 Associating semantics to WSDL elements (Akkiraju et al., 2005). THE WSDL-S APPROACH 223 semantics to the inputs and outputs of the annotated Web service. In addition, an important aspect to be considered is the creation of mappings between the XML Schema complex types and the corre- sponding ontological concepts. As WSDL-S does not prescribe an ontology language, the mapping techniques would be directly depen- dent of the semantic representation language chosen. In the next subsection we present in more details the extensibility elements of WSDL and how they can be used in annotating the inputs, outputs, and operations of Web services. 10.6.2. Semantic Annotations WSDL-S proposes five extensibility elements to be used in annotating the inputs, outputs, and operations of Web services:  modelReference: Extension element that denotes a one-to-one map- ping between schema elements and concepts from the ontology;  schemaMapping: Extension attribute that can be added to XSD elements or complex types to associate them with an ontology (used for one-to-many and many-to-one mappings);  precondi tion: Extension element (child of the operation element) used to point to a combination of complex expressions and conditions in the ontology, that have to hold before the execution of the Web service’s operation;  effects: Similar with preconditions, with the difference that the con- ditions in the ontology have to hold after the execution of the Web service’s operation.  category: Extension attribute of the interface element that points to categorization information that can be used for example when publish- ing the Web service. Each of these elements can be used to create annotations; in the rest of this section we briefly describe each type of annotations, pointing to the extensibility elements used. 10.6.2.1. Annotating the Input and Output Elements If the input or the output is a simple type it can be annotated using the extensibility of the XML Schema element: the modelReference attribute is used to associate annotations to the element. If the input or the output is a complex type two strategies can be adopted: bottom level annotation and top level annotation. In bottom level annotation all the leaf elements can be annotated with concepts from the ontology. The modelReference attribute is used here in a similar manner as above. While this method is simple, it makes 224 SEMANTIC WEB SERVICES – APPROACHES AND PERSPECTIVES the assumption that there is one-to-one correspondence between the elements from the XML Schema and the concepts from the ontology. In the case of one-to-many or many-to-one correspondences top level annotation method has to be used. Although it is a more complex method, its advantage is that it allows for complex mappings to be specified between the XML element and the domain ontology. The semantic of the elements in the complex type is captured by using the schemaMapping attribute. 10.6.2.2. Annotating the Operation Elements The operations of a Web service can be annotated with preconditions, which represent a set of assertions that must hold before the execution of that operation. The precondition extension element is defined as follows:  /precondition: Denote the precondition for the parent operation;  /precondition/@name: Uniquely identifies the precondition among the other preconditions defined in the WSML document;  /precondition/@modelReference: Points to that parts of the semantic model that describes the precondition of this operation;  /precondition/@expression: Contains the precondition associated to the parent operation. Its format directly depends on the semantic representation language used. The two ways of specifying the pre- condition assertions, /precondition/@expression, and /precondition/ @modelReference are mutually exclusive. For each operation there is only one precondition allowed. This restriction is adopted as an attempt to keep the specification simple. If one needs more than one precondition, the solution is to define in the domain ontology the complex expressions and conditions and to point to them using the modelReference attribute. The effects define the result of invoking a particular operation. The effect element is defined in a similar manner as the precondition (see above), and it is allowed to have one or more effects associated with one operation. 10.6.2.3. Service Categorization Adding categorization information to the Web service can be helpful in the discovery process. That is, by categorizing the published Web services can narrow the range of the candidate Web services. Multiple category elements can be used to state that a Web service falls in multiple categories as one category elements specifies one categorization. THE WSDL-S APPROACH 225 10.7. SEMANTIC WEB SERVICES GROUNDING: THE LINK BETWEEN THE SWS AND EXISTING WEB SERVICES STANDARDS As we have pointed in the previous sections, the ultimate aim of SWS – automatic execution of tasks like discovery, negotiation, composition, invocation of services – requires semantic description of various aspects of Web services. For example, the process of Web service discovery can be automated if we have a machine-processable description of what the user wants (a user goal) and what the available services can do (service capabilities). We call this kind of information semantic description of Web services. However, currently deployed Web services are generally described only on the level of syntax, specifying the structure of the messages that a service can accept or produce. In particular, Web Service Description Language (WSDL, 2005) describes a Web service interface as a set of operations where an operation is only a sequence of messages whose contents are constrained with XML Schema (2004). We call this the syntactic description of Web services. Certain tasks require that semantic processors have access to the information in the syntactic descriptions, for example to invoke a discovered service, the client processor needs to know how to serialize the request message. Linking between the semantic and the syntactic description levels is commonly called grounding. In order for SWS to be widely adopted, they must provide mechanisms that build on top of existing, widely adopted technologies. In this Section we look at such mechanisms and discuss the general issues of Semantic Web Service grounding (in Section 10.7.1); we also identify two major types of grounding, so in Section 10.7.2 we talk about data grounding and in Section 10.7.3 we talk about grounding behavior descriptions. 10.7.1. General Grounding Uses and Issues As we have shown in the previous sections, most of the existing approaches to Semantic Web Services describe services in terms of their functional and behavioral properties, using logics-based (ontologi- cal) formalism. First, to enable Web service discovery and composition, SWS frameworks need to describe what Web services do, that is, service capabilities. Second, to make it possible for clients to determine how to communicate with discovered services, the interfaces of the services need to be described. The description of a service interface must be sufficient for a client to know how to communicate successfully with the Web service; in particular a service interface must describe the messages and 226 SEMANTIC WEB SERVICES – APPROACHES AND PERSPECTIVES [...]... Domain Definition Language V 2 19 98 Technical Report, report CVC TR- 98- 003/DCS TR-1165, Yale Center for Computational Vision and Control 236 SEMANTIC WEB SERVICES – APPROACHES AND PERSPECTIVES Preist C 2004 A conceptual architecture for semantic web services In 3rd International Semantic Web Conference (ISWC2004) Springer Verlag: XX, November 2004 Riva A, Ramoni M 1996 LispWeb: A Specialised HTTP Server... investigate how the semantic technologies being developed can enhance the functionality of the digital library We have seen already that a number of the key challenges facing digital libraries relate to issues of semantics and semantic interoperability We explain in Subsection 11.3.2 below how semantic technology, and in particular the semantic knowledge access tools described in Chapter 8, are being used... W3C activity in the area of Web services, in order to provide a standardized framework for Semantic Web Services REFERENCES Akkiraju R, Farrell J, Miller J, Nagarajan M, Schmidt M, Sheth A, Verma, K 2005 .Web Service Semantics – WSDL-S Technical note, April 2005 Available at http://lsdis.cs.uga.edu/library/download/WSDL-S-V1.html Alonso G, Casati F, Kuno H, Machiraju V 2004 Web Services: Concepts, Architecture... FLight: Conceptual modeling and reasoning for the semantic web In Proceedings of the 14th International World Wide Web Conference Dean M, Schreiber G, editors 2004 OWL Web Ontology Language Reference W3C Recommendation 10 February 2004 Domingue J, Cabral L, Hakimpour F, Sell D, Motta E 2004 Irs-iii: A platform and infrastructure for creating WSMO-based semantic web services In Proceedings of the Workshop... the service On the data level, Semantic Web Service frameworks model Web services as entities that exchange semantic (ontological) data The grounding must provide means to represent that semantic data as XML messages to be sent over the network (according to serialization details from the WSDL binding), and it must also specify how received XML messages are interpreted as semantic data We investigate... John Wiley & Sons, Ltd 2 38 APPLYING SEMANTIC TECHNOLOGY TO A DIGITAL LIBRARY view to those data sets As discussed in Chapter 8, semantic information access offers improved ways to search for and browse information and, through an understanding of the relationship between documents, to improve the user interface Semantic access to information depends in turn on the supporting technologies described in... model of a Semantic Web Service framework as such part of the semantic description, that allows the client semantic processor to know what messages it can send or receive at any specific point during the interaction with a service Choreography descriptions have other uses as well, for example, detecting potential deadlocks, but these uses are out of scope of this discussion Because Semantic Web Services... creating a capability-based broker (facilitating the invocation of Web services through WSMO goals), ease-ofpublication being able to turn standalone code into a SWS through a single simple dialog, and tightly coupling the semantic descriptions with deployed Web services (e.g., semantic concepts and relations can be implemented as Web services) Ongoing work continues to align the two approaches The... modelReference attributes can 234 SEMANTIC WEB SERVICES – APPROACHES AND PERSPECTIVES point to concepts from WSML ontologies and the expressions in precondition or effects can be directly described in WSML Finally, we highlighted the importance and described possible approaches to grounding in the context of Semantic Web Services, as a key enabler for the adoption of SWS technologies to a wide audience... WSDL with WSDL-S elements pointing back to WSMO 10.7.2 Data Grounding Web services generally communicate with their clients using XML messages described with XML Schema On the semantic level, however, Web service inputs and outputs are described using ontologies A semantic client then needs grounding information that describes how the semantic data should be written in an XML form that can be sent to . be created to semantically describe the inputs, outputs, and the operation of 15 See http://lsdis.cs.uga.edu/. 222 SEMANTIC WEB SERVICES – APPROACHES AND PERSPECTIVES a Web service. By this the semantic. adding semantics to Web services.  Annotations Should be Agnostic to the Semantics Representation Language: Different Web service providers could use different ways of representing the semantic. the service. On the data level, Semantic Web Service frameworks model Web services as entities that exchange semantic (ontological) data. The grounding must provide means to represent that semantic data as XML