Semantic Web Services M -S Hacid University Claude

(Semantic) Web Services M. -S. Hacid University Claude Bernard, Lyon – France http: //www 710. univ-lyon 1. fr/~dbkrr 1

Outline Evolution of MIS/DSS Enterprise Applications Integration (EAI) Web Services Semantic Web Services Conclusion 2

History The information processing profession is historically immature because it has existed only since the early 1960 s. Classical Operational Information Systems: - How much an account balance is, right now? - How much is an inventory, right now? - What the status of a shipment is, right now? But there is a real value in looking at and integrating information over the spectrum of time as well 3

History (Cond. ) DSS is at the end of a long and complex evolution but continues to evolve. 1960 - master files - programs (Cobol) - reports 4

History (Cond. ) 1965 Lots of master files!!! - complexity of maintenance development - synchronization of data - hardware 5

History (Cond. ) 1970 DASD DBMS database – ’’ a single source of data for all processing’’ 1975 Online, High-performance Transaction Processing 6

History (Cond. ) 1980 tx processing MIS/DSS PCs, 4 GL technology 7

History (Cond. ) 1985 OLTP extract program Why extract program? - Performance - Control 8

History (Cond. ) 1990 ’’spider web’’ 9

History (Cond. ) Problems with Naturally Evolving Architecture: - credibility of data - productivity - inability to transform data into information 10

History (Cond. ) Lack of Credibility of Data: Dept. A +10% activity up Dept. B -15% activity down 11

History (Cond. ) No time basis of data Dept. A: +10% Sunday evening Dept. B: -15% Wednesday pm 12

History (Cond. ) Algorithmic differential Dept. A has chosen to analyze all old accounts Dept. B has chosen to analyze all large accounts Is there any necessary correlation between the characteristics of customers who have old accounts and customers who have large accounts? Probably NOT! 13

History (Cond. ) Levels of extraction Many levels of extraction being done from the time data enters the corporation’s system to the time analysis is prepared for management 14

History (Cond. ) Dept. A: +10% Sunday evening old accts Dept. B: -15% Wednesday pm large accts 15

History (Cond. ) External data With today’s technologies at the PC level, it is easy to bring in data from outside sources 16

History (Cond. ) Wall Street journal Dept. A: +10% Sunday evening old accts Dept. B: -15% Business Week Wednesday pm large accts 17

History (Cond. ) No common source of data Analysis of department A originates from files XY Analysis of department B originates from databases XUVW No synchronization or sharing of data between XY and XUVW! 18

History (Cond. ) Wall Street journal Dept. A: +10% Sunday evening old accts Dept. B: -15% Business Week Wednesday pm large accts 19

History (Cond. ) Problem with productivity To produce a corporate report locate and analyze the data for the report lots of files to explore Locate data : 9 -12 months Get data : 15 -24 months 20

A Change in the Approach Data Warehouse Enterprise Applications Integration Web Services Semantic Web Services 21

Enterprise Applications Integration (EAI) What is EAI? Enterprise Applications Integration is a solution that supports real-time seamless access to information resident in a variety of repositories. Business processing logic is extracted from application code and placed into an EAI tool where it is graphically represented and manipulated. 22

Today’s Business Reality BFDI E-Commerce 15 SAP 14 17 2 Customer Call BW 1 COPS 7 13 4 1 5 8 12 JDA 17 2 ? 16 3 11 Email CBCF Financials 12 DRP Tax System BW Customer Call Computer Telephony 6 1 COPS 7 13 4 1 5 8 10 BFDI 15 SAP 14 17 2 Email CBCF Financials 12 DRP 16 3 11 9 Tax System BW Customer Call Computer Telephony 6 COPS 7 15 2 3 11 1 13 DRP Financials CBCF 4 JDA COPS 7 1 BFDI 13 4 1 5 8 17 3 11 9 14 12 10 BFDI 14 E-Commerce SAP 15 2 JDA Email Tax System 10 SAP 14 Customer Call Computer Telephony 6 1 5 8 14 E-Commerce 16 BW Email 12 1 5 8 14 E-Commerce JDA 17 9 4 JDA BFDI SAP 14 1 COPS 13 10 14 E-Commerce Computer Telephony 6 7 15 SAP 9 Customer Call BW Tax System BFDI 14 CBCF Financials 10 14 E-Commerce Email Computer Telephony 6 DRP 16 3 11 9 15 Financials DRP 16 CBCF Tax System 23

Why EAI? The needs for AI stem primarily from the following business and technical objectives: 1. Integrate with outside partner/customer (as part of a merger) or a «net new» entity, which varies widely from a new set of e-commerce applications to supply chain integration. 2. Migrate towards a customer centric operating model to gain additional Insights in customer behaviors and identify new revenue streams and cross-selling opportunities. 3. Isolate components of huge monolithic systems so they can be replaced or retired because the legacy systems become un-maintainable. 4. Layer an end-user application (especially portals, CRM, and Web-based self-service) that must access data across multiple systems and/or databases. 5. Lower total cost of ownership by reducing system management complexity and maintenance costs. 24

EAI provides a structured and efficient way to integrate not only the applications but also the business process. EAI solutions offer the following unique benefits: 1. Reduced development and maintenance cost (separation of business logic from transaction processing capability…). 2. Enhanced performance and reliability (asynchronous messaging mechanisms…). 3. Centralized information bus (unification of isolated applications…). 4. Extension of legacy system lifecycle. 5. Reduced time to market (customize existing business rules and extend application functionality). 25

Enterprise Integration Solution Supplier Customer Business Process Management (BPM) Reseller B 2 Bi EAI Exchange B 2 Bi Distributor Mfg. BSP Packaged Apps Service BSP Custom Apps Legacy Apps App Servers Logistics BSP Mediate the interactions between the applications to integrate 26

Customers, Distributors, Resselers -Community -Content -Commerce Distribution Channels Data Customer Service Relationship -Web Site -Profiling -Personalization -Customization Rules Engine Data Business Process Integration Product/Customer Analysis Product/ Customer -CRM -Call Center Service -e. Mail -Instant Messaging Message Routing & Transformation Information Systems Message Transport Data Partners Data -Data Warehouse -Data Analysis -Targeted Marketing Data -Payroll -HR -Benefits -Etc. Operational Systems Data Rules Metadata -Order Management -Warehouse Management -Backend Support -Billing. 27

Web Services We look at Web services as a way to expose the functionality of an information system and make it available through standard web technologies. The use of standard technologies reduces heterogeneity, and is therefore key to facilitate application integration. Web services represent the first concerted effort that has gathered wide support for standardizing interactions across information systems. Difficulties of integrating applications across the Internet: 1. Firewalls 2. Lack of standardized protocols 3. Need for loosely-coupled interactions 4. Etc. 28

