DAML-S: use of the Service class

I promised (on last week's telecon) to send a summary of why we should
keep the Service class, as distinct from Profile and Process.  This
doesn't seem to be a controversial point, so perhaps we don't need to
spend any more time on it.   But I'll post this "for the record".

My belief is that we need to make several adjustments to the
relationships between Service and the other fundamental classes (along
the lines that we've discussed at various times), but not to eliminate
the Service class.   Note that I no longer envision any subclassing of
Service (as I did initially). But I envision instances of Service
playing an essential bookkeeping/grouping role; that is, they serve as
the central point of reference for a service, and they tie together
the other ontology elements for the service. Some reasons for wanting
to retain Service are:

(1) Intuitively, it seems that there ought to be *some* class of
objects that one can call "the service"
(2) I don't feel comfortable with calling either the Profile or the
Process "the service" (and I think there are good reasons for not
doing so; in particular (5) below)
(3) Our basic "structuring language" still feels right (a service
"presents" a profile, a service "is described by" a process, etc.).
I'm not saying these are the perfect word choices, but that the
underlying concepts still seem right -- and again, the way we tend to
talk about services seems to call for some object that *isn't* the
profile or the process.
(4) The service class, even though it won't be used for a taxonomy of
services as originally envisioned, can still be useful as an
organizational (grouping) device.  For example, it provides a place to
list all of the profiles of a service, and it may in the future
provide a place to hang other kinds of information about the service,
which we don't feel particularly belongs in either the profile or the
process.
(5) Given the flexibility that we want with respect to how many
Profiles there may be for a service, and with respect to making the
Process optional, the Service object provides the only point of
reference for which one can assume the existence of one (and exactly
one) of them, for any given Web service.

Here's a simple illustration: suppose that a service has several
different profiles associated with it; for instance, it may be a book
retailer that has one Profile that's an instance of the Better
Business Bureau's OnlineRetailProfile class, another profile that's an
instance of the American Interfaith Association's
ReligiousBooksellerProfile class, and a third profile that's an
instance of Yahoo's RetailStorefrontProfile class.  (I'm imagining
that each of these three organizations maintains its own profile-based
taxonomy of services.) Now suppose you want to tell some software
agent developer to take a look at this service.  You don't want to
give her a pointer to any specific profile; rather, you want her to
look at the service as a whole.  So you give a URI for the Service
object.  Similarly, if you are making a site index for some large
corporation's WebSite, and you want to list all the services, with one
list element per Service, it would be useful to point to the Service
object, rather than any given Profile for the service.

This doesn't change the crucial role of profiles. In searching and
matchmaking situations, one or more of the service's Profiles will be
the important objects used by the search engine or matchmaker.  I'm
just suggesting that there's use for the Service object in certain
other situations.

- David

David Martin
SRI International

Received on Thursday, 23 May 2002 14:31:02 UTC