DAML-SWeb Service Description for the Semantic Web

Document Sample
DAML-SWeb Service Description for the Semantic Web Powered By Docstoc
					DAML-S: Semantic Markup for Web


 Introduction
 An Upper Service Ontology overivew
  - Service Profile;
  - Service Model;
  - Sevice Grounding;
 Reasoning support
 Example
 Conclusions

         What is DAML-S?

DAML-S is a DAML+OIL ontology of Web Services which
  goal is to represent Web programs and devices in a
  computer-interpretable manner.

Why DAML+OIL for Web Services

 Rich declarative service representation
  UDDI: no capability description, limited to the name, a
  pointer and other link information
 The well-described semantic model
  Lack in WSDL
 Proved and implemented reasoning support

An Upper Ontology for Services

DAML-S defines a set of classes and properties, specific to
   the description of services.
The top of the DAML-S ontology is very general, i.e. it
   doesn’t specify any particular subclasses of the root or
   even the conceptual basis for structuring the taxonomy.
It is expected that the taxonomy will be structured
   according to functional and domain differences and
   market needs.

An Upper Ontology for Services

The class Service is the root of the DAML-S ontology.
It is characterized by three important properties:
1. A high-level description of a service and its provider.
   The class Service presents a ServiceProfile
2. A detalized description of the contol- and dataflow of
   the service.
   The class Service is describedBy a ServiceModel
3. A mapping from the (abstract) content of the service to
   some specific transmittable format(s).
   The class Service supports a ServiceGrounding

An Upper Ontology for Services

Figure 1.                                                    What it does

  Resource                                                   ServiceProfile

              provides                           presents


                       supports             describedby
   ServiceGrounding                                       ServiceModel

    How to access it                                        How it works
Service Profile

The class Service presents a ServiceProfile for
   describing the capabilities and parameters of the
It answers the question:
“What does the service require of agents, and provide for
Informally, it specifies “what the service does” and is
   used by an agent to determine if the service meets its
   rough needs and satisfies constraints (security, locality,
   quality requirenments etc.).

Service Profile

Service profiles consist of three types of information:
 a description of the service and the service provider
 the functional behavior of the service
 several functional attributes (for automatic service
Implicitly, service profiles specify the intended purpose of
  the service, because they specify only those functional
  behaviors that are publicly provided.

Service Profile
                               Description Properties
serviceName         The name of the service
intendedPurpose     A high-level description of what constitutes (typical) successful
textDescription     A brief, human readable description of the service, summarizing what the service
                    offers or what capabilities are being requested.
role                An abstract link to Actors involved in the service execution.
requestedBy         A sub-property of role referring to the service requester.
providedBy          A sub-property of role referring to the service provider
                                Functional Attributes
geographicRadius    Geographic scope of the service, either at the global scale (e.g. e-commerce) or at a
                    regional scale (e.g. pizza delivery).
degreeOfQuality     Quality qualifications, such as providing the cheapest or fastest possible service.
serviceParameter    An expandable list of properties that characterize the execution of a service, such as
                    averageResponseTime or invocationCost.
communicationThru   High-level summary of how a service may communicate, e.g. what communication
                    language is used (e.g., KQML, SOAP).
serviceType         Broad classification of the service that might be described by an ontology of service
                    types, such as B2B, B2C etc.
serviceCategory     Categories defined within some service category ontology. Such categories may
                    include Products, Information Services etc.
qualityGuarantees   Guarantees that the service promises to deliver, e.g. guaranteeing to provide a
                    response within 3 minute s, etc.
qualityRating       Industry-based ratings, such as the “Dun and Bradstreet Rating” for businesses.
Service Model

The class Service is describedBy a ServiceModel, that
   specifies the workflow and possible execution paths of
   the service.
It answers the question: “How does it work?”
It is used by an agent to:
 perform more in-depth analysis of whether the service
   meets the agent’s needs;
 compose service descriptions from multiple services to
   perform a specific task;
 coordinate the activities of different agents;

Process Model

Web Services can be represented as processes, which
  details both the control structure and data flow structure
  of the services, i.e. the possible steps that are necessary
  to execute a service.
The ProcessModel extends the ServiceModel and is
  used to describe services as processes.
The Process Ontology consists of subclasses and properties
  of the ProcessModel class.

The Process Ontology

The basic class of the Process Ontology is the Process.
Its sublcasses describe each process by:
 any number of (possibly, conditional) inputs;
 any number of (possibly, conditional) outputs;
 any number of preconditions, which must hold in order
   for the process to be invoked;
 any number of (possibly, conditional) side effects;
 any number of participants (subprocess);

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 composedOf property, by which the control
  structure of the process is indicated, using a
  ControlConstruct 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).

Control Constructs of Processes
 Construct      Description
  Sequence      Execute a list of processes in a sequential order
  Concurrent    Execute elements of a bag of processes concurrently
     Split      Invoke elements of a bag of processes

  Split+Join    Invoke elements of a bag of processes and synchronize

  Unordered     Execute all processes in a bag in any order
    Choice      Choose between alternatives and execute one
 If-then-else   If specified condition hold, execute “Then”, else execute “Else”.
 Repeat-Until   Iterate execution of a bag of processes until a condition holds
 Repeat-While   Iterate execution of a bag of processes while a condition holds

