DAML-S has been designed to support discovery of Web services based on their capabilities. Broadly speaking, services can play either one of three roles: providers, requesters and registries. Service providers offer their capabilities to the rest of the service community; service requesters look for services to whom to subcontract a task; finally, web service registries record the capabilities offered by the providers at a given time\footnote{As discussed in the Technical Overview, other forms of registries are also possible and DAML-S can be used in any of them. In the rest of the example we will assume a registry that records offers of service and responds to requests of service.} and responds to requests of service. In this walkthrough, we will discuss how to compile the profile of Congo Inc so that its functionalities can be advertised to a web service registry. In the rest of the example we will assume the following XML namespaces. XML entities such as "&concepts;" are also resolved using the list below. concepts "http://www.daml.ri.cmu.edu/ont/DAML-S/concepts.daml" congo "http://www.daml.org/services/daml-s/2001/10/Congo.daml" country "http://www.daml.ri.cmu.edu/ont/Country.daml" daml "http://www.daml.org/2001/03/daml+oil" profile "http://www.daml.org/services/daml-s/2001/10/Profile" rdf "http://www.w3.org/1999/02/22-rdf-syntax-ns" rdfs "http://www.w3.org/2000/01/rdf-schema" service "http://www.daml.org/services/daml-s/2001/10/Service" xsd "http://www.w3.org/2000/10/XMLSchema" A profile is an instance of the class Profile defined in http://www.daml.org/services/daml-s/2001/10/Profile. rdf:ID provides an ID to the instance so it can be referred to by other ontologies. The first set of information that the service profile provides is descriptive information about the service and information about the provider of the service. {\em isPresentedBy} relates the profile to the service it describes, in this case Congo_BookBuying_Service. {\em serviceName} is an identifier of the service that can be used to refer to the profile. Congo_BookBuying_Agent {\em textDescription} is a human readable description of the service This agentified service provides the opportunity to browse a book selling site and buy books there {\em providedBy} describes the provider of the service. CongoBuy 412 268 8780 412 268 5569 Bravo@Bravoair.com somewhere 2, OnWeb, Montana 52321, USA http://www.daml.org/services/daml-s/2001/05/CongoBuy.html In the next section the profile specifies additional attributes of the service. These are attributes like quality guarantees, service constraints like geographic radius and so on. {\em geographicRadius} specifies whether there is a limitation on the distribution of the service. By restricting the geographicRadius to United States, we specify that the service will not be offered to requesters outside this area. This field is used either by the register during matching, or by the requester to decide whether to use this service. {\em qualityRating} specify the quality of the service provided. For now it is just a placeholder. This field is used either by the register during matching to make sure that the quality requested is matched, or by the requester to decide whether to use this service. The next section of the profile is a set of attributes for describing key elements of the process that this profile is a characterization of. The four key elements of the process model that may want to be described are the input parameters required for use of the process model, the outputs (data coming back from the service provider), and perhaps key constraints to consider when deciding whether to use the service (the preconditions and conditional effects of the process). The profile uses a somewhat different way to describe inputs and outputs than does the process model, as it is not directly describing the process actions. The property profile:input is used to describe each key input to the corresponding process, by using as values the descriptions of the class class profile:ParameterDescription. ParameterDescriptions name the corresponding parameter properties of the process, and their value restrictions. Currently, due to limitations of the DAML language, there is no logical relationship between ParameterDescriptions in the Profile and the actual input, output, etc. parameters of the corresponding process model. Therefore, at least in theory, the two descriptions may be inconsistent. Nevertheless, the intended use of these descriptions is to correctly characterize the key parameters of the process model so that potential clients can properly find offered services that meet their needs. {\em input} refers to inputs to the process model. Each input require a name and a restriction to what information is requested and a reference to the process model input used. There are no logical constraints between the inputs in the process model and the inputs in the profile model, therefore, at least in theory, the two sets may be totally unrelated. Nevertheless, it is at advantage of whoever advertises the service to be truthful on the information reported, because it increases the likelihood that the service will be selected to satisfy the needs of a requester. An input parameter is described by a name, a restriction on its values, and a reference to the input parameter in the profile it represents. The value restriction is used during matching to check whether the inputs that the requester is willing to provide match what the provider needs. The requester uses the inputs to know what additional information it needs to provide to the service to have a successful run. Outputs are represented similarly to inputs. As with the inputs the restriction is used by the web register to specify whether the service provides the outputs that are expected by the requester. The requester uses the outputs to know what additional knowledge it will acquire from the service. Preconditions and effects have a structure similar to the structure of inputs and outputs. The main difference is that instead of a restriction to some class they have a statement which are defined as daml:Thing. Preconditions and effects are used by the registry in a way that is similar to the inputs and outputs. Furthermore, the requester uses preconditions to make sure that indeed it can run the service; while it uses effects to know what will result after the interaction with the service completes. Finally, close the description of the service.