Services are effected by processes and processes generally require resources. Therefore, an ontology of resources is an important component of an ontology of services. Our aim in this write-up is to propose an ontology of resources stated at an abstract enough level to cover physical, temporal, computational and other sorts of resources. Specific kinds of resources will of course have specific properties; in this development we sketch out the principal classes of properties a resource might have. At the end we have appended a version of the portions of the ontology that can currently be encoded in DAML+OIL. As DAML develops, particularly in the area of expressing rules, the various constraints on concepts in the ontology will be written up in DAML as well.

First of all, a distinction must be pointed out. There are resource types, such as fuel. There are resource tokens, such as the fuel in the gas tank of a particular car. And there is the quantity, or capacity, of the resource token at any given instant, such as the five gallons of fuel in the car's tank right now. We are primarily interested in the second of these notions. Resources in this sense can, depending on resource type, be consumed, replenished, locked, and released. A resource token, or simply resource, is what is available to an activity.

Resources are allocated to activities or processes. A principal distinction in types of resources concerns their status after the activity stops using them. We will call this the resource's AllocationType. If a resource is gone after it is used, its AllocationType is ConsumableAllocation. If not, its AllocationType is ReusableAllocation.

Examples of reusable resources are the use of a device, the availability of an agent, the use of a region of space, and the use of bandwidth. (These could be viewed as consumable uses of the cross product of the resource (e.g., space) with time, but they are easily decomposed into the resource and time, where only time is consumed.) A persistent resource can be locked and released. When it is locked, it cannot be used by another agent.

Examples of consumable resources are food, charge in a battery, fuel, money, and time. Consumable resources can sometimes be replenished after they are consumed. A deadline is an indirect constraint on the consumable resource of time.

Many resources, such as food, are perishable. We can view this case as having two processes operating on the resource -- one functional and relatively rapid, one dysfunctional and relatively slow. Thus, eating food is functional, food spoiling is dysfunctional, and eating is rapid relative to spoiling.

Preconditions on processes can often be viewed as the availability of some resource. Many processes have a location precondition, or more generally, an access precondition. Permission would be an example. In general, if a process is executed as a precondition to another process, we can view its product (or its having been done) as a resource. Something being in the right location for a process's execution can thus be seen as a resource.

Resources generally have a precise quantitative measure of capacity at any given instant of time. (Enthusiasm is an interesting limiting case -- it is a consumable resource that can be replenished and is required for many tasks, but it cannot be measured precisely. Attention is a similar resource.)

The quantitative measure might be continuous, such as the quantity of fuel. Or it could be a discrete measure, such as a number of chairs occupied. Thus, a resource has a CapacityType, where the two CapacityTypes are DiscreteCapacity and ContinuousCapacity.

Capacity can be related to various other resource-theoretic predicates. In the following rules, for future incorporation into the DAML ontology, R stands for a resource, A for an activity, T for a time interval, and t for a time instant. The expression use(A,R,T/t) means that activity A uses resource R over time interval T or for time instant t. The expression capacity(R,T/t) refers to the capacity of resource R over time interval T or for time instant t.

The capacity of a persistent resource at the beginning of its use is the same as at the end.
reusable(R) & use(A,R,T) ==> capacity(R,start(T)) = capacity(R,end(T))

The quantity of a consumable resource at the beginning of its use is more than at the end.
consumable(R) & use(A,R,T) ==> capacity(R,start(T)) > capacity(R,end(T))

When an agent replenishes a resource during period T, there is more after the replenishment.
replenish(A,R,T) ==> capacity(R,start(T)) < capacity(R,end(T))

When an reusable resource is used for period T, it is locked at the beginning of T and released at the end.
reusable(R) & use(A,R,T) ==> lock(A,R,start(T)) & release(A,R,end(T))

Capacities of resources can also have a capacityGranularity, that is, the units in terms of which the capacity is measured.

A resource can be atomic, or it can be an aggregate. Thus, AtomicResource and AggregateResource are subclasses of Resource.

Some atomic resources can be shared by different activities, while others cannot. For example, several activities may need a table but can in fact use the same table. We thus distinguish between unit capacity atomic resources, whose availability to an activity is a yes-no question, and batch capacity atomic resources, which can support multiple activities in a synchronized fashion. UnitCapacityResource and BatchCapacityResource are subclasses of AtomicResource.

Aggregates can be conjunctive or disjunctive. For conjunctive aggregates, all the elements must be allocated to the activity. For a disjunctive aggregate a subset of the elements in the aggregate can be allocated. An example of a disjunctive resource is a process that requires any 3 adjacent chairs of 100 chairs in a room. Thus, ConjunctiveAggregateResource and DisjunctiveAggregateResource are subclasses of AggregateResource.

Shareable resources should be understood in terms of batch capacity resources and aggregation.

A very important use of an ontology of resources could be in a monotonic version of "negation as failure" in DAML-L. In this view, "not P" would not be negation as failure. Rather one would use the predicate "cantfind(P,R)" where R is some indication of the resources to devote to the search for a proof of P. R could then be a list or description of web resources, a certain number of inference steps, or a certain amount of time, for example.

<?xml version="1.0"?>

<!--
      This is an initial definition of an ontology for resources, for the
      purposes of DAML-S. The schemata here are written in a way that allows
      this file reside anywhere (i.e., it does not have to be fetched from its
      "real" URI).

      Author: Ora Lassila

      Copyright 2001 Nokia Research Center.
      All Rights Reserved.

      Subject to the Nokia Open Source (NOKOS) license:
        http://www.opensource.org/licenses/nokia.html
-->


<!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 r    "http://www.daml.org/services/schemata/resources#">
]>

<rdf:RDF xmlns:rdf="&rdf;"
         xmlns:rdfs="&rdfs;"
         xmlns:daml="&daml;"
         xmlns:r="&r;">

<daml:Ontology rdf:about="&r;">
  <daml:versionInfo>no version number yet...</daml:versionInfo>
  <rdfs:comment>Resource Ontology for DAML-S</rdfs:comment>
  <daml:imports rdf:resource="http://www.daml.org/2001/03/daml+oil"/>
</daml:Ontology>


<!--
        BASE CLASS FOR ALL RESOURCES
        
        Resources have "capacity", but this notion can also be used to
        represent various kinds of variables (which could act as pre-
        conditions for allocation): location, access rights, etc.
-->

<daml:Class rdf:about="&r;Resource"
   rdfs:label="Resource"/>

<daml:ObjectProperty rdf:about="&r;allocationType"
   rdfs:label="allocation type">
  <rdfs:domain rdf:resource="&r;Resource"/>
  <rdfs:range rdf:resource="&r;AllocationType"/>
</daml:ObjectProperty>

<daml:ObjectProperty rdf:about="&r;capacityType"
   rdfs:label="capacity type">
  <rdfs:domain rdf:resource="&r;Resource"/>
  <rdfs:range rdf:resource="&r;CapacityType"/>
</daml:ObjectProperty>

<rdf:Property rdf:about="&r;capacityGranularity"
   rdfs:label="capacity granularity">
  <rdfs:domain rdf:resource="&r;Resource"/>
</rdf:Property>


<!--
        ALLOCATION TYPES
        
        Address essentially what happens after the resource is released:
        
          consumable    (gone after it is allocated)
          reusable      (available after released)
-->

<daml:Class rdf:about="&r;AllocationType"
   rdfs:label="Allocation Type"/>

<r:AllocationType rdf:about="&r;ConsumableAllocation"/>
<r:AllocationType rdf:about="&r;ReusableAllocation"/>


<!--
        CAPACITY TYPES
        
        Address "measures" of allocation:
        
          discrete      (resource has notion of granularity)
          continuous    (allocate any amount)
-->

<daml:Class rdf:about="&r;CapacityType"
   rdfs:label="Capacity Type"/>

<r:CapacityType rdf:about="&r;DiscreteCapacity"/>
<r:CapacityType rdf:about="&r;ContinuousCapacity"/>


<!--
        RESOURCE SUBCLASSES
        
        These mostly address issues of resource composition:

          atomic
            unit-capacity       (on/off)
            batch-capacity      (multiple activities, time-synchronized, can allocate)
          aggregate             (has "sub-resources")
            conjunctive         (must allocate all)
            disjunctive         (can allocate a subset)
-->

<daml:Class rdf:about="&r;AtomicResource"
   rdfs:label="Atomic Resource">
  <rdfs:subClassOf rdf:resource="&r;Resource"/>
</daml:Class>

<daml:Class rdf:about="&r;UnitCapacityResource"
   rdfs:label="Unit-capacity Resource">
  <rdfs:subClassOf rdf:resource="&r;AtomicResource"/>
</daml:Class>

<daml:Class rdf:about="&r;BatchCapacityResource"
   rdfs:label="Batch-capacity Resource">
  <rdfs:subClassOf rdf:resource="&r;AtomicResource"/>
</daml:Class>

<daml:Class rdf:about="&r;AggregateResource"
   rdfs:label="Aggregate Resource">
  <rdfs:subClassOf rdf:resource="&r;Resource"/>
</daml:Class>

<daml:Class rdf:about="&r;ConjunctiveAggregateResource"
   rdfs:label="Conjunctive Aggregate Resource">
  <rdfs:subClassOf rdf:resource="&r;AggregateResource"/>
</daml:Class>

<daml:Class rdf:about="&r;DisjunctiveAggregateResource"
   rdfs:label="Disjunctive Aggregate Resource">
  <rdfs:subClassOf rdf:resource="&r;AggregateResource"/>
</daml:Class>


</rdf:RDF>