Web Services and their Approach to Distributed Computing (main ingredients of Web services) Defining Web services Generic definition A Web service is seen as an application accessible to other applications over the Web [Fisher 2002, Menasce and Almeida 2001]. Anything that has a URL is a Web service (ex. cgi script) A program accessible over the Web with a stable API, published with additional descriptive information on some service directory. M. Fisher. Introduction to Web Services. Part of the Java Web Services Tutorial. Aug. 2002. http: //java. sun. com/webservices/docs/1. 0/tutorial/. D. Menasce and V. Almeida. Capacity Planning for Web Services. Prentice Hall, 2001. 29

Definition by UDDI Consortium A Web service is considered as a self-contained, modular business application that has open, Internet-oriented, standards-based interface. Published interface that can be invoked across the Internet ? 30

Definition by W 3 C «A software application identified by a URI, whose interfaces and bindings are capable of being defined, described, and descovered as XML artifacts. A Web service supports direct interactions with other software agents using XML-based messages exchanged Internet-based protocols» [W 3 C 2002] Should be advertised so that it is possible to write clients that bind and interact with them. W 3 C. Web Services Architecture Requirements. October 2002. http: //www. w 3. org/TR/wsa-reqs/. Part of Web technology. Data format used for many Web-based interactions. 31

Another Definition [Jupitermedia Corporation] A standardized way of integrating Web-based applications using the XML, SOAP, WSDL, and UDDI open standards over an Internet protocol backbone • XML is used to tag the data • SOAP is used to transfer the data • WSDL is used for describing the services available • UDDI is used for listing what services are available Jupitermedia Corporation. Webopedia: Online Dictionary for Computer and Internet Terms. http: //www. webopedia. com/. 32

Example: B 2 B integration Customer Internal procurement requests Supplier Web server Internal infrastructure B 2 B interactions occur by accessing Web pages, filling Web forms, or via email. Warehouse Web server Internal infrastructure Automation is driven by the goals: • Lower costs • Streamlined and more efficient process • Ability to monitor and track process executions • Ability to detect and manage exceptions 33

Limitations of Conventional Middleware in B 2 B Integration third party Where to put the middleware? • Trust • Confidentiality • Autonomy Wf. MS adapter message broker customer Internal infrastructure The combination of message broker and adapters enables interoperability supplier Supplier’s adapters Customer’s adapters Internal procurement requests A ’’global’’ workflow is executed here (drives the whole business process) warehouse Internal infrastructure Warehouse’s adapters Internal infrastructure 34

The Web brought • Standard interaction protocols (HTTP) • Data formats (XML) Adopted by many companies Creation of a basis for establishing a common middleware infrastructure that reduces the heterogeneity among interfaces and systems. 35

B 2 B integration with Web Services Three main aspects • Service-oriented architectures. • Redesign of middleware protocols. • Standardization. 36

Service-oriented paradigm Assumption The functionality made available by a company will be exposed as a service A service is a procedure, method, or object with a stable, published interface that can be invoked by clients Requesting and executing a service involves a program calling another program Services are loosely-coupled 37

Middleware protocols Web services redesign of the middleware protocols to work in a peer-to-peer fashion and across companies. In conventional middleware: lack of trust and confidentiality issues often make a case against a central coordinator. needs to be redesigned to allow more flexibility in terms of locking resources. 38

Standardization In conventional application integration: CORBA and Java enabled the development of portable applications. Service-oriented architecture Redefinition of middleware protocols Not sufficient standardization OASIS (Organization for the Advancement of Structured Standards) W 3 C B 2 B integration is what generated the need for web services 39

It is possible to make web services available to clients residing on a local LAN Customer Web service Internal procurement requests Internal infrastructure Supplier Web service Internal infrastructure Languages and protocols standardized, eliminating need for many different middleware infrastructures (need only the web services middleware) Interactions based on protocols redesigned for peer to peer and B 2 B settings Warehouse Web service Internal functionality made available as a service No centralized coordination! Internal infrastructure However, the challenge and ultimate goal of web services is inter-company interactions 40 (a long-term goal!)

Web Services Technologies The first required issues: • What exactly a service is? • How it can be described? Service description in conventional middleware is based on interfaces and interface definition languages (IDL). Implicit context: • Clients and services are developed by the same team. • Semantics of operations + order of invocation known in advance. • The middleware platform defines and constrains many aspects of the service description and binding process. In web services and B 2 B interaction no such implicit context! service descriptions must be richer and more detailed. 41

Service description and discovery stack Non-functional properties e. g. , return policy, Qo. S, . . (UDDI) Properties and semantics A language for specifying URI and transport protocol (HTTP) (WSDL) Business protocols Order in which to execute operations by a client (WSCL, BPEL) Interfaces Common base language Meta language for specifying all aspects of services (XML) WSDL: Web Services Description Language WSCL: Web Services Conversation Language BPEL: Business Process Execution Language UDDI: Universal Description, Discovery and Integration 42

Service discovery • At design-time (static binding) • At run-time (using dynamic binding techniques) 43

Service interactions (a set of abstractions and tools that enable interactions among services) WS-transaction Middleware properties (horizontal protocols) WS-coordination Protocol infrastructure (meta-protocol) Basic and secure messaging Transport WS-security SOAP 44

Combining Web Services : Composition Web service Request. Quote PC manufacturers (latest prices) Customer Shippers (delivery schedules) Reseller of personal computers 45

Web Services Architectures Web services are a way to expose internal operations so that they can be invoked through the web. Company A (provider) Company D (client) Web service client Web service interface Access to internal systems Centralized brokers • Route messages • Provide properties to the interactions • Logging • Transactional guarantees • Name and directory services • reliability Web service Internal architecture External architecture Web service middleware Company C (provider) internal service Web service Company B (provider) Protocol infrastructure • Coordinates the interaction among web services • Implements the peer to peer protocols Service composition infrastructure Supports the definition and execution of composite services 46

Internal Architecture of a Web Service other tiers service interface The basic components of each middleware instance reside on a LAN and the resulting application also runs on the same LAN. integration logic middleware service interface integration logic middleware resource manager 47

External Architecture of a Web Service Wrapping internal functionality as a Web Service brokers and workflow management systems in the case of conventional middleware External middleware for web services where this middleware should reside? Two solutions: 1. Implement the middleware as a peer-to-peer system (appealing but problem of reliability and trustworthiness) 2. Introduce intermediaries or brokers acting as the necessary middleware. 48

Company A (service requester) Company B (service provider) Web service client Web service 3. interact Web service middleware (internal) other tiers 2. find The abstraction and infrastructure provided by the registry are part of the external middleware 1. Publish the service description Service descriptions Company C (directory service provider) 49