Service Grounding

The class Service supports a ServiceGrounding, that
  describes a mapping from an abstract (ServiceProfile
  and ServiceModel) 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
  how 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

Reasoning in DAML-S
 Service requests are constructed as partial service
 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


To illustrate the main concepts, an example of a fictious
   book-buying service, provided by Congo Inc., has been
This service is, in fact, a collection of smaller programs,
   some of which are used in this presentation.
The whole example can be found at:

 Example: an atomic process
The LocateBook 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=”LocateBook”>
 <rdfs:subClassOf rdf:resouce=”http://www.daml.org/services/daml-
   s/2001/10/Process.daml#AtomicProcess” />
   <daml:Restriction daml:cardinality=”1”>
    <daml:onProperty rdf:resource=”#bookName”/>

<rdf:Property rdf:ID=”bookName”>
 <rdfs:subPropertyOf rdf:resource=”http://www.daml.org/services/daml-
   s/2001/10/Process.daml#input” />
 <rdfs:domain rdf:resource=”#LocateBook”/>
 <rdfs:range rdf:resource=”http://www.w3.org/2000/10/XMLSchema#string"/>
</rdf:Property>                                                            19
  Example: an atomic process
<rdf:Property rdf:ID=”bookDescription”>
 <rdfs:subPropertyOf rdf:resource=”http://www.daml.org/services/daml-
   s/2001/10/Process.daml#conditionalOutput” />
 <rdfs:domain rdf:resource=”#LocateBook”/>
 <rdfs:range rdf:resource=”InCatalogueBookDescription”/>

<daml:Class rdf:ID=”InCatalogueBookDescription”>
 <rdfs:subClassOf rdf:resouce=”http://www.daml.org/services/daml-
   s/2001/10/Process.daml#ConditionalOutput” />

Example: an atomic process
<rdf:Property rdf:ID=”condInCatalogueBookDescription”>
 <rdfs:subPropertyOf rdf:resource=”http://www.daml.org/services/daml-
   s/2001/10/Process.daml#coCondition” />
 <rdfs:domain rdf:resource=”#InCatalogueBookDescription”/>
 <rdfs:range rdf:resource=”#InCatalogueBook”/>

<rdf:Property rdf:ID=”outInCatalogueBookDescription”>
 <rdfs:subPropertyOf rdf:resource=”http://www.daml.org/services/daml-
   s/2001/10/Process.daml#coOutput” />
 <rdfs:domain rdf:resource=”#InCatalogueBookDescription”/>
 <rdfs:range rdf:resource=”#TextBookDescription”/>

<daml:Class rdf:ID=”TextBookDescription”>
 <rdfs:subClassOf rdf:resource=” http://www.daml.org/2001/03/daml+oil#Thing” />

Example: a composite process

With a description of each of the atomic
  programs/processes in hand, it possible then to describe
  compositions of these programs that provide specific
The DAML-S composite process is built recursively in a top-
  down manner. Each CompositeProcess is composedOf a
  ControlStructure, which may be a Sequence, If-then-
  else, etc. Each such ControlConstruct, in turn, has a
  ”components” property, which specify the classes of the

Example: a composite process

In the Congo example, CongoBuy was described in terms
   of two main steps – locating the book, and then buying
ExpandedCongoBy is the name for the sequence of the
   atomic process LocateBook, followed by the composite
   process CongoBuyBook.
Other restrictions (on inputs, outputs, preconditions and
   effects) can also be specified.

Example: a composite process
<daml:Class rdf:ID=”ExpandedCongoBuy”>
 <rdfs:subClassOf rdf:resouce=”http://www.daml.org/services/daml-
    s/2001/10/Process.daml#CompositeProcess” />
      <daml:onProperty rdf:resource=”http://www.daml.org/services/daml-
    s/2001/10/Process.daml#composedOf “/>
      <daml:intersectionOf rdf:parseType=”daml:collection”>
       <daml:Class rdf:about=”process:Sequence”/>
       <daml:onProperty rdf:resource=” process:components”/>
        <daml:listOfInstanceOf rdf:parseType=”daml:collection”>
           <daml:Class rdf:about=”#LocateBook/”>
           <daml:Class rdf:about=”#CongoBuyBook/”>
         </daml:listOfInstanceOf rdf:parseType=”daml:collection”>
 </rdfs:subClassOf>                                                       24
Example: a simple process

<daml:Class rdf:ID=” CongoBuy”>
  <rdfs:subClassOf rdf:resouce=&process;#SimpleProcess” />

<daml:Class rdf:about=”#CongoBuy”>
      <daml:onProperty rdf:resource=”&process;#expand”/>
      <daml:toClass rdf:resource =”#ExpandedCongoBuy”/>


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.


Shared By: