The inventor of the World Wide Web, Tim Berners-Lee, is also the originator of the next generation of Web architecture, the Semantic Web. Currently, his World Wide Web consortium (W3C) team works to develop, extend, and standardize the Web’s markup languages and tools.
The objective of the Semantic Web Architecture is to provide a knowledge representation of linked data in order to allow machine processing on a global scale. The W3C has developed a new generation of open standard markup languages that are now poised to unleash the power, flexibility and, above all, logic of the next generation of the Web, and open the door to the next generation of Web Services.
Currently, Web Services that use the .NET and J2EE frameworks are struggling to expand against the limitations of existing Web architecture and conflicting proprietary standards. With software vendors battling for any advantage, Semantic Web Services offer a giant leap forward; the first-time developer can successfully exploit its latent potential to deliver such applications as semantic search, collective email and collaborative Web word processing.
Why do we need such a system? Today, the data available within HyperText Markup Language (HTML) is difficult to manipulate on a large scale. Just think of information about plane schedules, baseball statistics, and product purchasing information. While presently available at numerous sites, using this data in its HTML form is problematic, even is eXtensible Markup Language (XML) is employed. The Semantic Web offers an easier way to publish data that can be accessed and re-purposed as needed.
Semantic Web Services
For Semantic Web services to become a reality, a markup language must be descriptive enough that a computer can automatically determine its meaning. The following is a list of tasks such a language would be required to perform:
- Discovery: A program must first be able to automatically find, or discover, an appropriate Web service. Neither the Web Service Description Language (WSDL) nor the Universal Discovery and Description language (UDDI) allows for software to determine what a Web service offers to the client. A Semantic Web service describes its properties and capabilities so that software can automatically determine its purpose.
- Invocation: Software must be able automatically to determine how to invoke or execute the service. For example, if executing the service is a multi-step procedure, the software needs to know how to interact with the service to complete the necessary sequence. A Semantic Web service provides a descriptive list of what an agent needs to do to be able to execute and fulfill the service. This includes defining the inputs and outputs of the service.
- Composition: Software must be able to select and combine a number of Web services to complete a certain objective. The services have to interoperate with each other seamlessly so that the combined results are a valid solution.
- Monitoring: Agent software needs to be able to verify and monitor the service properties while in operation.
When Web markup languages evolve to the point that they can perform the above tasks, Semantic Web service can begin to prosper. You may be surprised to learn just how near the W3C is to meeting these conditions.
Advanced Markup Languages
There are many ways in which the two areas of Web Services and the Semantic Web could interact to lead to the further development of Semantic Web Services. Berners-Lee has suggested that both of these technologies would benefit from integration that would combine the Semantic Web’s meaningful content with Web Services’ business logic.
Areas such as UDDI and WSDL are ideally suited to be implemented using Semantic Web technology. In addition, SOAP could use Resource Description Framework (RDF) payloads, remote RDF queries and updates, and interact with Semantic Web business rules engines, thereby laying the foundation for Semantic Web Services.
The W3C is engaged in building the Pyramid of Web Markup Languages, which starts with HTML and XML and continues upward to include RDF and the most recent Web Ontology Language (OWL). The off-spring of OWL is OWL for Services (OWL-S).
However, the technology issues of the Next Generation Web create many problematic questions that must be solved before the full power and capability of the Semantic Web Services are available.
Figure 1 – The Markup Language Pyramid
Concerns about logic loops, syntax errors and trust-worthy published information remain formidable problems. Despite this, several credible examples of Semantic Web Services are well under way. The next section presents an example developed by the DAML organization.
OWL-S Example: Congo.com
Current XML-based Web Service technology provides limited support in mechanizing service recognition, service configuration and combination, service comparison, and automated negotiation. In a business environment, the vision of flexible and autonomous Web Service translates into automatic cooperation between enterprise services. Any enterprise requiring a business interaction with another enterprise needs automatically to discover and select the optimal Web Services. Any necessary mediation would be applied on the basis of data and processes using automatic translation for semantic interoperations.
In order to design an automatic self-regulating OWL-S-based Web Service Ontology, it is necessary to understand how the automatic service will operate within a complex dynamic environment and how it will respond to a wide variety of outside stimuli. Unlike traditional computer projects, designing an OWL-S-based Web Service requires detailed analysis that exposes and eliminates semantic logic conflicts and indeterminacies. Because OWL-S-based Web Services seek to remove humans from interactions and leave automated processes in place, logic conflicts would result in unacceptable transaction failure rates.
In this section, we’ll look at the phases and steps necessary to design and implement an OWL-S-based Web Service. We’ll illustrate the design process through an example for an online book service that offers users the ability to select a book, collect buyer information, collect payment and deliver the book. We walk through an OWL-S online book buying example called Congo.com provided by www.daml.org, which is available for download at http://daml.semanticweb.org/services/owl-s/1.0/. This example provides details of the transactions, processes and flow paths of the service performance.
Design of an Online Book Store
In order to design an online book service, we require the following transactions: the ability to make a selection of books, collect information about the buyer, collect his payment and deliver the book. These transactions are delineated as follows:
- Book search capability to locate the desired book
- Place book in individual’s shopping cart
- Individual signs-in, and
- Load profile, or
- Create new account, and
- Create new profile
- Specify delivery details
- Finalize purchase
- Book distribution
- Book delivery
The Congo, Inc. Online Book Store
The Congo.com example is a fictitious book-buying service offered by the fictitious Web Service provider, Congo, Inc. This book-buying service uses the design we just described and produces a suite of Web programs called LocateBook, PutInCart, SignIn, CreateAcct, CreateProfile, LoadProfile, SpecifyDeliveryDetails, and FinalizeBuy. The composite service CongoBuy is composed of this suite of smaller programs required for a user to buy books.
The OWL-S specification for encoding of the profile ontology, the process ontology and the grounding ontology can be found at http://daml.semanticweb.org/services/owl-s/1.0/ The Congo.com example source code is available at http://daml.semanticweb.org/services/owl-s/1.0/examples.html
Task-Driven Markup of Web Services
In the Congo.com example, Web Service provider Congo Inc. is considering using three automation tasks enabled with OWL-S markup:
- automatic Web Service discovery
- automatic Web Service invocation
- automatic Web Service composition and interoperation
In the following sections, we first provide a description of the Web-accessible programs through a process model and grounding description in order to provide automatic invocation and composition. Then, we provide a means of advertising the properties and capabilities through a profile description for automatic discovery.
Describing the Congo.com Transaction Programs
The development of ontology for the Congo.com Web Service involves four steps as follows:
- Describe Individual Programs: describe the individual programs that comprise the service. The process model provides a declarative description of a program’s properties.
- Describe the Grounding for Each Atomic Process: e.g. relate LocateBook to its grounding, LocateBookGrounding.
- Describe Compositions of the Atomic Processes: e.g. describe the composite process CongoBuyBook, which is a composition of LocateBook, PutInCart, etc.
- Profile Description: provide a declarative advertisement for the service. It is partially populated by the process model.
The Congo.com Web Service begins by describing the program that utilizes the service. OWL-S provides for a declarative description of the programs in terms of a process model. This provides the descriptors to automate Web Service invocation, and Web Service composition and interoperation.
To enable automated Web Service invocation, a Web Service must be able to tell an external agent how to interact with the Web Service, for example, how to automatically construct an HTTP call to execute or invoke a Web Service, and what outputs are returned from the service. To compose services, the process model must describe the preconditions necessary for its execution, and its effects. OWL-S provides the process ontology to accomplish this. The markup then enables the Web Service provider to include sufficient information for automating Web Service invocation as well as automating Web Service composition. The Congo Service Ontology is shown in Figure 2 above.
Step 1: Describe Individual Programs
The first step in developing Congo.com is to describe the individual programs that are to comprise the service. The process model provides a declarative description of a program’s properties.
Congo Inc. provides a book-buying OWL-S-based Web Service for its customers, called CongoBuy. This service is actually a collection of smaller Congo programs. We must first describe each of these individual programs, and then describe the composition of each, which becomes the ExpandedCongoBuy interactive service.
Throughout this example, we will refer to the profile ontology and the process ontology. These ontologies define classes and properties that form a service description. For a particular service, we specialize the classes and properties by creating subclasses and subproperties.
The Congo.com book-buying service uses a suite of eight Web-accessible transaction programs called LocateBook, PutInCart, SignIn, CreateAcct, CreateProfile, LoadProfile, SpecifyDeliveryDetails, and FinalizeBuy. The information flow through the Congo.com example is illustrated in Figure 3. The names of the programs reflect their functions, starting with LocateBook, where the user selects a book, through to FinalizeBuy, where the user completes his purchase. It is the process model that provides a declarative description of the properties of the Web-accessible programs.
The process model (shown in Listing 1, below) sees each program as either an atomic process or a composite process. In addition, it allows for the concept of a simple process, which will provide a simplified view of the composite CongoBuy program. A simple process is used to describe a view of an atomic or composite service to which it expands.
Listing 1 – Process Model
<owl:Class rdf:ID="Process">
<rdfs:comment> The most general class of processes </rdfs:comment>
<owl:unionOf rdf:parseType=" owl:collection">
<owl:Class rdf:about="#AtomicProcess"/>
<owl:Class rdf:about="#SimpleProcess"/>
<owl:Class rdf:about="#CompositeProcess"/>
</owl:unionOf>
</owl:Class>A non-decomposable Web-accessible program is described as an atomic process. An atomic process is characterized by its ability to be executed by a single HTTP call that returns a response.
<owl:Class rdf:ID="AtomicProcess">
<owl:subClassOf rdf:resource="#Process"/>
</owl:Class>The LocateBook program is an atomic process that takes as input the name of a book and returns a description of the book and its price (see Figure 4). For brevity, we refer to the inputs, outputs, preconditions and effects as “iope’s.”
<owl:Class rdf:ID="LocateBook">
<rdfs:subClassOf rdf:resource="&process;#AtomicProcess"/>
</owl:Class>If we want to put restrictions on the iope’s, (such as cardinality restrictions), we need to define LocateBook as follows in Listing 2, with some or all of its iope’s listed in the class definition.
Listing 2 – LocateBook Input
< owl:Class rdf:ID="LocateBook">
<rdfs:subClassOf rdf:resource="&process;#AtomicProcess"/>
<rdfs:subClassOf>
< owl:Restriction owl:cardinality="1">
<owl:onProperty rdf:resource="#bookName"/>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>Two types of parameters are the OWL-S properties input (see Listing 3) and output (see Listing 4).
Listing 3 – Properties General Input
<rdf:Property rdf:ID="parameter">
<rdfs:domain rdf:resource="#Process"/>
<rdfs:range rdf:resource="http://www.daml.org/2001/03/owl#Thing"/>
</rdf:Property>
<rdf:Property rdf:ID="input">
<rdfs:subPropertyOf rdf:resource="#parameter"/>
</rdf:Property>Associated with each process is a set of properties that, in turn, have associated parameters. Two types of parameters are the OWL-S properties input and (conditional) output. An example of an input for LocateBook might be the name of the book. We proclaim this using the subPropertyOf construct.
An example of an input for LocateBook would be the name of the book, “bookName”, as shown below:
<rdf:Property rdf:ID="bookName">
<rdfs:subPropertyOf rdf:resource="&process;#input"/>
<rdfs:domain rdf:resource="#LocateBook"/>
<rdfs:range rdf:resource="&xsd;#string"/>
</rdf:Property>Inputs can be mandatory or optional. In contrast, outputs are generally conditional. For example, when searching for a book in the Congo catalogue, the output may be a detailed description of the book, if Congo carries it; otherwise, it may be a “Sorry, unavailable” message. A conditional output class is ConditionalOutput, which describes both a condition and the output based on this condition.
Listing 4 – General Conditional Output Class
<rdf:Property rdf:ID="output">
<rdfs:domain rdf:resource="#parameter"/>
<rdfs:range rdf:resource="#ConditionalOutput"/>
</rdf:Property>
<owl:Class rdf:ID="ConditionalOutput">
<owl:subClassOf rdf:resource="http://www.daml.org/2001/03/owl#Thing"/>
</owl:Class>
<rdf:Property rdf:ID="coCondition">
<rdfs:domain rdf:resource="#ConditionalOutput"/>
<rdfs:range rdf:resource="#Condition"/>
</rdf:Property>
<rdf:Property rdf:ID="coOutput">
<rdfs:domain rdf:resource="#ConditionalOutput"/>
<rdfs:range rdf:resource="http://www.daml.org/2001/03/owl#Thing"/>
</rdf:Property>The process bookDescription is output-conditional and is dependent upon the book being in the Congo catalogue (see Listing 5).
Listing 5 – LocateBooks Output BookDescription
<rdf:Property rdf:ID="bookDescription">
<rdfs:subPropertyOf rdf:resource="&process;#conditionalOutput"/>
<rdfs:domain rdf:resource="#LocateBook"/>
<rdfs:range rdf:resource="InCatalogueBookDescription"/>
</rdf:Property>
<owl:Class rdf:ID="InCatalogueBookDescription">
<rdfs:subClassOf rdf:resource="&process;#ConditionalOutput"/>
</owl:Class>
<rdf:Property rdf:ID="condInCatalogueBookDescription">
<rdfs:subPropertyOf rdf:resource="&process;#coCondition"/>
<rdfs:domain rdf:resource="#InCatalogueBookDescription"/>
<rdfs:range rdf:resource="#InCatalogueBook"/>
</rdf:Property>
<rdf:Property rdf:ID="outInCatalogueBookDescription">
<rdfs:subPropertyOf rdf:resource="&process;#coOutput"/>
<rdfs:domain rdf:resource="#InCatalogueBookDescription"/>
<rdfs:range rdf:resource="#TextBookDescription"/>
</rdf:Property>
<owl:Class rdf:ID="TextBookDescription">
<rdfs:subClassOf rdf:resource="&owl;#Thing"/>
</owl:Class>The designation of inputs and outputs enables automation of the Web Service invocation. For automated composition and interoperation, program side-effects must be described. An action metaphor is used to conceive services having preconditions (described as properties) and a (conditional) effect, analogous to inputs and conditional outputs.
Preconditions specify what must be true in order for an agent to execute a service. Many Web Services have no preconditions except that the input parameters are known. However, Web-accessible devices may have many physical preconditions including bandwidth resources or battery power. Preconditions are described in the process ontology as properties, in the same manner as inputs.
<rdf:Property rdf:ID="precondition">
<rdfs:domain rdf:resource="#Process"/>
<rdfs:range rdf:resource="http://www.daml.org/2001/03/owl#Thing"/>
</rdf:Property>Step 2: Describe the Grounding for Each Atomic Process
The grounding for LocateBook is LocateBookGrounding. For the class LocateBook, every instance of the class has an instance of the hasGrounding property, with value LocateBookGrounding.
The hasGrounding property is defined in Process.owl.
<owl:Class rdf:about="LocateBook">
<owl:sameClassAs>
<owl:Restriction owl:cardinality="1">
<owl:onProperty rdf:resource="#hasGrounding"/>
<owl:hasValue rdf:resource="#LocateBookGrounding"/>
</owl:Restriction>
</owl:sameClassAs>
</owl:Class>Listing 6 is an example of a OWL-S Grounding Instance.
Listing 6 – LocateBookGrounding
<grounding:WsdlGrounding rdf:ID="LocateBookGrounding">
<grounding:wsdlReference rdf:resource="https://www.w3.org/TR/2001/NOTE-wsdl-20010315">
<grounding:otherReferences rdf:parseType="owl:collection">
"https://www.w3.org/TR/2001/NOTE-wsdl-20010315"
"http://schemas.xmlsoap.org/wsdl/soap/"
"http://schemas.xmlsoap.org/soap/http/"
</grounding:otherReferences>
<grounding:wsdlDocuments rdf:parseType="owl:collection">
"http://example.com/congo/congobuy.wsdl"
</grounding:wsdlDocuments>
<grounding:wsdlOperation
rdf:resource="http://example.com//locatebook.wsdl#FindBook"/>
<grounding:wsdlInputMessage
rdf:resource="http://example.com/locatebook.wsdl#LocateBookInput"/>
<grounding:wsdlInputMessageParts rdf:parseType="owl:collection">
<grounding:wsdlMessageMap>
<grounding:damlsParameter rdf:resource=#bookName>
<grounding:wsdlMessagePart
rdf:resource="http://example.com//locatebook.wsdl#BookName">
</grounding:wsdlMessageMap>
... other message map elements ...
</grounding:wsdlInputMessageParts>
<grounding:wsdlOutputMessage
rdf:resource="http://example.com/locatebook.wsdl#LocateBookOutput"/>
<grounding:wsdlOutputMessageParts rdf:parseType="owl:collection">
... similar to wsdlInputMessageParts ...
</grounding:wsdlOutputMessageParts>
<grounding:WsdlGrounding>Step 3: Describe Compositions of the Atomic Processes
So far, we have described each of the atomic processes and their iope’s. Now, we describe compositions of those programs that provide specific services. The CongoBuy composite service enables a user to buy a book.
In Listing 7, we provide the definition of a composite process in the process model. Notice that the composite process is composed of other processes.
In the Congo.com example, CongoBuy is described in terms of two main steps: locating the book and then buying the book .
ExpandedCongoBuy is name of the composition for the sequence of the atomic process LocateBook followed by CongoBuyBook.
While the locate book is an atomic process, the buying of a book involves a sequence of subprocesses corresponding to a payment method, the details of delivery and finalizing the buy process. Figure 6 shows the Congo Service Model.
Listing 7 – CompositProcess
<owl:Class rdf:ID="CompositeProcess">
<owl:intersectionOf rdf:parseType="owl:collection">
<owl:Class rdf:about="#Process"/>
<owl:Restriction daml:minCardinality="1">
<owl:onProperty rdf:resource="#composedOf"/>
</owl:Restriction>
</owl:intersectionOf>
</owl:Class>
<rdf:Property rdf:ID="composedOf">
<rdfs:domain rdf:resource="#CompositeProcess"/>
<rdfs:range rdf:resource="#ControlConstruct"/>
</rdf:Property>
The OWL-S composite process is recursively constructed in a top-down manner. Each CompositeProcess is composedOf a ControlConstruct, which may be a Sequence, Alternative, If-then-else, and so on. Each ControlConstruct has a property that specifies the classes of its subcomponents. These classes may also be processes or control constructs. Finally, the end is reached, when the components of a composite process are atomic processes.
ExpandedCongoBuy is the name for the sequence of the atomic process LocateBook, followed by composite process CongoBuyBook. As was the case with atomic processes, composite processes have iopes’s (inputs, outputs, preconditions and effects) and restrictions. Figure 5 above represents CongoBuy, which corresponds to Listing 8.
Listing 8 – ExpandedCongoBuy
<owl:Class rdf:ID="ExpandedCongoBuy">
<rdfs:subClassOf rdf:resource="&process;#CompositeProcess"/>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="&process;#composedOf"/>
<owl:toClass>
<owl:Class>
<owl:intersectionOf rdf:parseType="owl:collection">
<owl:Class rdf:about="process:Sequence"/>
<owl:Restriction>
<owl:onProperty rdf:resource="process:components"/>
<owl:toClass>
<owl:Class>
<owl:listOfInstancesOf rdf:parseType="owl:collection">
<owl:Class rdf:about="#LocateBook"/>
<owl:Class rdf:about="#CongoBuyBook"/>
</owl:listOfInstancesOf>
</owl:Class>
</owl:toClass>
</owl:Restriction>
</owl:intersectionOf>
</owl:Class>
</owl:toClass>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction owl:cardinality="1">
<owl:onProperty rdf:resource="#expCongoBuyBookName"/>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction owl:cardinality="1">
<owl:onProperty rdf:resource="#expCongoBuyCreditCardNumber"/>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction owl:cardinality="1">
<owl:onProperty rdf:resource="#expCongoBuyCreditCardType"/>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction owl:cardinality="1">
<owl:onProperty rdf:resource="#expCongoBuyCreditCardExpirationDate"/>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction owl:cardinality="1">
<owl:onProperty rdf:resource="#expCongoBuyDeliveryAddress"/>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction owl:cardinality="1">
<owl:onProperty rdf:resource="#expCongoBuyPackagingSelection"/>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction owl:cardinality="1">
<owl:onProperty rdf:resource="#expCongoBuyDeliveryTypeSelection"/>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>Creating a Service
Although the CongoBuy service is a composition of several of Congo’s transaction programs, it is useful to view it as a black-box process that expands the composite process. The black-box process enables the details of the operation of the composite process to be hidden. In the Congo example, a simple process called CongoBuy is (see Listing 9):
<owl:Class rdf:ID="CongoBuy">
<rdfs:subClassOf rdf:resource="&process;#SimpleProcess"/>
</owl:Class>The simple process is related to the composite ExpandedCongoBuy process through the expand property. CongoBuy expands to ExpandedCongoBuy.
Listing 9 – CongoBuy
<owl:Class rdf:about="#CongoBuy">
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="&process;#expand"/>
<owl:toClass rdf:resource="#ExpandedCongoBuy"/>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>As was the case with ExpandedCongoBuy, the black-box process, CongoBuy has a variety of properties that characterize its black-box view. The iope’s for the black-box process are designed for the computed iope’s of the associated composite process. For now, OWL-S leaves this decision up to the Web service provider.
Step 4: Profile Description – Advertising the Services
OWL-S has been designed to enable automated Web Service discovery by providing descriptions of the properties and capabilities. These descriptors exist in a registry of services, to provide for better indexing and retrieval by search engines. Markup for Web Service discovery requires the construction of a process model and that its profile is made available.
The descriptive information about the service and its provider is as follow:
<profile:profile rdf:ID="Profile_Congo_BookBuying_Service">The term isPresentedBy relates the profile to the service it describes, in this case Congo_BookBuying_Service.
<service:isPresentedBy>
<service:Service df:resource = "&congo;#Congo_BookBuying_Service"/>
</service:isPresentedBy>
The term serviceName is an identifier of the service that can be used to refer to the profile.
<profile:serviceName>Congo_BookBuying_Agent</profile:serviceName>
The term textDescription is a human readable description of the service.
<profile:textDescription>
This service provides a
book selling site
</profile:textDescription>The term providedBy describes the provider of the service.
Listing 10 – Profile providedBy
<profile:providedBy>
<profile:ServiceProvider rdf:ID="CongoBuy">
<profile:name>CongoBuy</profile:name>
<profile:phone>455 484 1256 </profile:phone>
<profile:fax>455 484 1234 </profile:fax>
<profile:email>congo@congo.com</profile:email>
<profile:physicalAddress>
location, USA
</profile:physicalAddress>
<profile:webURL>
http://www.daml.org/services/daml-s/0.9/CongoBuy.html
</profile:webURL>
</profile:ServiceProvider>
</profile:providedBy>The profile specifies additional attributes of the service.
The property profile:input is used to describe each key input to the corresponding process, using as values the descriptions of the class profile:ParameterDescription. ParameterDescriptions name the corresponding parameter properties of the process, and their value restrictions.
Due to limitations of the OWL language, there is no logical relationship between ParameterDescriptions in the Profile and the actual input, output, etc. parameters of the corresponding process model. Each input requires a name and a restriction on what information is requested, as well as a reference to the process model input used.
An input parameter is described by a name, a restriction on its values, and a reference to the input parameter in the profile it represents. The value restriction is used during matching to check whether the inputs that the requester is willing to provide match those required by the provider. The requester uses the inputs to identify the additional information it needs in order to provide to the service.
<input>
<profile:ParameterDescription>
<profile:parameterName rdf:resource="bookTitle"/>
<profile:restrictedTo rdf:resource="&xsd;#string"/>
<profile:refersTo rdf:resource="&congo;#congoBuyBookName"/>
</profile:ParameterDescription>
</input>Outputs are represented similarly to inputs. The restriction is used by the Web register to specify whether the service provides the outputs that are expected by the requester. The requester uses the outputs to know what additional knowledge it will acquire from the service.
<output>
<profile:ParameterDescription>
<profile:parameterName rdf:resource="EReceipt"/>
<profile:restrictedTo rdf:resource="&congoProcess;#EReceipt"/>
<profile:refersTo rdf:resource="&congo;#congoBuyReceipt"/>
</profile:ParameterDescription>
</output>Preconditions and effects have a similar structure to that of inputs and outputs. The main difference is that, instead of a restriction to some class, they have a statement which is defined as owl:Thing. Preconditions and effects are used by the registry in a way that is similar to the inputs and outputs.
<precondition>
<profile:ConditionDescription>
<profile:ConditionName rdf:resource="AcctExists"/>
<profile:statement rdf:resource="&congoProcess;#AcctExists"/>
<profile:refersTo
rdf:resource="&congo;#congoBuyAcctExistsPrecondition"/>
</profile:ParameterDescription>
</precondition>Finally, close the description of the service.
</profile:OfferedService>The complete Congo.com Service is given in Listing 11.
Listing 11 – CongoService.owl
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE uridef (View Source for full doctype...)>
<rdf:RDF xmlns:rdf="https://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:rdfs="https://www.w3.org/2000/01/rdf-schema#" xmlns:owl="https://www.w3.org/2002/07/owl#" xmlns:service="http://www.daml.org/services/owl-s/0.9/Service.owl#" xmlns="http://www.daml.org/services/owl-s/0.9/CongoService.owl#">
<owl:Ontology rdf:about="">
<owl:versionInfo>$Id: CongoService.owl,v 1.12 2003/09/19 05:06:47 martin Exp $</owl:versionInfo>
<rdfs:comment>This ontology represents the DAML-S service description for the Congo web service example.</rdfs:comment>
<owl:imports rdf:resource="https://www.w3.org/2002/07/owl" />
<owl:imports rdf:resource="http://www.daml.org/services/owl-s/0.9/Service.owl" />
<owl:imports rdf:resource="http://www.daml.org/services/owl-s/0.9/CongoProfile.owl" />
<owl:imports rdf:resource="http://www.daml.org/services/owl-s/0.9/CongoProcess.owl" />
<owl:imports rdf:resource="http://www.daml.org/services/owl-s/0.9/CongoGrounding.owl" />
</owl:Ontology>
<service:Service rdf:ID="ExpressCongoBuyService">
<!-- Reference to the Profile -->
<service:presents rdf:resource="http://www.daml.org/services/owl-s/0.9/CongoProfile.owl#Profile_Congo_BookBuying_Service" />
<!-- Reference to the Process Model -->
<service:describedBy rdf:resource="http://www.daml.org/services/owl-s/0.9/CongoProcess.owl#ExpressCongoBuyProcessModel" />
<!-- Reference to the Grounding -->
<service:supports rdf:resource="http://www.daml.org/services/owl-s/0.9/CongoGrounding.owl#CongoBuyGrounding" />
</service:Service>
<service:Service rdf:ID="FullCongoBuyService">
<service:presents rdf:resource="http://www.daml.org/services/owl-s/0.9/CongoProfile.owl#Profile_Congo_BookBuying_Service" />
<!-- Reference to the Process Model -->
<service:describedBy rdf:resource="http://www.daml.org/services/owl-s/0.9/CongoProcess.owl#FullCongoBuyProcessModel" />
<!-- Reference to the Grounding -->
<service:supports rdf:resource="http://www.daml.org/services/owl-s/0.9/CongoGrounding.owl#FullCongoBuyGrounding" />
</service:Service>
</rdf:RDF>
http://www.daml.org/services/owl-s/0.9/CongoService.owl
How to Prepare for Semantic Web Services
Few developers today are actively building Semantic Web services. Yet, as the standards are completed and the demand for intelligent agents grows, expertise will be required in the field of Semantic Web services. Keeping informed, adopting early prototypes, and anticipating change is essential to developers who want to stay ahead of the curve.
Developers should monitoring key Websites to stay informed as the Semantic Web progresses. The World Wide Web Consortium coordinates all formal Semantic Web specifications. Alternatively, the DARPA Agent Markup Language Homepage contains use cases, tools, ontologies, and other useful resources for creating semantic markup. New books and research papers are also worth investigating.
Many of the development tools available today are free — some as open-source projects. The W3C maintains links to many free tools, and commercial tools can be found at SemanticWeb.org.
Conclusion
The Semantic Web and Web services initiatives are closely related. Both share the high-level objective of making information on the current World Wide Web accessible and usable to software agents. Semantic Web services are the powerful combination of two evolving technologies.
H. Peter AlessoPeter, of www.web-iq.com, is an Internet innovator with twenty years research experience at Lawrence Livermore National Laboratory (LLNL). As Engineering Group Leader at LLNL he has led a team of computer scientists, physicists and engineers in a wide range of innovative software projects.