Basic Web Services Technology Web services architectures are mainly based on three components: 1. The service requester 2. The service provider 3. The service registry Thereby closely following a client/server model with an explicit name and directory service Basic infrastructure necessary to implement web services: • A way to communicate (SOAP) • A way to describe services (WSDL) • A name and directory server (UDDI) Core of web services 50

A minimalist infrastructure for web services 1. Common syntax for all specifications (XML) 2. A mechanism to allow remote sites to interact with each other a. b. c. A common data format for the messages being exchanged A convention for supporting specific forms of interaction (messaging or RPC) A set of bindings for mapping messages into a transport protocol (TCP/IP, HTTP, SMTP) Messages as basic unit of communication 51

Application object (client) SOAP-based middleware SOAP messages exchanged on top of HTTP, SMTP or other transport Service requestor Service provider Application object (service provider) SOAP-based middleware Converts procedure calls to/from XML messages sent through HTTP or other protocols 52

<operation name=’’order. Goods’’> <input message=‘’’Order. Msg’’/> </operation> WSDL of Service provider WSDL compiler (client side) WSDL compiler (server side) Service provider Service requestor Application/proxy object (provider) Application/proxy object (client) stub skeleton SOAP-based middleware SOAP messages 53

Service requestor Service provider Application object (client) Application object (service provider) skeleton stub SOAP-based middleware SOAP messages (to look for services) SOAP messages (to publish service description) SOAP-based middleware Service descriptions • How to publish services? • What information needs to be provided to register a service? • How to query the registry? UDDI registry 54

SOAP : Simple Object Access Protocol A joint effort from Canon, IBM, Microsoft and SUN First version (1999) based on HTTP Current version (2003) XML encoding SOAP defines how to organize information using XML in a structured and typed manner so that it can be exchanged between peers. - A message format describing how information can be packaged into an XML document. - A set of conventions for using SOAP messages to implement the RPC interaction pattern, defining how clients can invoke a remote procedure by sending a SOAP message and how services can reply by sending another SOAP message back the caller. - A set of rules that any entity that processes a SOAP message must follow. - A description of how a SOAP message should be transported on top of HTTP and SMTP. 55

Schematic Representation of a SOAP message SOAP envelope SOAP header Optional can be processed by intermediate nodes Header block SOAP body Body block Mandatory Intended to the receiver 56

SOAP envelope SOAP body Agreement on the structure of the document SOAP envelope SOAP body Purchase. Order document - product item - quantity Acknowledgment document - order ID Document-style interaction SOAP envelope Agreement on the RPC method signature SOAP body SOAP envelope SOAP body Method name order. Goods Input parameter 1 product item Input parameter 2 quantity Methode return value order ID RPC-style interaction 57

The structure of a SOAP message is also influenced by encoding rules, which define how a particular entity or data structure is represented in XML. Transaction identifier <Product. Item> <name>…</name> <type>…</type> <make>…</make> </Product. Item> <Product. Item name=’’…’’ type=’’…’’ make=’’…’’ /> <Product. Item name=’’…’’ <type>…</type> <make>…</make> </Product. Item> <? xml version=’ 1. 0 ? > <env: Envelope xmlns: env=’’http: //www. w 3. org/2002/06/soap-envelope’’> <env: Header> <t: transaction. ID xmlns: t=’’http: //intermediary. example. com/procurement’’ env: role=’’http: //www. w 3. org/2002/06/soap-envelope/role/next’’ env: must. Understand=’’true’’ > 57539 </t: transaction. ID> </env: Header> <env: Body> <m: order. Goods env: encoding. Style=’’http: //www. w 3. org/2002/06/soap-encoding’’ xmlns: m=’’example. com/procurement’’> <m: product. Item> <name>ACME Softener</name> </m: product. Item> <m: quantity> 35 </m: quantity> </m: order. Goods> </env: Body> </env: Envelope> envelope header blocks body -none 58 -next -ultimate. Receiver

<wsdl: message name="Get. Last. Trade. Price. Input"> <wsdl: part name="body" element="xsd 1: Trade. Price. Request"/> </wsdl: message>  <wsdl: message name="Get. Last. Trade. Price. Output"> <wsdl: part name="body" element="xsd 1: Trade. Price"/> </wsdl: message>  <wsdl: port. Type name="Stock. Quote. Port. Type">  <wsdl: operation name="Get. Last. Trade. Price"> Get. Last. Trade. Price <wsdl: input message="tns: Get. Last. Trade. Price. Input"/> <wsdl: output message="tns: Get. Last. Trade. Price. Output"/> </wsdl: operation> </wsdl: port. Type> 59

SOAP Message Embedded in HTTP Request POST /Stock. Quote HTTP/1. 1 Host: www. stockquoteserver. com Content-Type: text/xml; charset="utf-8" Content-Length: nnnn SOAPAction: "Some-URI" <soapenv: Envelope xmlns: soapenv="http: //schemas. xmlsoap. org/soap/envelope/"> <soapenv: Body> <m: Get. Last. Trade. Price xmlns: m="Some-URI"> <m: ticker. Symbol>DIS</m: ticker. Symbol> </m: Get. Last. Trade. Price> </soapenv: Body> </soapenv: Envelope> SOAP Message Embedded in HTTP Response HTTP/1. 1 200 OK Content-Type: text/xml; charset="utf-8" Content-Length: nnnn <soapenv: Envelope xmlns: soapenv="http: //schemas. xmlsoap. org/soap/envelope/"> <soapenv: Body> <m: Get. Last. Trade. Price. Response xmlns: m="Some-URI"> <m: price>34. 5</m: price> </m: Get. Last. Trade. Price. Response> </soapenv: Body> </soapenv: Envelope> 60

A Simple Implementation of SOAP Service provider Proxy procedure located in a stub appended to the client at copmpile time Service requester client implementation invokes the service as local call client stub invoke SOAP engine to prepare SOAP message SOAP engine Packages SOAP into HTTP and passes it to an HTTP client that sends it to the provider HTTP engine service implementation invokes the local procedure of the service implementation server stub The router passes the message, identifies the appropriate stub, and delivers the parsed message SOAP router passes the content of HTTP message to the router HTTP server 61

WSDL: Web Services Description Language Originally created by IBM, Microsoft, and Ariba WSDL = merge of three previous proposals: • Microsoft SOAP Contract Language (SCL) and Services Description Language (SDL) • IBM’s Network Accessible Service Specification Language (NASSL) In WSDL, specifications are XML documents that describe Web services (service interfaces); that is operations offered by a Web service. Existing IDLs are tied to a concrete middleware platform. WSDL also needs to define the mechanisms to access the Web service. Lack of a common middleware platform the need for defining the location at which the service is available. 62

Structure of a WSDL interface Conceptually analogous to conventional IDL WSDL specification abstract part types each message is a typed document messages operations one-way notification asynchronous request-response synchronous solicit-response port types concrete part defines protocol binding and other information bindings services and ports 63

64

WSDL of service provider Using WSDL 1. 2. A contract that a Web service implements Input to a stub compilers and other tools 2 WSDL compiler (client side) 1 WSDL compiler (server side) service requestor service provider application object (client) application object (service provider) skeleton stub SOAP-based middleware WSDL generator SOAP messages SOAP-based middleware 65

UDDI: Universal Description Discovery and Integration Specification of a framework for describing and descovering Web services UDDI specification originated from: 1. Ariba and IBM collaborations on B 2 B 2. IBM and Microsoft collaborations on XML and SOAP 3. Microsoft and Ariba collaborations on Biz. Talk and c. XML First specification appeared in 2000 UDDI defines data structures and APIs for publishing service descriptions in the registry and for querying the registry to look for published descriptions 66

Information in a UDDI registry : organizations and contact information (e. g. , telephone, email White Pages address) and the services the organizations provide. Yellow Pages : classifications of both companies and Web services according to taxonomies. Green Pages : how a given service can be invoked (pointers to service description documents, typically stored outside the registry) 67

UDDI data structures A group of related Web services offered by a business entity business. Entity name contacts description identifiers categories business. Service service key name description categories binding. Template binding key description address detailed info references to t. Models t. Model key name description overview. Doc identifiers categories Specs stored at the provider’s site 68

UDDI t. Model: example <t. Model. Key=’’uddi: uddi. org: v 3_publication’’> <name>uddi-org: publication_v 3</name> <description>UDDI Publication API V 3. 0</description> <overview. Doc> <overview. URL use. Type=’’wsdl. Interface’’> http: //uddi. org/uddi_api_v 3_binding. wsdl#UDDI_Publication_Soap. Binding </overview. URL> </overview. Doc> <overview. URL use. Type=’’text’’> http: //uddi. org/pubs/uddi_v 3. htm#Pub. V 3 </overview. URL> </overview. Doc> <category. Bag> <keyed. Reference key. Name=’’uddi-org: types: wsdl’’ key. Value=’’wsdl. Spec’’ t. Model. Key=’’uddi: uddi. org: categorization: types’’/> <keyed. Reference key. Name=’’uddi-org: types: soap’ key. Value=’’soap. Spec’’ t. Model. Key=’’uddi: uddi. org: categorization: types’’/> <keyed. Reference key. Name=’’uddi-org: types: xml’’ key. Value=’’xml. Spec’’ t. Model. Key=’’uddi: uddi. org: categorization: types’’/> <keyed. Reference key. Name=’’uddi-org: types: specification’’ key. Value=’’specification’’ t. Model. Key=’’uddi: uddi. org: categorization: types’’/> </category. Bag> </t. Model> overview. Doc (refer to WSDL specs and to API specs) Classification information (specifies that this t. Model is about XML, WSDL and SOAP specs) 69

A (Java) program which resides and executes on a server to provide functionality to the server or processing of data on the server. Web services at work Case of a stored procedure service implementation server stub service provider 1 WSDL generator WSDL service descriptions 2 SOAP router WSDL compiler HTTP engine UDDI publisher 3 business. Entity business. Service binding. Template t. Model Inquiry API Publishers API UDDI registry 70

Service Coordination Protocols In real applications, interactions are typically more complex than single, independent invocations. Using a particular service typically involves performing sequences of operations in a particular order. customer (client) 1: request. Quote supplier (Web service) 2: order. Goods 3: make. Payment Complex internal logic Context information (conventional programming language or service composition) composition 71

Modeling Conversation between a Client and a Web Service Conversation: sequences of operations (i. e. , message exchanges) that could occur between a client and a Conversation service as part of the invocation of a Web service. Coordination protocol: the specification of the set of correct and accepted conversations. protocol request. Quote State machine quote requested order. Goods goods ordered cancel. Order order canceled make. Payments order completed WSCL 72

Modeling Conversations among Multiple Web Services (Multi-party Conversations) Reason: asynchronous nature of Web services 1: request. Quote customer 2: order. Goods 3: confirm. Order supplier 4: make. Payment 73

1: request. Quote customer 2: order. Goods 4: confirm. Order supplier 5: make. Payment 7: get. Shipment. Detail 3: check. Ship. Available 6: order. Shipment warehouse 8: confirm. Shipment 9: confirm. Shipment 74

Sequence diagram supplier customer warehouse request. Quote order. Goods check. Ship. Available confirm. Order make. Payment order. Shipment get. Shipment. Detail confirm. Shipment 75

customer supplier warehouse request. Quote (to supplier) order. Goods (to supplier) Activity diagram check. Ship. Available (to warehouse) confirm. Order (to customer) make. Payment (to supplier) confirm. Shipment (to warehouse) cancel. Order (to customer) order. Shipment (to warehouse) get. Shipment. Details (to customer) confirm. Shipment (to supplier) 76

Service Composition as a way to master complexity request. Quote notify. Payment customer (client) order. Goods supplier (Web service) make. Payment request. Quote another supplier (Web service) approval (Web service) 77

customer supply chain inventory planning … accounting … procurement approval supplier another supplier 78

Semantic Web 79

Semantic Web • It is the sucess of the web that creates serious needs for its improvement. • The web uses the computer as a device for rendering information for the human reader but neither for information processing nor computing. The semantic web is aiming on bringing back the computer as an information processing device. 80

Semantic Web • The semantic web is based on machineprocessable semantics of data. • It will significantly change our information access based on a higher level of service provided by computers. • It is based on new web languages such as XML, RDF, and OWL, and tools that make use of these languages. • Applications are in areas such as Knowledge Management (e. Work, e. Learning, e. Goverment, . . . ), Enterprise Application Integration, and e. Commerce. 81

The Evolving Web of Knowledge Proof, Logic and Ontology Languages DATA/PROGRAMS Shared terms/terminology Machine-Machine communication 2010 Resource Description Framework e. Xtensible Markup Language Hyper. Text Transfer Protocol Self-Describing Documents Foundation of the Current Web 2000 DOCUMENT S 1990 Berners-Lee, Hendler; Nature, 2001 82

Semantic Web Main achievements: • A ontology language proposal called OWL. • Several case studies for intranet applications and a methodology. • A three-layered software architecture for making the semantic web a reality. • A large number of interwoven web services that implement this vision. 83

Hierarchy of Languages DAML + Oi. L RDFS RDF XML 84

RDF – Resource Description Framework • Resources are related to each other by properties to form subject/predicate/object statements (triples). • The triples can be used to construct a graph: subject http: //purl. org/dc/elements/1. 1/title http: //www. w 3. org predicate http: //purl. org/dc/elements/1. 1/publisher object “W 3 C Home Page” object “WWW Consortium” • Statements themselves can be resources of other statements (i. e. reified statements) 85

