This document provides a walk-through example of the use of the OWL-S Web Service Ontologies (version 1.2) for describing Web services. OWL-S is written in OWL (March 2001). This walk-through is not intended as a complete description of OWL-S. For a complete specification of OWL-S, please refer to the OWL-S technical overview.
OWL-S comprises several ontologies in OWL, the Web Ontology Language. Throughout this walk-through, we will refer to the profile ontology, the process ontology and the grounding ontology. Each is described in more detail in the technical section of the OWL-S distribution. The OWL encoding of these ontologies are defined by OWL ontology definition documents Profile.owl, Process.owl., and Grounding.owl of this release, respectively.
Our walk-through utilizes the example of a fictitious book-buying service offered by the Web service provider, Congo Inc. Congo has a suite of programs that they are making accessible on the Web. These programs (self-described by their names) are LocateBook, PutInCart, SignIn, CreateAcct, CreateProfile, LoadProfile, SpecifyDeliveryDetails, and FinalizeBuy. We walk through the exercise of Congo Inc., marking up a subset of these Congo web services in the OWL-S ontology. We then focus on the composite service, CongoBuy that composes these smaller programs into a program that enables a user to buy books. Pointers to all parts of the OWL-S description of the Congo service can be found on the examples page. The OWL-S Congo service description is divided into these files:
In this walk-through, we take the perspective of the typical Web service provider (Congo Inc.) and consider three automation tasks that a Web service provider might wish to enable with OWL-S version 1.2 markup:
These automation tasks are described in more detail in the OWL-S technical overview and in [McIlraith et al., 2001]. The tasks that the Web service provider wishes to automate drive what OWL-S descriptions they may wish to create.
An important distinction when describing a Web service is the difference between the description of the physical program(s) that you are making Web-accessible, and the description you use to describe the service(s) provided by those program. In what follows, we take a bottom-up approach, first providing a description of the Web-accessible programs through a process model, and grounding description, and then subsequently providing a means of advertising the properties and capabilities of that program through a profile description.
The first step in creating a
semantic Web service is to describe the program that realizes the service.
OWL-S provides for a declarative description of the programs in terms of a
process model, thus providing the necessary descriptors to automate Web
service invocation, and/or Web service composition and interoperation. If
the service provider does not wish to do this, then the may skip this
section and move direction to the section entitled "Advertising Your
Programs".
To enable automated Web service invocation, a Web service must be able to tell an external user (henceforth referred to as an agent) how to actually interact with the Web service -- how to automatically construct an (http) call to execute or invoke a Web service, and what output(s) may be returned from the service. To compose services, the process model must describe the preconditions necessary for its execution, and the effects. To enable such functionality, OWL-S provides a process ontology. The markup enables the Web service provider to include sufficient information for automating Web service invocation as well as automating Web service composition.
Congo Inc. provides the CongoBuy book buying Web service for its customers. This service is actually a collection of smaller Congo programs, each Web-accessible and composed together to form the CongoBuy program. Congo Inc. must first describe each of these individual programs, and then describe their composition, which the external world sees as the CongoBuy interactive program/service.
The CongoBuy program comprises a number of different programs including LocateBook, PutInCart, etc. It is the process model that provides a declarative description of the properties of the Web-accessible programs we wish to reason about.
The process model conceives each program as either an atomic process or as a composite process. It additionally allows for the notion of a simple process, which we will use later on to provide a simplied view of the composite CongoBuy program. In general the notion of a simple process is used to describe a view, abstraction or default instantiation of an atomic or composite service to which it expands.
<owl:Class rdf:ID="Process">
<rdfs:comment> The most general class of processes </rdfs:comment>
<rdfs:subClassOf rdf:resource="&service;#ServiceModel"/>
<owl:unionOf rdf:parseType="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 (e.g., http) call, that returns a response. It does not require an extended conversation between the calling program or agent, and the program.
<owl:Class rdf:ID="AtomicProcess"> <owl:subClassOf rdf:resource="#Process"/> </owl:Class>
An example of an atomic process is the LocateBook program that takes as
input the name of a book and returns a description of the book and its
price, if the book is in Congo's catalogue. The most direct way to proclaim
<process:AtomicProcess rdf:ID="LocateBook">
<rdfs:comment>
If the book described by "bookName" is in Congo's catalogue, then the
output of LocateBook is the ISBN of the book.
If the book is not in Congo's catalogue, then the output is a message
to this effect.
</rdfs:comment>
</process:AtomicProcess>
Associated with each process is a set of properties called
Parameters. Using a program or function metaphor, parameters are
the variables of a process. In fact, the class
Parameters have a property called parameterType that specifies the OWL class of descriptions that is suitable for values of the parameter. If a parameter has a fixed value, it is specified using the property parameterValue. Processes can be described as setting (or binding) output and local parameters as we will see below, and input parameters can receive values from the output of other processes, or by by being associated directly with portions of the content of messages sent by clients through groundings.
<owl:Class rdf:ID="Parameter">
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#parameterType" />
<owl:cardinality rdf:datatype="&xsd;#nonNegativeInteger">1</owl:cardinality>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf rdf:resource="&swrl;#Variable"/>
</owl:Class>
<owl:DatatypeProperty rdf:ID="parameterType">
<rdfs:domain rdf:resource="#Parameter"/>
<rdfs:range rdf:resource="&xsd;#anyURI"/>
</owl:DatatypeProperty>
<owl:DatatypeProperty rdf:ID="parameterValue">
<rdfs:comment>
If an Input parameter has a constant value, or (as in the case of
Output) is a description in terms of of some other process parameters,
then supply it using this property.
Note that it must be interpreted after reading it as an XMLLiteral.
</rdfs:comment>
<rdfs:domain rdf:resource="#Parameter"/>
<rdfs:range rdf:resource="&rdf;#XMLLiteral"/>
</owl:DatatypeProperty>
Parameters are associated with
processes by the property
<owl:ObjectProperty rdf:ID="hasParameter"> <rdfs:comment> Parameters are related to Processes by this property or its sub-properties. </rdfs:comment> <rdfs:domain rdf:resource="#Process"/> <rdfs:range rdf:resource="#Parameter"/> </owl:ObjectProperty>
Four classes of parameters are defined for OWL-S classes. The first two
are Input and (conditional) Output. We will touch on the
third and fourth types, Local and ResultVar later. Inputs
are the informational parameters supplied to the service by the agent
requesting the service. Outputs represent the information returned by the
service.
Using these definitions, we can describe the one input to
(Note: We will use the convention of pre-pending the name of the
process class to the names of parameters, to avoid confusion with
parameters of other processes.)
<process:AtomicProcess rdf:about="LocateBook">
<process:hasInput>
<process:Input rdf:ID="LocateBookBookName">
<process:parameterType rdf:datatype="&xsd;#anyURI">&xsd;#string</process:parameterType>
</process:Input>
</process:hasInput>
<process:hasOutput>
<process:Output rdf:ID="LocateBookOutput">
<process:parameterType rdf:datatype="&xsd;#anyURI">&THIS;#LocateBookOutputType</process:parameterType>
</process:Output>
</process:hasOutput>
</process:AtomicProcess>
XML Schema data types are used to specify the parameter types of processes when they are simple data types. In this case, the book name is a string, and the output could be any URI, though the intention is that it be an OWL description of the message that is returned to the client.
In order to enable the programs/services to be used for automated composition and interoperation, we must additionally describe the side-effects of the programs, if any exist. To do so, it is useful to use an action metaphor to conceive services. In this context we can consider services to have the properties preconditions and (conditional) effect.
Preconditions specify things that must be true of the world in order for an
agent to execute a service. Many Web services that are embodied as
programs on the Web have no preconditions except that the input parameters
are known. At the level of abstraction we are modeling Web services, there
are no physical preconditions to the execution of a piece of software on
the Web. In contrast, Web-accessible devices may have many physical
preconditions including bandwidth resources or battery power.
Preconditions are described in the process ontology as follows. Since they
are a property, like
When we ask that a service execute, we expect that something will change as a result. There are two kind of effects that we care about here: effects on the world and effects on what we know. The results of a process include both its effects on the world and its outputs, those informational items returned to the requester in a response message, that are the new things we know.
We are now ready to describe the results of a service process, specifying
the things that happen as a consequence of the service being executed.
As different outcomes can happen when a process executes, OWL-S
provides a way of describing result descriptions for multiple different
result circumstances. For example, the
<owl:Class rdf:ID="Result"> <rdfs:label>Result</rdfs:label> </owl:Class> <owl:ObjectProperty rdf:ID="hasResult"> <rdfs:label>hasResult</rdfs:label> <rdfs:domain rdf:resource="#Process"/> <rdfs:range rdf:resource="#Result"/> </owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="inCondition"> <rdfs:label>inCondition</rdfs:label> <rdfs:domain rdf:resource="#Result"/> <rdfs:range rdf:resource="&expr;#Condition"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID="hasEffect"> <rdfs:label>hasEffect</rdfs:label> <rdfs:domain rdf:resource="#Result"/> <rdfs:range rdf:resource="&expr;#Expression"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID="withOutput"> <rdfs:label>withOutput</rdfs:label> <rdfs:domain rdf:resource="#Result"/> <rdfs:range rdf:resource="#OutputBinding"/> </owl:ObjectProperty>
hasEffect is used to associate the result with a logical expression describing what will have changed when the process is completed, such as a change of ownership resulting from a purchase. withOutput is used to describe the value of the process' output parameters when that result condition occurs. It relates the result to what is called an
Before we look at the OWL XML descriptions of the
define atomic process LocateBook(
inputs: (LocateBookBookName - xsd:string),
outputs: (LocateBookOutput - LocateBookOutputType),
result: (forall (LocatedBook - profileHierarchy:Book,
BookISBN - xsd:string)
profileHierarchy:title(LocatedBook, LocateBookBookName) &
InStockBook(LocatedBook) & hasISBN(LocatedBook, BookISBN)
|->
output(LocateBookOutput <= BookISBN)
result: (profileHierarchy:title(LocateBook_aBook, LocateBookBookName) &
OutOfStockBook(LocateBook_aBook)
|->
output(LocateBookOutput <= NotifyBookOutOfStock)),
)
Here we see the same atomic process defined, with its inputs and
outputs, and two result conditions. The process' parameterType restrictions
are specified after the dash following the parameter names
The effects of the process are conjunctive expressions describing what is true after the process runs, and these expressions can include assignments of values to the process' output parameters. When the latter are indicated, look likeforall(<ResultVar> - <ResultVarType>, ...)
output(<OutputParameter> <= <expression>, ...)
In this case, since the process is representing an information service, the output variable is assigned a different kind of value for each of the two result conditions. In the successful case, it is an ISBN number, while in the other it is a token signifying that the book is out of stock.
Here is just the first of these two results in OWL XML syntax, using the
SWRL expression language to represent expressions like
<process:AtomicProcess rdf:about="LocateBook">
<process:hasResult>
<process:Result>
<rdfs:comment>
This result covers the case where the book is in stock
and the book's ISBN is output.
</rdfs:comment>
<process:hasResultVar> <!-- forall (LocatedBook - profileHierarchy:Book) -->
<process:ResultVar rdf:ID="LocatedBook">
<rdfs:comment>The book identified by the given name</rdfs:comment>
<process:parameterType rdf:datatype=&profileHierarchy;#Book">
&profileHierarchy;#Book
</process:parameterType>
</process:ResultVar>
</process:hasResultVar>
<process:hasResultVar> <!-- forall (BookISBN - xsd:string) -->
<process:ResultVar rdf:ID="BookISBN">
<rdfs:comment>The ISBN of the book identified</rdfs:comment>
<process:parameterType rdf:datatype="&xsd;#string">
&profileHierarchy;#ISBN
</process:parameterType>
</process:ResultVar>
</process:hasResultVar>
<process:inCondition>
<expr:SWRL-Condition rdf:ID="BookInStock">
<expr:expressionObject>
<swrl:AtomList> <!-- A list of conjuncts using rdf:first, rdf:rest -->
<rdf:first>
<!-- title(LocatedBook, LocateBookBookName) -->
<swrl:DatavaluedPropertyAtom>
<swrl:propertyPredicate rdf:resource="&profileHierarchy;#title"/>
<swrl:argument1 rdf:resource="#LocatedBook"/>
<swrl:argument2 rdf:resource="#LocateBookBookName"/>
</swrl:DatavaluedPropertyAtom>
</rdf:first>
<rdf:rest>
<swrl:AtomList>
<rdf:first>
<!-- InStockBook(LocatedBook) -->
<swrl:ClassAtom>
<swrl:classPredicate rdf:resource="#InStockBook"/>
<swrl:argument1 rdf:resource="#LocatedBook"/>
</swrl:ClassAtom>
</rdf:first>
<rdf:rest>
<swrl:AtomList>
<rdf:first>
<!-- hasISBN(LocatedBook, BookISBN) -->
<swrl:ClassAtom>
<swrl:classPredicate rdf:resource="&profileHierarchy;#hasISBN"/>
<swrl:argument1 rdf:resource="#LocatedBook"/>
<swrl:argument2 rdf:resource="#BookISBN"/>
</swrl:ClassAtom>
</rdf:first>
<rdf:rest rdf:resource="&rdf;#nil"/>
</swrl:AtomList>
</rdf:rest>
</swrl:AtomList>
</expr:expressionObject>
</expr:SWRL-Condition>
</process:inCondition>
<process:withOutput> <!-- output(LocateBookOutput <= BookISBN) -->
<process:Binding>
<process:toParam>
<process:Output rdf:about="#LocateBookOutput"/>
</process:toParam>
<process:valueSource>
<process:ResultVar rdf:about="#BookISBN"/>
</process:valueSource>
</process:withOutput>
</process:Result>
</process:hasResult>
</process:AtomicProcess>
OWL-S atomic process specifications are abstract, in the sense that they do not include all the details needed to invoke and interact with the given process. To make an atomic process usable, a grounding is needed, which specifies these details. Although different types of groundings are possible, the WSDL grounding is the most widely used, and the most important in terms of connecting OWL-S to mainstream Web service standards.
A WSDL grounding is essentially a mapping between an atomic process and a WSDL (1.1) service specification. In particular, this mapping associates the atomic process with an operation in WSDL, and it associates the inputs and outputs of the atomic process with message parts in WSDL.
WSDL, the Web Services Description Language, is a widely-used language for specifying messages, protocols, communications endpoints, and other conventions associated with Web services. The current release of OWL-S employs WSDL 1.1; future releases of OWL-S will ground to WSDL 2.0, which is undergoing standardization in a W3C working group.
CongoGrounding.wsdl contains the WSDL service description of our Congo service. In this section we will show how to
ground the
Before looking at this example, however, there is one important
distinction that we must touch upon, having to do with the typing
system used by the WSDL declaration. WSDL declarations normally
declare the types of message parts using XML Schema. That is, each
message part is declared to be of a primitive XML Schema type, or a
user-defined type declared in XML Schema. For example,
we see the
WSDL also allows for the use of other type specification mechanisms
besides XML Schema, by means of extension mechanisms. This makes it
possible to construct a WSDL service that reads or writes OWL as its
"native" syntax. In this case, it is not necessary to specify a type
declared in XML Schema, and the
In such a case, the WSDL code can refer to an OWL-S
document, using the attribute
Additional explanation of OWL-S groundings is available in the Technical Overview, Section 6 and in Describing Web Services using OWL-S and WSDL. in addition, the Congo and BravoAir examples, on the OWL-S 1.2 Release Examplespage, include groundings and the associated WSDL files.
With a description of each of the atomic programs/processes in hand, and all their IOPR's, we are now ready to describe compositions of these programs that provide specific services. Here we examine the CongoBuy composite service, that enables a user to buy a book.
In contrast to atomic processes, composite processes are composed of other composite or atomic processes. They are composed through the use of control constructs, currently one of:
These are used to describe the ordering of service actions and the conditional execution of processes in the composition.
The following is the definition of a composite process in the process model. As you can see, a composite process is composed of other processes.
<owl:Class rdf:ID="CompositeProcess">
<owl:intersectionOf rdf:parseType="owl:collection">
<owl:Class rdf:about="#Process"/>
<owl:Restriction owl: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>
We build the OWL-S composite process recursively in a top-down manner.
Each
In the Congo example, CongoBuy was described in terms of two main steps – locating the book, and then buying the book. While (for exposition) we assume that the locate book is an atomic process (without components), the buying of a book involves a sequence of subprocesses (other atomic or composite processes) that correspond to specifying a payment method, specifying the details of delivery (address, wrapping type, etc.) and finalizing the buy process. In this walk-through, we show how to describe a simple composition and refer the reader to the Congo encoding for the full encoding of the CongoBuy composite process.
ExpandedCongoBuy is the name we use for the sequence of the atomic process LocateBook, followed by the, as yet undefined composite process CongoBuyBook. As was the case with atomic processes, composite processes have IOPRs's (inputs, outputs, preconditions and effects) and we can likewise place restrictions on these IOPR's within our class definition.
<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>
The OWL-S description of CongoBuyBook can be found on CongoProcess.owl, or by looking on the OWL-S release examples page.
Although the CongoBuy service is actually a predetermined composition of
several of Congo's Web-accessible programs, it is useful to initially view
it as a black-box process that expands to the composite process. The value
of the black-box process is that it enables the details of the operation of
the composite process to be hidden. We specify this by
definiting a simple process called
<owl:Class rdf:ID="CongoBuy">
<rdfs:subClassOf rdf:resource="&process;#SimpleProcess"/>
</owl:Class>
<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 blackbox view. The IOPR's for the black-box process are designed to be a useful shorthand. These are generally the computed IOPR's of the associated composite process, but we do not discuss details of computed IOPR's in this release. For now, OWL-S leaves this decision up to the Web service provider.
This completes our walk-through of how to describe Congo Inc.'s programs.
OWL-S has been designed to enable automated Web service discovery by providing OWL descriptions of the properties and capabilities of a Web service, typically used to locate or select a service. These descriptors can be used to populate a registry of services, to provide better indexing and retrieval features for search engines, or they can be used as input to a match-making system (e.g., [Sycara et al., 1999]). Markup for Web service discovery is likely the simplest form of markup a service provider will wish to provide. It does not depend upon a process model being constructed, however if a process model is constructed, it should be used to populate some of the profile, in order to maintain consistency.
In this section we walk the reader through OWL-S 1.2 profile construction. We continue with our CongoBuy example. The complete OWL-S Congo profile ontology is defined in CongoProfile.owl. The OWL-S Profile ontology used as the basis for this service profile is Profile.owl.
In the rest of the example we will assume the following XML namespaces. XML entities such as "&concepts;" are also resolved using the list below.
concepts
"http://www.daml.ri.cmu.edu/ont/owl-s/concepts.daml"
congo
"http://www.daml.org/services/owl-s/1.2/Congo.daml"
country
"http://www.daml.ri.cmu.edu/ont/Country.daml"
daml
"http://www.daml.org/2001/03/OWL"
profile
"http://www.daml.org/services/owl-s/1.2/Profile"
rdf
"http://www.w3.org/1999/02/22-rdf-syntax-ns"
rdfs
"http://www.w3.org/2000/01/rdf-schema"
service
"http://www.daml.org/services/owl-s/1.2/Service"
xsd
"http://www.w3.org/2000/10/XMLSchema"
The definition of an instance of Profile can be done through the rdf:ID
that provides an ID to the instance so it can be referred to by
otherontologies.
<profile:profile rdf:ID="Profile_Congo_BookBuying_Service">
The first set of information that the service profile provides is
descriptive information about the service and information about the
provider of the service.
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>
serviceName is an identifier of the service that can be used to refer to the profile.
<profile:serviceName>Congo_BookBuying_Agent</profile:serviceName>
textDescription is a human readable description of the service
<profile:textDescription>
This agentified service provides the opportunity to browse a
book selling site and buy books there
</profile:textDescription>
contactInformation describes the provider of the service.
<profile:contactInformation>
<actor:Actor rdf:ID="CongoBuy">
<actor:name>CongoBuy</profile:name>
<actor:phone>412 268 8780 </profile:phone>
<actor:fax>412 268 5569 </profile:fax>
<actor:email>Bravo@Bravoair.com</profile:email>
<actor:physicalAddress>
somewhere 2,
OnWeb,
Montana 52321,
USA
</actor:physicalAddress>
<profile:webURL>
http://www.daml.org/services/owl-s/1.2/CongoBuy.html
</profile:webURL>
</actor:Actor >
</profile:contactInformation>
In the next section of the profile specifies additional attributes of the service. These can be
specified through two different properties: serviceCategory and serviceParameter.
<profile:has_process rdf:resource="ExpressCongoBuy"/>
ServiceCategory is used to
specify the category of a Web service with respect to a categorization
mechanism such as UNSPSC or NAICS. For example Congo can be
classified as a “book selling service”
<profile:serviceCategory>
<profile:ServiceCategory rdf:ID="NAICS-category">
<profile:value>
Airline reservation services
</profile:value>
<profile:code>
561599
</profile:code>
</profile:ServiceCategory >
</profile:serviceCategory>
ServiceParameters specify
additional features of the Web service such as quality rating.
For example in the Congo example, quality rating may be expressed as
follows.
<profile:serviceParameter>
<profile:ServiceParameter>
<profile:serviceParameterName rdf:datatype="&xsd;#string">
SomeRating
</profile:serviceParameterName>
<profile:sParameter rdf:resource="&concepts;#qualityRating_Good"/>
</profile:ServiceParameter>
</profile:serviceParameter>
The next section of the profile is a set of attributes for
describing key elements of the process that this profile is a
characterization of. The four key elements of the process model that
may want to be described are the input parameters (data to be sent to
the service), the outputs (data to be returned by the service
provider), and potentially perhaps key constraints of service usage,
such as the preconditions and conditional (side-)effects of the
service. When a process model exists, these attributes of
the service are generally derived from the process model, however when
there is no process model, they must be manually encoded by the service
providers.
Rather than defining new inputs, outputs, preconditions and results in
the profile, these can be imported directly from the Process
Model. Their role here is somewhat different, rather than
specifying the inputs, outputs, preconditions and results of a single
process, they are general of the whole service. Furthermore, only
the more salient inputs, outputs, preconditions and results of the
whole process need to be represented. The decision of what to
represent in the profile depends on a lot of issues, including the type
of discovery mechanism employed. But the goal is to maximize the
likelihood that the Web service will be appropriately selected to
perform the tasks that it needs to perform.
hasInput is a property that
allows the specification of inputs of the Profile. Its values are
the inputs of the Process Model. For example a possible input of
the Profile is the ISBN number of the book which was required by
the process ExpressCongoBuy. The use of such an input is shown
in the following line.
<profile:hasInput rdf:resource="&congoProcess;#ExpressCongoBuyBookISBN"/>
hasOutput is the equivalent
to hasInput on the Output side. It can be used to express what
kind of outputs will be produced by the service. For example, the
following line refers to the output of ExpressCongoBuy.
<profile:hasOutput rdf:resource="&congoProcess;#ExpressCongoBuyOutput"/>
hasPrecondition also refers
to one of the preconditions of the Process model. For example, a
precondition to the correct use of the service is that the client has
an account with the service.
<profile:hasPrecondition rdf:resource="&congoProcess;#ExpressCongoBuyAcctExists"/>
hasResult complete the functional representation by reporting a typical result of the service.
<profile:hasResult rdf:resource="&congoProcess;#ExpressCongoBuyPositiveResult"/>In the previous lines we provided a definition of the Profile in which functional properties refer directly to the Process Model. This is the simplest, and safiest, way to define the functional properties of the Profile. An alternative way is to define the property directly in the Profile with no relation to the Process Model. For example, even though ExpressCongoBuy does not require inputs of type book, such an input can be defined in the Profile of the service, as shown by the following lines.
<profile:hasInput>
<process:hasInput>
<process:Input>
<process:parameterType rdf:datatype="&xsd;#anyURI">
&BookOntology;#Book
</process:parameterType>
</process:Input>
</process:hasInput>>
</profile:hasInput
This type of references increase the expressive power of the Profile allowing the modeler to express the function of provided by the service independently of the model of the actual inputs and outputs that the service exchanges or of the preconditions and effects that apply to any of the services. Despite its power, this type of modeling needs to be donewith extreme care since it may easily lead to a description of capabilities that are not reflected in the service itself.
Comment: BEGIN OF EDITABLE SECTION
input refers to inputs to the process model. Each input requires a name and a restriction to what information is requested and a reference to the process model input used. There are no encoded logical constraints between the inputs in the process model and the inputs in the profile model, therefore, at least in theory, the two sets may be totally unrelated. Nevertheless, the IOPR's of the profile should be consistent with the IOPR's of the process model, since discovery of a service often leads to its execution.
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 what the provider needs. The requester uses the inputs to know what additional information it needs to provide to the service to have a successful run.
<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. As with the 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 structure similar to the structure of inputs and outputs. The main difference is that instead of a restriction to some class they have a statement which are defined as owl:Thing. Preconditions and effects are used by the registry in a way that is similar to the inputs and outputs. Furthermore, the requester uses preconditions to make sure that indeed it can run the service; while it uses effects to know what will result after the interaction with the service completes.
<precondition>Finally, close the description of the service.
<profile:ConditionDescription>
<profile:ConditionName rdf:resource="AcctExists"/>
<profile:statement rdf:resource="&congoProcess;#AcctExists"/>
<profile:refersTo
rdf:resource="&congo;#congoBuyAcctExistsPrecondition"/>
</profile:ParameterDescription>
</precondition>
</profile:OfferedService>
Do we have any acknowledgments that are specific for this document?
Do we have any references or footnotes? If so, we can copy the formatting from Overview.html.