<?xml version='1.0' encoding='ISO-8859-1'?> 
<!DOCTYPE uridef[
  <!ENTITY rdf "http://www.w3.org/1999/02/22-rdf-syntax-ns">
  <!ENTITY rdfs "http://www.w3.org/2000/01/rdf-schema">
  <!ENTITY daml "http://www.daml.org/2001/03/daml+oil">
  <!ENTITY service "http://www.daml.org/services/daml-s/2001/05/Service.daml">
  <!ENTITY DEFAULT "http://www.daml.org/services/daml-s/2001/05/Service.daml">
  <!ENTITY THIS "http://www.daml.org/services/daml-s/2001/05/Service.daml">
]>

<!--
  This document uses entity types as a shorthand for URIs.
  Download the source for a version with unexpanded entities.
  -->
<rdf:RDF 
  xmlns:rdf =  "&rdf;#"
  xmlns:rdfs = "&rdfs;#"
  xmlns:daml = "&daml;#"
  xmlns =      "&service;#">

  <daml:Ontology rdf:about="">
    <daml:versionInfo>
      $Id: Service.daml,v 1.3 2001/06/14 15:46:23 kmbarber Exp $
    </daml:versionInfo>
    <rdfs:comment>
      SRI's upper-level DAML ontology for services; first cut; incomplete.
      Augmented by Terry Payne, CMU.
    </rdfs:comment>
  </daml:Ontology>


  <!-- =================================================================
		  DAML SERVICES

  Class Service stands at the top of a hierarchy of services.  It
  "presents" a ServiceProfile, is "describedBy" a ServiceModel, and
  "supports" a ServiceGrounding.  Each descendant class of Service is
  expected to present a descendant class of ServiceProfile, be describedBy a
  descendant class of ServiceModel, and support a descendant class of
  ServiceGrounding.  The nature of profiles, models, and groundings may
  vary widely from one type of service (that is, one descendant class of
  Service) to another.

  The service profile tells "what the service does"; that is, it gives
  the type of information needed by a service-seeking agent to determine
  whether the service meets its needs (typically such things as input
  and output types, preconditions and postconditions, and binding
  patterns).  Logic rules can be used in such a specification (for
  instance, a rule might say that if a particular input argument is
  bound in a certain way, certain other input arguments may not be
  needed, or may be provided by the service itself). 

  The service model tells "how the service works"; that is, it describes
  what happens when the service is carried out.  For non-trivial
  services (those composed of several steps over time), this description
  may be used by a service-seeking agent (at least) in four different
  ways: (1) to perform a more in-depth analysis of whether the service
  meets its needs; (2) to compose service descriptions from multiple
  services to perform a specific task; (3) during the course of the
  service enactment, to coordinate the activities of the different
  participants; (4) to monitor the execution of the service.  For
  non-trivial services, the first two tasks require a model of action and
  processes, the last two involve, in addition, an execution model.

  Note: For extremely simple, one-step services, the model may be no
  different than the service profile.  For this reason, the "describedBy"
  property is optional.

  A service grounding (grounding for short) object specifies the details
  of how an agent can access a service.  Typically a grounding may
  specify some well know communications protocol (e.g., RPC, HTTP-FORM,
  CORBA IDL, SOAP, Java remote calls, OAA, Jini), and service-specific
  details such as port numbers used in contacting the service.  In
  addition, the grounding must specify, for each abstract type specified
  in the ServiceModel, an unambigous way of exchanging data elements of
  that type with the service (that is, marshalling / serialization
  techniques employed).  The likelihood is that a relatively small set of
  groundings will come to be widely used in conjunction with DAML
  services.  Groundings will be declared and documented in detail at
  various well-known URIs.

  Taken together, the ServiceModel and ServiceGrounding object
  associated with a Service will give enough information for an agent to
  make use of a newly discovered service.

  ======================================================================
  -->

  <!-- Services -->

  <rdfs:Class rdf:ID="Service">
    <rdfs:label>Service</rdfs:label>
    <rdfs:comment>Top Level Service</rdfs:comment>
  </rdfs:Class>


  <!-- Service Profile -->

  <rdfs:Class ID="ServiceProfile">
    <rdfs:label>ServiceProfile</rdfs:label>
    <rdfs:comment>See comments above</rdfs:comment>
  </rdfs:Class>

  <!-- Service Model -->

  <rdfs:Class rdf:ID="ServiceModel">
    <rdfs:label>ServiceModel</rdfs:label>
    <rdfs:comment>See comments above</rdfs:comment>
  </rdfs:Class>

  <!-- Service Grounding -->

  <rdfs:Class rdf:ID="ServiceGrounding">
    <rdfs:label>ServiceGrounding</rdfs:label>
    <rdfs:comment>See comments above</rdfs:comment>
  </rdfs:Class>

  <!-- presenting a profile -->

  <rdf:Property rdf:ID="presents">
    <rdfs:domain rdf:resource="&service;#Service"/>
    <rdfs:range rdf:resource="&service;#ServiceProfile"/>
    <daml:cardinality>1</daml:cardinality>
  </rdf:Property>

  <rdf:Property rdf:ID="isPresentedBy">
    <rdfs:domain rdf:resource="&service;#ServiceProfile"/>
    <rdfs:range rdf:resource="&service;#Service"/>
    <daml:inverseOf rdf:resource="&service;#presents"/>
    <daml:cardinality>1</daml:cardinality>
  </rdf:Property>

  <!-- being described by a model -->

  <rdf:Property rdf:ID="describedBy">
    <rdfs:domain rdf:resource="&service;#Service"/>
    <rdfs:range rdf:resource="&service;#ServiceModel"/>
    <rdfs:comment>No cardinality restriction; some services will not
      need a service model.</rdfs:comment>
  </rdf:Property>

  <rdf:Property rdf:ID="describes">
    <rdfs:domain rdf:resource="&service;#ServiceModel"/>
    <rdfs:range rdf:resource="&service;#Service"/>
    <daml:inverseOf rdf:resource="&service;#describedBy"/>
    <rdfs:comment>No cardinality restriction; some services will not
      need a service model.</rdfs:comment>
  </rdf:Property>

  <!-- supporting a grounding -->

  <rdf:Property rdf:ID="supports">
    <rdfs:domain rdf:resource="&service;#Service"/>
    <rdfs:range rdf:resource="&service;#ServiceGrounding"/>
    <rdfs:comment>a service can be offered via any number of groundings.</rdfs:comment>
    <daml:minCardinality>1</daml:minCardinality>
  </rdf:Property>

  <rdf:Property rdf:ID="isSupportedBy">
    <rdfs:domain rdf:resource="&service;#ServiceGrounding"/>
    <rdfs:range rdf:resource="&service;#Service"/>
    <daml:inverseOf rdf:resource="&service;#supports"/>
    <rdfs:comment>one or more groundings support a service.</rdfs:comment>
    <daml:minCardinality>1</daml:minCardinality>
  </rdf:Property>

  <!-- providing a service -->

  <rdf:Property rdf:ID="provides">
    <rdfs:comment>A Resource provides a service, such as a WebSite.</rdfs:comment>
    <rdfs:domain rdf:resource="&rdfs;#Resource"/>
    <rdfs:range rdf:resource="&service;#Service"/>
  </rdf:Property>

  <rdf:Property rdf:ID="isProvidedBy">
    <rdfs:comment>A service is provided by a Resource, such as a WebSite.</rdfs:comment>
    <rdfs:domain rdf:resource="&service;#Service"/>
    <rdfs:range rdf:resource="&rdfs;#Resource"/>
    <daml:inverseOf rdf:resource="&service;#provides"/>
  </rdf:Property>

</rdf:RDF>