RDF Syntax • Data model does not enforce particular syntax • Specification suggests many different syntaxes based on XML • General form: Starts an RDF-Description Subject (OID) <rdf: RDF> <rdf: Description about="http: //www. w 3. org/Home/Lassila"> <s: Creator>Ora Lassila</s: Creator> <s: created. With rdf: resource=“http: //www. w 3 c. org/amaya”/> </rdf: Description> </rdf: RDF> Literal Properties Resource (possibly another RDF-description) 86

Resulting Graph http: //www. w 3. org/Home/Lassila s: Creator Ora Lassila s: created. With http: //www. w 3 c. org/amaya <rdf: RDF> <rdf: Description about="http: //www. w 3. org/Home/Lassila"> <s: Creator>Ora Lassila</s: Creator> <s: created. With rdf: resource=“http: //www. w 3 c. org/amaya”/> </rdf: Description> </rdf: RDF> 87

RDF schema • Different from XML DTD: syntax vs. semantics • Defines Class, Property, sub. Class. Of, sub. Property. Of, domain, range, and some others • http: //www. w 3. org/TR/rdf-schema/ http: //www. w 3. org/TR/REC-rdf-syntax/ 88

Why RDF Is Not Enough • Only range/domain constraints on properties (need others) • No properties of properties (unique, transitive, inverse, etc. ) • No equivalence, disjointness, etc. • No necessary and sufficient conditions (for class membership) • No defined semantics 89

From RDF to DAML+OIL • DAML+OIL: DARPA Agent Markup Language – Current version unites early DAML language with OIL • DAML+OIL extends RDF statements to provide a rich descriptive logic language – Provides restrictions and additional notations on properties • Cardinality restrictions • Notations include inverse. Of, Transitivity, etc – Provides additional properties for class definitions • Disjoint-with, complement-Of, intersection. Of, etc – Provides universal & existential quantification through class restriction 90 http: //www. daml. org/language

DAML+Oil example Define a "product number"'s domain and range. . <daml: Datatype. Property rdf: ID="product. Number"> <rdfs: label>Product Number</rdfs: label> <rdfs: domain rdf: resource="#Product"/> <rdfs: range rdf: resource= "http: //www. w 3. org/2000/10/XMLSchema#non. Negative. Integer"/> </daml: Datatype. Property> ”Availability" is a sort of enumerated type. . <daml: Class ID="Availability"> <daml: one. Of parse. Type="daml: collection"> <daml: Thing rdf: ID="In. Stock"> <rdfs: label>In stock</rdfs: label> </daml: Thing> <daml: Thing rdf: ID="Back. Ordered"> <rdfs: label>Back ordered</rdfs: label> </daml: Thing> <daml: Thing rdf: ID="Special. Order"> <rdfs: label>Special order</rdfs: label> </daml: Thing> </daml: one. Of> 91 </daml: Class>

Semantic Web Layer Cake • Semantic Web layer cake proposed by Tim Berners-Lee • Build upon successive W 3 C standards • Add meaning through semantics to the existing WWW Ontology & Description Logic Defining Taxonomies Relating Statements Syntax Layer WWW Protocol DAML+OIL RDFS (RDF Schema) RDF XML HTTP 92

Web Services • Web Services will transform the web from a collection of information into a distributed device of computation. • Web services should transform e. Commerce from a nice application into a mass phenomena. • Bringing E-commerce to its full potential requires a Peer-to-Peer (P 2 P) approach. Anybody must be able to trade and negotiate with everybody else. • However, such an open and flexible E-commerce has to deal with many obstacles before it becomes reality! • The issue is scalability and economy in price. 93

Web Services Def 2. New concept for e. Work and e. Commerce Def 1. Software Architecture Figure Taken From Dieter Fensel Talk Def 3. New programming technology 94

Web Services Def 1. Web Services as a Software Architecture “Web services are a new breed of Web application. They are self-contained, selfdescribing, modular applications that can be published, located, and invoked across the Web services perform functions, which can be anything from simple requests to complicated business processes. … Once a Web service is deployed, other applications (and other Web services) can discover and invoke the deployed service. ” IBM web service tutorial 95

Web Services connect computers and devices with each other using the Internet to exchange data and combine data in new ways. The key to Web Services is on-the-fly software creation through the use of loosely coupled, reusable software components. Software can be delivered and paid for as fluid streams of services as opposed to packaged products. 96

Web Services Def 2. Web Services as a new Concept for e. Work and e. Commerce Web Services are Services accessible via the web Dieter Fensel`s definition 97

Web Services • Business services can be completely decentralized and distributed over the Internet and accessed by a wide variety of communications devices. • The internet will become a global common platform where organizations and individuals communicate among each other to carry out various commercial activities and to provide valueadded services. • The dynamic enterprise and dynamic value chains become achievable and may be even mandatory. 98

Web Services Def 3. Web Services as a programming technology Web Services are Remote Procedure Calls (RPC) over HTTP current state of the art 99

Web Services The web is organized around URIs, HTML, and HTTP. • URIs provide defined ids to refer to elements on the web, • HTML provides a standardized way to describe document structures (allowing browsers to render information for the human reader), and • HTTP defines a protocol to retrieve information from the web. ==> Not surprisingly, web services require a similar infrastructure around UDDI, WSDL, and SOAP. 100

Web Services UDDI WSDL SOAP URI HTML HTTP 101

Web Services • UDDI provides a mechanism for clients to find web services. A UDDI registry is similar to a CORBA trader, or it can be thought of as a DNS service for business applications. • WSDL defines services as collections of network endpoints or ports. A port is defined by associating a network address with a binding; a collection of ports define a service. • SOAP is a message layout specification that defines a uniform way of passing XML-encoded data. It also defines a way to bind to HTTP as the underlying communication protocol. SOAP is basically a technology to allow for “RPC over the web”. 102

Web Services • UDDI, WSDL, and SOAP are important steps into the direction of a web populated by services. • However, they only address part of the overall stack that needs to be available in order to achieve the above vision eventually. • There are many layer requires to achieve automatic web service discovery, selection, mediation and composition into complex services. 103

Web Services • Many organizations had the insight that message definition and exchange are not sufficient to build an expressive web services infrastructure. • In addition to UDDI, WSDL and SOAP, standards are proposed such as WSFL, XLANG, eb. XML, BPSS, BPML, WSCL, and BPEL 4 WS. Bringing web services to their full potential requires their combination with semantic web technology. 104

Semantic Web Services Imagine a travelling service: • Decompose into elementary services • Describe elementary services by goals instead of hardwiring them. • Keep the human programmer out of the loop to keep it economic, on demand, and scalable. You cannot achieve this vision without semantic web technology that maintains selection and combination of heterogeneous selection combination web services during runtime 105

Semantic Web Services • Mechanized support is needed, for example in finding and comparing vendors and their offers. Machine processable semantics of information allows to mechanize these tasks. • Mechanized support is needed in dealing with numerous and heterogeneous data formats. Ontology technology is required to define such standards better and to map between them. • Mechanized support is needed in dealing with numerous and heterogeneous business logics. Mediation is needed to compensate these differences, allowing partners to cooperate properly. 106

Semantic Web Services web services • The WSMF consists of four main different elements: repositories mediators – ontologies that provide the terminology used by other elements; – goal repositories that define the problems that should be solved by web services; – web services descriptions that define various aspects of a web service; – and mediators which bypass interoperability problems. ontologies 107

500 million user more than 3 billion pages Static Semantic Web enabled Web Services The General Vision WWW URI, HTML, HTTP 108

Serious Problems in information • finding • extracting • representing • interpreting • and maintaining WWW Static URI, HTML, HTTP Semantic Web enabled Web Services The General Vision Semantic Web RDF, RDF(S), OWL 109

Web Services Dynamic UDDI, WSDL, SOAP WWW Static URI, HTML, HTTP Bringing the computer back as a device for computation Semantic Web enabled Web Services The General Vision Semantic Web RDF, RDF(S), OWL 110

Bringing the web to its full potential Web Services Intelligent Web Services WWW Semantic Web Dynamic UDDI, WSDL, SOAP Static Semantic Web enabled Web Services The General Vision URI, HTML, HTTP RDF, RDF(S), OWL 111

Semantic Web Services 112

Semantic Web Services Semantic Web Techniques Web Services techniques Existing Web 113

Semantic Web enabled Web Services 114

Slide taken from Grosof’s Talk 115

Slide taken from Grosof’s Talk 116

117 Slide taken from Grosof’s Talk

Describing & Discovering Agents & Services on the Semantic Web • DAML – DARPA Agent Markup Language! • Can be used as a tool to investigate and solve many of the agent-based semantic mismatch issues – i. e. Semantic mismatches in agent discovery, selection, negotiation, interoperation, & in the composition/planning of larger scale solutions • DAML -S Coalition formed to explore DAML for Services 118

DAML-S • An upper ontology for describing the properties & capabilities of agents & (Web) services in an unambiguous, computer interpretable markup language. • Built as an additional layer above DAML+OIL • Designed to the following automated tasks… http: //www. daml. org/services 119

Automation enabled by DAML-S • Web Service Discovery & Selection – Find an airline that can fly me to Toulouse, France. • Web Service Invocation – Book flight tickets from Air. France to arrive 21 st Aug. • Web Service Composition & Interoperation – Arrange taxis, flights and hotel for travel from Lyon to Toulouse, OR, via Paris. • Web Service Execution Monitoring – Has the taxi to Toulouse Blagnac Airport been reserved yet? 120

Layered Approach to Language Development XML DAML-S (Services) DAML+OIL RDFS (RDF Schema) RDF • The first major application of DAML+OIL • Layer exists above DAML+OIL & RDF • Future versions will build upon emerging layers (e. g. DAMLRules etc) HTTP 121

DAML-S Upper Ontology . input types. output types. preconditions. postconditions . communication protocol (RPC, HTTP, …). port number. marshalling/serialization • process flow • composition hierarchy • process definitions 122

DAML-S Service Models 123

Presenting Service Profiles • Service Profile – Presented by a service. – Represents “what the service provides” – One can derive: • Service Advertisements • Service Requests 124

DAML-S Service Profile Non Functional Properties Functionality Description 125

DAML-S Service Profile Functionality Description • Functional Specification of what the service provides in terms of parameters, subclassed as: – preconditions – inputs – outputs – effects 126

DAML-S Service Profile Functionality Description • Preconditions – Set of conditions that should hold prior to service invocation • Inputs – Set of necessary inputs that the requester should provide to invoke the service • Outputs – Results that the requester should expect after interaction with the service provider is completed • Effects – Set of statements that should hold true if the service is invoked successfully. – Often refer to real-world effects • Package being delivered, or Credit card being debited 127

DAML-S Service Profile Functionality Description • An Input/Output/Precondition/Effect parameter has three properties: – parameter. Name: the name of the parameter – restricted. To : a resource corresponding to some RDF/DAML property type within some ontology (i. e. the range of a parameter instance) – refers. To : the corresponding parameter defined within the process model 128

DAML-S Service Profile Functionality Description 129

DAML-S Service Profile Non Functional Properties • Provides supporting information about the service. 130

DAML-S Service Profile Non Functional Properties • These include – – – – service. Name text. Description has_process quality. Rating service. Parameter service. Category contact. Information 131

DAML-S Service Profile Non Functional Properties - Actor 132

DAML-S Service Profile Non Functional Properties Quality. Rating 133

DAML-S Service Profile Non Functional Properties – Service. Category 134

DAML-S Service Profile Non Functional Properties – Service. Parameter 135

Profile Hierarchy • Sub-classing the Profile model facilitates the creation and specialisation of service categories • Each subclass can: – Introduce new properties – Place restrictions on existing properties • Sub-classing can also be used to specialise requests for service • An example Profile Hierarchy is provided, but others could just as easily be defined 136

Profile Hierarchy – sample ontology 137

DAML-S Service Models 138

Describing Service Models • Service Process – Describes how a service works. • Facilitates – (automated) Web service invocation – composition – interoperation – monitoring 139

DAML-S Service Model (Overview) 140

Types of the process in DAML-S • Atomic processes: directly invokable (by an agent), have no subprocesses, executed in a single step. • Composite processes: consist of other (non-composite or composite) processes. They have a composed. Of property, by which the control structure of the process is indicated, using a Control. Construct subclasses (see table …). • Simple processes: abstract concepts, used to provide a view of some atomic process, or a simplified representation of some composite process (i. e. , the “black box” view of a collapsed composite process). 141

Atomic Process Example <!– Atomic Process Definition - Get. Desired. Flight. Details --> <rdfs: Class rdf: ID="Get. Desired. Flight. Details"> <rdfs: sub. Class. Of rdf: resource="http: //www. daml. org/Process#Atomic. Process" /> </rdfs: Class> <!– (sample) Inputs used by atomic process Get. Desired. Flight. Details --> <rdf: Property rdf: ID="departure. Airport_In"> <rdfs: sub. Property. Of rdf: resource="http: //www. daml. org/Process#input" /> <rdfs: domain rdf: resource="#Get. Desired. Flight. Details" /> <rdfs: range rdf: resource="http: //www. daml. ri. cmu. edu/ont/ DAML-S/concepts. daml#Airport" /> </rdf: Property> <rdf: Property rdf: ID="outbound. Date_In"> <rdfs: sub. Property. Of rdf: resource="http: //www. daml. org/Process#input" /> <rdfs: domain rdf: resource="#Get. Desired. Flight. Details" /> <rdfs: range rdf: resource="http: //www. daml. ri. cmu. edu/ont/ DAML-S/concepts. daml#Flight. Date" /> </rdf: Property> Airport Flight Date departure. Airport_In Atomic. Process Get. Desired Flight Details outbound. Date_In 142

Composite Process Example <rdfs: Class rdf: ID="Book. Flight"> <rdfs: sub. Class. Of rdf: resource="#Composite. Process" /> <rdfs: sub. Class. Of rdf: resource="http: //www. daml. org/Process#Sequence" /> <daml: sub. Class. Of> <daml: Restriction> <daml: on. Property rdf: resource="http: //www. daml. org/Process#components" /> <daml: to. Class> <daml: sub. Class. Of> <daml: union. Of rdf: parse. Type="daml: collection"> <rdfs: Class rdfs: about="#Get. Flight. Details" /> <rdfs: Class rdfs: about="#Get. Contact. Details" /> <rdfs: Class rdfs: about="#Reserve. Flight" /> <rdfs: Class rdfs: about="#Confirm. Reservation" /> </daml: union. Of> Composite Process </daml: sub. Class. Of> </daml: to. Class> Book. Flight </daml: Restriction> </daml: sub. Class. Of> </rdfs: Class> Get Flight Details Get Contact Details Sequence Reserve Flight Confirm Reservation 143 Sequence

DAML-S Service Models 144

Supporting a Service Grounding • Service Grounding – Provides a specification of service access information. – Service Model + Grounding give everything needed for using the service – Builds upon WSDL to define message structure and physical binding layer • Specifies: – communication protocols, transport mechanisms, agent communication languages, etc. 145

WSDL (Web Services Description Language) • Structured mechanism to describe: – – Abstract operations that a Web Service can perform Format of messages it can process Protocols it can support Physical bindings to: • communication languages, e. g. SOAP or HTTP messages • Location of services, i. e. URI and port numbers • XML based • Current Status: – Developed by IBM and Microsoft – Version 1. 1 submitted as a W 3 C Note 146

WSDL Components • Types – containers for XSD data type definitions • Message – abstract definition of the data being communicated • Operation – abstract message exchange protocol • Port Type – abstract set of operations • Binding – concrete protocol and data format for a port type • Port – single, physical endpoint • Service – collection of related endpoints 147

DAML-S / WSDL Binding DAML-S Process Model Atomic Process Resources/Concepts Inputs / Outputs Message Operation Binding to SOAP, HTTP, etc. WSDL 148

DAML-S / WSDL Mapping 149

Service Grounding The class Service supports a Service. Grounding, that describes a mapping from an abstract (Service. Profile and Service. Model) to a concrete specification of the service description elements, that are required for interacting with the service, i. e. the inputs and outputs of atomic processes. The central function of a DAML-S grounding is to show the (abstract) inputs and outputs of an atomic process are to be realized concretely as messages, which carry those inputs and outputs in some specific transmittable format (e. g. RPC, CORBA, Java RMI, HTTP etc. ). 150

Reasoning in DAML-S • Service requests are constructed as partial service descriptions. • Requests are then evaluated against the advertised service taxonomy using subsumption (classification). • Matches are generally recognized whenever the service advertised is subsumed by (is a particular case of) the service description requested. Note: Advertisements and requests can differ sharply, in level of detail and in the level of abstraction of the terms used. 151

A whole example can be found at: http: //www. daml. org/services/daml-s/2001/05/Congo. daml 152

153

154

155

156

157

158

159

160

161

162

163

164

165

166

167

Services modelling (from www. sncf. com) Timetable_SNCF_One_Way_Ticket Travel transport_means. Train date. Departure. Date hour. Departure. Hour nb. Adults. Integer category. Boolean Voyage lieu_dep. Chaîne_car lieu_arr. Chaîne_car 168

Services modelling (from www. sncf. com) Timetable_SNCF_One_Way_Ticket Travel transport_means. Train date. Departure. Date hour. Departure. Hour nb. Adults. Integer category. Boolean Voyage lieu_dep. Chaîne_car lieu_arr. Chaîne_car 169

Services modelling (from www. sncf. com) Timetable_SNCF_One_Way_Ticket Travel transport_means. Train date. Departure. Date hour. Departure. Hour nb. Adults. Integer category. Boolean Voyage lieu_dep. Chaîne_car lieu_arr. Chaîne_car 170

Services modelling (from www. sncf. com) Timetable_SNCF_One_Way_Ticket Travel transport_means. Train date. Departure. Date hour. Departure. Hour nb. Adults. Integer category. Boolean Travel lieu_dep. Chaîne_car lieu_arr. Chaîne_car 171

Services modelling (from www. sncf. com) Timetable_SNCF_One_Way_Ticket Travel transport_means. Train date. Departure. Date hour. Departure. Hour nb. Adults. Integer category. Boolean Voyage lieu_dep. Chaîne_car lieu_arr. Chaîne_car 172

Services modelling (from www. sncf. com) Timetable_SNCF_One_Way_Ticket Travel transport_means. Train date. Departure. Date hour. Departure. Hour nb. Adults. Integer category. Boolean Voyage lieu_dep. Chaîne_car lieu_arr. Chaîne_car 173

Services modelling (from www. sncf. com) Timetable_SNCF_One_Way_Ticket Travel transport_means. Train date. Departure. Date hour. Departure. Hour nb. Adults. Integer category. Boolean Voyage lieu_dep. Chaîne_car lieu_arr. Chaîne_car 174

compute. BCov features • rewriting algorithm – Transform a query into another query expressed in terms of services names defined in the ontology – Compute the differences « query – rewriting » and « rewriting – query » as concept descriptions on which other reasonings can be applied initiate a user-machine dialogue to make him precise his query • combinatorial search – Optimized exploration of all possible combinations of services names (exponential space) – Only best are displayed (possibility to order worse additional solutions) • inference technique – Logical inference done in parallel with combinatorial exploration – Solutions may be found even if query’s terms and services’ 175 terms are not the same

Example : the rewriting process User query System answer 176

Example : the rewriting process User query System answer In this case, only one best combination of services : Q 6 ter query is rewritten into the combination of 2 services : { Inn_France, Timetable_SNCF_One_Way_Ticket} 177

Example : difference query-services User query System answer First difference between the query and the rewriting : Part of the query that does not match any part of any service : the « rest » . The rest can be sent to other discovery systems as a new query. 178

Example : difference query-services User query System answer Second difference between the query and the rest : Parts of the services that do not match any part of the query : the « miss » . The miss can be reused in order to automatically generate forms in which the user can add mandatory details in order to run the services. 179

Example : the rewriting process User query Step 1 : concept normalization Proposed services Useful concepts (from the ontology) for normalization 180

Example : the rewriting process User query Proposed services Step 2 : concept matching etc… Useful concepts (from the ontology) for normalization 181

Conclusion 182

183 Slide taken from Grosof Talk

184

• Logic – I am an employee of UMBC is a member of W 3 C. UMBC has GET access to http: //www. w 3. org/Member/. I (therefore) have access to http: //www. w 3. org/Member/. • Proof – UMBC's document employ. List lists me as an employee. W 3 C'c member list includes UMBC. The ACLs for http: //www. w 3. org/Member/ assert that employees of members have GET access. • Trust – UMBC's document employ. List is signed by a private key that W 3 C trusts to make such assertions. W 3 C'c member list is trusted by the access control mechansim. The ACLs for http: //www. w 3. org/Member/ were set by an agent trusted by the access control mechanism. 185

Some tools, software, and systems Pellet : http: //www. mindswap. org/2003/pellet/demo Onto. Link : http: //www. mindswap. org/2004/Onto. Link/ Photo. Stuff : http: //www. mindswap. org/2003/Photo. Stuff/ Swoop and Swoop. Ed : http: //www. mindswap. org/2004/SWOOP/ METEOR-S : http: //lsdis. cs. uga. edu/projects/METEOR-S/ GLUE : http: //www. themindelectric. com. . . 186

Resources • Web Services: Concepts, Architecture and Applications. G. Alonso, F. Casati, H. Kuno, V. Machiraju, Springer Verlag 2004 • DAML+OIL – http: //www. daml. org/language • OWL – http: //www. w 3. org/2001/sw/Web. Ont/ • DAML-S – http: //www. daml. org/services/ http: //www. w 3. org/2002/ws/ http: //www. computer. org/intelligent/ http: //classweb. gmu. edu/kersch/infs 770/Topics/web_services. htm 187

Example: an atomic process The Locate. Book program takes as input the name of a book and returns a description of the book and its price (if the book is in catalogue). <daml: Class rdf: ID=”Locate. Book”> <rdfs: sub. Class. Of rdf: resouce=”http: //www. daml. org/services/damls/2001/10/Process. daml#Atomic. Process” /> <rdfs: sub. Class. Of> <daml: Restriction daml: cardinality=” 1”> <daml: on. Property rdf: resource=”#book. Name”/> </rdfs: sub. Class. Of> </daml: Class> <rdf: Property rdf: ID=”book. Name”> <rdfs: sub. Property. Of rdf: resource=”http: //www. daml. org/services/damls/2001/10/Process. daml#input” /> <rdfs: domain rdf: resource=”#Locate. Book”/> <rdfs: range rdf: resource=”http: //www. w 3. org/2000/10/XMLSchema#string"/> </rdf: Property> 188

Example: an atomic process <rdf: Property rdf: ID=”book. Description”> <rdfs: sub. Property. Of rdf: resource=”http: //www. daml. org/services/damls/2001/10/Process. daml#conditional. Output” /> <rdfs: domain rdf: resource=”#Locate. Book”/> <rdfs: range rdf: resource=”In. Catalogue. Book. Description”/> </rdf: Property> <daml: Class rdf: ID=”In. Catalogue. Book. Description”> <rdfs: sub. Class. Of rdf: resouce=”http: //www. daml. org/services/damls/2001/10/Process. daml#Conditional. Output” /> </rdfs: sub. Class. Of> </daml: Class> 189

Example: an atomic process <rdf: Property rdf: ID=”cond. In. Catalogue. Book. Description”> <rdfs: sub. Property. Of rdf: resource=”http: //www. daml. org/services/damls/2001/10/Process. daml#co. Condition” /> <rdfs: domain rdf: resource=”#In. Catalogue. Book. Description”/> <rdfs: range rdf: resource=”#In. Catalogue. Book”/> </rdf: Property> <rdf: Property rdf: ID=”out. In. Catalogue. Book. Description”> <rdfs: sub. Property. Of rdf: resource=”http: //www. daml. org/services/damls/2001/10/Process. daml#co. Output” /> <rdfs: domain rdf: resource=”#In. Catalogue. Book. Description”/> <rdfs: range rdf: resource=”#Text. Book. Description”/> </rdf: Property> <daml: Class rdf: ID=”Text. Book. Description”> <rdfs: sub. Class. Of rdf: resource=” http: //www. daml. org/2001/03/daml+oil#Thing” /> </daml: Class> 190

Example: a composite process With a description of each of the atomic programs/processes in hand, it is possible then to describe compositions of these programs that provide specific services. The DAML-S composite process is built recursively in a topdown manner. Each Composite. Process is composed. Of a Control. Structure, which may be a Sequence, If-thenelse, etc. Each such Control. Construct, in turn, has a ”components” property, which specify the classes of the subcomponents. 191

Example: a composite process In the Congo example, Congo. Buy was described in terms of two main steps – locating the book, and then buying it. Expanded. Congo. By is the name for the sequence of the atomic process Locate. Book, followed by the composite process Congo. Buy. Book. Other restrictions (on inputs, outputs, preconditions and effects) can also be specified. 192

Example: a composite process <daml: Class rdf: ID=”Expanded. Congo. Buy”> <rdfs: sub. Class. Of rdf: resouce=”http: //www. daml. org/services/damls/2001/10/Process. daml#Composite. Process” /> <rdfs: sub. Class. Of> <daml: Restriction> <daml: on. Property rdf: resource=”http: //www. daml. org/services/damls/2001/10/Process. daml#composed. Of “/> <daml: to. Class> <daml: intersection. Of rdf: parse. Type=”daml: collection”> <daml: Class rdf: about=”process: Sequence”/> <daml: Restriction> <daml: on. Property rdf: resource=” process: components”/> <daml: to. Class> <daml: list. Of. Instance. Of rdf: parse. Type=”daml: collection”> <daml: Class rdf: about=”#Locate. Book/”> <daml: Class rdf: about=”#Congo. Buy. Book/”> </daml: list. Of. Instance. Of rdf: parse. Type=”daml: collection”> </daml: Class> </daml: to. Class> </daml: Restriction> </daml: intersection. Of> </daml: Class> </daml: to. Class> </daml: Restriction> </rdfs: sub. Class. Of> </daml: Class> 193

Conclusions DAML-S is an upper ontology for describing Web-Services, written in DAML+OIL. By providing a rich declarative representation and an efficient reasoning support, DAML-S addresses the objective of making Web Services computer-interpretable and, hence, enables their automatic discovery, invocation, verification, composition and interoperation as well as execution monitoring. 194