As explained in the Technical Overview and elsewhere, a service profile is used to characterize a service for purposes such as advertisement, discovery, and selection. Service profiles may be published in various kinds of registries, discovered using various tools, and selected using various kinds of matchmaking techniques. DAML-S does not prescribe or limit the ways in which profiles may be used, but rather, seeks to provide a basis for their construction that is flexible enough to accommodate many different contexts and methods of use.
In general, this kind of service characterization must effectively position a service within the broad array of services that exists within some domain, or perhaps in the world at large. One very natural technique for this kind of positioning is the construction of a class hierarchy, with inheritance of properties by subclasses. This fundamental technique, which is a familiar part of object-oriented design and programming, is also well supported by DAML+OIL and other description logic-based markup languages. This technique, when used to construct a hierarchy of subclasses of the Profile class, provides a useful means of constructing a "yellow pages" style of service categorization, but with more formal structure than is typically used in yellow pages, and thus supporting more powerful forms of query.
In ProfileHierarchy.daml, we give an extremely simple example of this kind of class hierarchy. We emphasize that this is an extremely limited example, intended only to provide Profile subclasses under which the Congo and BravoAir examples can be categorized, and to illustrate inheritance of properties and multiple inheritance. ProfileHierarchy.daml is not meant to provide canonical Profile classes for use on the Web, but is meant merely to illustrate technical features of this approach.
Ultimately, the Semantic Web will likely support a number of different Profile-based hierarchies, and those that are most widely used will be selected by market forces. Existing taxonomies of service categories, such as NAICS and UNSPSC, are likely to evolve into class-hierarchical categorization schemes, with inherited properties, using the approach illustrated here.
In addition to a class hierarchy of service profiles, we anticipate many other class hierarchical categorization schemes will be used in connection with DAML-S service profiles; for instance, hierarchies of products, geographical regions, media, or various other categories related to different types of services. Typically, various properties of a Profile instance will be given values taken from these other hierarchies. For example, a B2C site may characterize its product offerings using terms (classes or instances) from a product hierarchy, and its delivery region using terms from a geographical hierarchy. Strictly speaking, these auxiliary class hierarchies are outside the scope of DAML-S, but will normally be specified using DAML+OIL, and thus will automatically be compatible with a DAML-S specification. We do not specify any such class hierarchies here, except for a tiny fragment of a product hierarchy, used in conjunction with the Congo example.
Although the Profile-based class hierarchical approach, as illustrated here, is an advantageous and promising way of using the Profile, it is not the only useful approach, and DAML-S does not mandate that all every Profile should be classified on the basis of a hierarchy of classes. Indeed, it is possible to specify the profile of a service directly as instances of the class Profile, avoiding the use of hierarchical classfication all together. The latter approach is appropriate when a service cannot be appropriately classified by any ontological scheme, or when a hierarchical classification would entail inappropriate inferences that the author of the profile would rather avoid. Ultimately, the hierarchical classification of profiles provides an additional tool to describe more precisely the service and its functionalities. It is up to service providers who create the profiles to decide whether to take advantage of it and how.