Article
Preparing for Semantic Web Services
Page: 1 2
Listing 6 is an example of a OWL-S Grounding Instance.
Listing 6 – LocateBookGrounding
<grounding:WsdlGrounding rdf:ID="LocateBookGrounding">
<grounding:wsdlReference rdf:resource="http://www.w3.org/TR/2001/NOTE-wsdl-20010315">
<grounding:otherReferences rdf:parseType="owl:collection">
"http://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="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xmlns:owl="http://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="http://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.