Modular Content Personalization Service Architecture for E-Commerce Applications

Transcription

1 Modular Content Service Architecture for E-Commerce Applications Susanne Boll Multimedia Information Systems Institute for Computer Science and Business Informatics Vienna University, Austria Abstract Personalized Web portals are becoming more and more popular. What is unsatisfying with existing sites is that the scope of the personalized content they provide is typically that of the underlying site. Providers of such personalized content typically develop their own, proprietary personalized Web portal. To use different personalization features of different sites users have to hop from one personalized site to another and provide different user profile information there. Therefore, we propose a flexible architecture in which a personalization mediator acts as a broker of modular personalization services between providers of personalized content and users that are interested in such personalized content. In this architecture, the providers of personalized content publish their personalization services via a unified interface to this mediator. A user provides its profile information to the mediator which in turn finds and calls the most suitable service which finally delivers the most targeted personalized content. The benefit of our approach is that users get an easier and unified access to a notional unlimited collection of personalization services by the mediator. For the providers, the approach allows different sites with different personalization capabilities to embed their personalization services in a generic infrastructure for applications like personalized Web portals. 1 Introduction is seen as one of the key issues in Customer Relationship Management, and consequently affects the interaction of E-Commerce companies with their customers on the Web. Though we are still at a hype, there is a clear awareness for personalized content and products, technologies are evolving and developing, and consulting companies have been jumping onto that topic for quite a while. In this paper, we are concerned with technological aspects of Web personalization for E-Commerce applications. Current solutions that provide personalized content over the Web to their users, can be very roughly classified into two groups: MyPortals and Recommendation Systems. My- Portals subsume Web portals that personalize the content of a content provider for registered users such as MyYahoo! by Yahoo! Inc. The typical portals we find, however, personalize only their own content, i.e., the content that is owned or under contract. The personalization is typically initiated by a manual selection of the information and services of interest and the provision of some personal information. Recommendation systems recommend information or products to users such that they may use or buy this information or product. They typically employ collaborative-filtering algorithms to select those products and information that are most suitable for a user. Recommendation systems underly sites like that of the online book retailer Amazon.com or the movie recommendation system MovieLens provided by the University of Minnesota. With the first and, admittedly, very interesting and attractive solutions available so far, we see the following open issues for users and providers of personalization services that need to be solved: What if the users would like to have different personalized sites under one roof? To use the different personalization features that are offered by different sites the users have visit each site separately and provide different profile information there. User may also need to maintain this different profile information at the different sites. What if users would like to get a personalized offer but prefer to stay anonymous at first hand? Users are nowadays worring about their privacy and are reluctant of revealing their full identity. Personalized sites, however, offer the personalization service only after the users identification. The more sophisticated the personalization functionality is, the more information about the users needs to be provided.

2 This is a user profile and some privac y inform ation This is a user profile and some privac y inform ation This is a user profile and some privac y inform ation This is a user profile and some privac y inform ation What about providers that offer some personalization features but not enough to make customers to (re)visit their site for these features? Smaller sites that offer a simple level of personalization or customization are only visited by chance or if the user explicitly accesses it. So far it is not possible to easily embed such a smaller personalization service in a larger Web portal. What about providers that want to offer their personalization services to different portals? To be part of a portal a personalization service would need a kind of gateway or wrapper to be part of the portal. Consequently, for a participation in different portals this would have to be specifically developed for every single portal. What about portal providers that want to provide a flexible infrastructure to plug and run personalization services? So far each portal provider develops an own proprietary personalization architecture. Addressing these needs of users and providers of personalized services, we propose a modular personalization service architecture that integrates personalization features of different sources under one roof for the user s satisfaction and the provider s advantage. The central contribution of this work is the design and development of concepts for such an architecture. The remainder of this paper is organized as follows: Section 2 motivates and introduces the concept of our modular personalization service architecture. This architecture is elaborated in more detail in Section 3 which presents the single steps and solutions needed for registering and using personalization services in the proposed architecture. A short overview of the related work in the field is given in Section 4. We summarize the concepts of the architecture and the benefits for users and providers in Section 5. 2 Overview of the proposed architecture for modular content personalization services In the introduction, we pointed out the limitations of existing personalized Web portals and motivated the need of an architecture in which a collection of different personalization services from different sources is integrated by one personalization mediator. This mediator takes in the providers s personalization services of different origin and complexity and provides them in a modular fashion to the user or user application, respectively. In the following, we given an overview of the personalization service architecture and a simple application example. Overview of the architecture. In the proposed architecture, as illustrated in Figure 1, personalization service providers offer some kind of personalization capability. The personalization services of the different providers are registered at the mediator which collects descriptions of the Service Provider Services Personalized Web Portal request & receive Mediator M Profile & Privacy Information Service Registry find & call register & respond Service Provider Services service descriptions This is a user profile and some privacy information Profile & privacy profile & privacy information Service Provider Services Figure 1. Architecture for modular personalization services services in a personalization service registry. Via a personalized Web portal, a user requests personalized content under a certain privacy policy from the personalization mediator. Based on the available user and privacy information the personalization mediator searches the most suitable service from the personalization service registry. The actual service is called and responds with the personalized content which is finally received by the user s personalized Web Portal. Simple application example. For a personalized Web portal, content providers and online retailers such as an online bookstore, weather services on the web, online news magazine, sports Web sites provide their personalization services to the personalization mediator as well as the services parameters, syntax, protocol, and semantics. Practically, this could be the URL of a cgi-bin script, the parameters the script takes for the personalization task and a set of keywords describing the service. The mediator stores this information in its registry. The personalized Web portal provides the mediator with user information like place of living, general interest, and favorite sports and also the preferred privacy policy. The mediator uses this user information and the semantic service description to find for the most suitable service in the registry. Once the service is found, the mediator maps the user profile information to the service s parameters, e.g., the topics of interest to the parameters of the personalized news service, or the user s location(s) to the parameters of the weather service. Then the actual call of the service is created, e.g., URL with the service parameters, and sent via the specified protocol, e.g., HTTP, to the personalization service provider. The result is delivered to the Web portal, e.g., in HTML.

3 3 The personalization service architecture at work Having introduced the general idea of the personalization service architecture, we are now concerned with a closer look onto the single concepts needed for the proposed architecture. The central tasks of the architecture, and specifically of the mediator are the registration of personalization services at the mediator, the provision of user profile and privacy information to the mediator, and the actual usage of the mediator as a personalization service broker which are discussed in the following sections. 3.1 Service registration This section is concerned with the steps for providers to register personalization services at the mediator. First an overview of the single steps needed for service registration is given before we come to actual solutions and concepts needed for an actual realization of the mediator to sufficiently support the service registration. Overview. Figure 2 illustrates the single steps needed for the service registration. The personalization mediator provides the service provider with a ontology for the actual service description (1). With this common ontology the service provider and the mediator base on the same vocabulary for the service description. Equipped with the ontology the personalization service provider assembles a service description that is sent to the mediator (3). Additionally, the personalization service provider is provided with the schema definition of the user profiles at the mediator (2). With the user profile schema definition the service provider can describe the mapping from the user profile information to the service s parameters. Coupled with the information about transport protocol and request syntax the binding information is complete and also registered with the mediator (4). Also, the personalization provider must provide its privacy policy to the mediator (5). This information is needed as the service provider later will receive user profile information with the requests from the mediator and needs to describe how it is going to treat this data. The mediator inserts the complete service registration information into the personalization service registry (6) and possibly the providers privacy policy. Technological solutions needed. In the following, we present the solutions needed en route to support the single steps as introduced above and illustrated in Figure 2. Please note that the numbering of the paragraphs follows the numbering in Figure Provision of an ontology for semantic service description to the provider The aim of the personalization service provider is to offer a service to the mediator that is frequently used by the system s users afterwards. For this the mediator should have sufficient knowledge about the service and its functionality to be able to find and select the services most suitable to the user s needs. Therefore a semantic description of the personalization service is needed. However, for such a description the mediator and the service provider need to share a common understanding of the terms and concepts involved in the semantics of the service. Otherwise, service retrieval on behalf of the user is difficult, as it was left to the mediator to dynamically discover or derive a services semantics and make sure that it uses it correctly. The use of a common, domain specific ontology is a well accepted concept in applications that want to search across or merge information between users and providers [15] such as the mediator and the personalization service providers. For the selection of such an ontology, the mediator and the service provider can agree on a standard like the general Universal Standard Products and Services Classification (UNSPSC) [1] or existing domain-specific ontologies. For the development of an ontology for the description of the personalization services one can create a concept graph on the base of RDF-schema [4] or Topic Maps [13]. For the actual electronic exchange of the ontology of choice between the mediator and the service provider an XML-based representation of the ontology can be used. 2. Provision of user profile schema description to the provider User profile information is needed for two important tasks in the architecture. On the basis of user profile information the mediator searches and finds suitable services for user and the service providers describe the mapping between profile entries and their service s parameters. There is a lot of research done and underway in the area of user models describing users for specific domains or to describe specific user features and behaviour. However, when it comes to the mere exchange of profile information (Web-based systems) rely on hierarchically structured (XML-based) descriptions of user profiles like CPEX [3], CC/PP [16] and as was proposed with OPS [12]. A standard for the exchange of user profile information with good extensibility features we see is the evolving, RDF-based W3C standard Composite Capabilities/ Preference Profile (CC/PP) [16]. Even though the CC/PP base schema is limited to the description of an end user s hard and software capabilities, it can be extended through the introduction of new attribute vocabularies. Consequently, mediator s user profile schema description is to be developed as a specific Composite Capabilities

4 Personalized Web Portal User A Provide: privacy policy of A with M Provide: user profile schema description Send: user profile information of A Mediator M Service Registry 6 10 insert: Service registration of X privacy of M insert: User Profile of A Profile & Privacy Store Provide: ontology for service description Provide: user profile schema description Register: semantic service description for X Register: mapping & binding to personalization service X Provide: privacy policy Service Provider Service X Figure 2. service registration and user profile and privacy provision / Preference Profile (CC/PP) vocabulary [14] which is described by a corresponding RDF schema [4]. Employing XML as the exchange syntax, the mediator provides such user profile schema description to the personalization server provider. 3. Provision of semantic personalization service description to the mediator A semantic personalization service description of the service is used by the mediator used to search and find most suitable services for the users/applications of the system. As explained before, for a reasonable retrieval of personalization services from the registry, the semantic information about the services needs to be provided along an ontology which is common to the service provider and the mediator. For the actual semantic description of a service the service provider selects that set of concepts from the ontology that best describes the service. This implies that the ontology is designed carefully to meet the application domain and the personalization features of the service. For example, a personalized weather service could be associated with concepts like weather and national or a personalized book information service with books and modern art. This set of concepts is delivered from the personalization service provider to the personalization mediator. The exchange format used for the exchange of the semantic service description is XML-based. 4. Provision of mapping and binding information to the mediator The mapping and binding information addresses the aspects of how to map the user profile information to the right service parameters and how to bind the service request to the communication protocol and transfer syntax of the personalization service. For the mapping of the user interest and preferences to the actual service s parameter the mediator needs to know that, e.g., the home location of the user matches the place of the weather service, or the interest in modern art to the title parameter of the book recommendation service. We do not believe in an automatic mapping from user profile information to the services parameters by either the mediator or the service provider. We understand that the use of personalization services can be successful only if the personalization really meets the user. This can only be the case if, on the way from the user to the service provider, none of the so valuable user information is lost. Therefore, the mediator exposes the user profile structure to the provider which in turn provides the most suitable (n:m) mapping of the user profile entries to the service s parameters. The description format of the mapping is a set of pairs that map the entries of the user profile to the corresponding service parameter, described in an XML document. The binding information describes how the call from the mediator to the personalization service looks like. This comprises information about the service location, the protocol, the format of the call, the syntax of the call, the format and the syntax of the result. For a simple call to a cgibin script this would means that the service provider specifies the URL of the cgi-bin script, the name of the script, the parameter names, HTTP as the protocol and HTML as the result. The Web Service Definition Language (WSDL) [5] is the language of choice to describe the binding of the personalization services. The so called binding element of WSDL includes supported operations, as well as the input and output for each operation. The bindings provide concrete information of what protocol is being used, how the data is being transported, and where the service is located. Mapping and binding information are transferred to the personalization mediator and stored in the registry. 5. Provision of privacy policy by the provider to the mediator As the mediator has access to the personal information about its clients and hands over part of this information to the service providers first and foremost there must be an agreement between the three of them how to deal with privacy issues. The privacy policy of a personalization service

5 provider describes how the provider will treat the information it receives about the user. This privacy policy must be compliant with the privacy policy the user negotiates with the personalization mediator which is also discussed below in Step 7. The solution to be employed for this is the P3P standard [7] that provides the formats by which two parties, a client and a server, describe and enforce their privacy policy. The mediator requests the privacy policy from the personalization service and compares it with user s privacy policy. After an agreement about common privacy policies the mediator uses the service. Following the P3P protocol, the exchange of privacy policies would have to be carried our for every personalization service call. For frequent uses of the service, however, a storage of the provider s policy at the mediator for negotiation purposes is reasonable. We assume that Steps 1 to 5 are not necessarily carried out automatically but rely on an exchange of the information before the actual usage of the personalization services. It might be interesting to look at the Conversation Definition Language (CDL) [11] for the sequence of the exchange of XML-based documents between mediator and service provider. 6. service registration at the mediator The registry is the place that manages and provides service information. The mediator inserts the information about the service into the service registry. Each service becomes a unique entry in the registry. The semantic description of the personalization services is used to associate the service with the respective concepts in the ontology. Additionally the binding information and the privacy policy information are stored in the registry and the profile and privacy storage. For the mere storage of a service s binding information, if described with WSDL, a UDDI registry can be employed. The remaining management of service semantics, privacy policies, and mapping information, however, is not covered by a UDDI registry and is modeled and implemented so far separately. We are currently evaluating the ebxml registry information model [9] for its applicability for managing the complete service information accumulating at the mediator. 3.2 User profile and privacy policy provision. This section is concerned with the steps for users to provide their profile information and their privacy policy. First an overview of the single steps needed for service registration is given before we come to actual solutions and concepts needed for an actual realization of the mediator to sufficiently support the service registration. Figure 2 illustrates the single steps needed for the user profile and privacy policy provision. Overview. As the users have to provide personal information to the mediator it is of high importance that they negotiate their privacy policy with the personalization mediator (7), i.e,. how this profile information is to be treated by the personalization service provider. For the provision of the actual profile the user or the user application, respectively, gets the user profile schema from the mediator (8). With this information the user can provide the respective profile information to the mediator (9) which in turn inserts it into the user profile store (10). The actual storing of the profile information is not mandatory the profile information can be provided to the mediator for each request if this is preferred. Technological solutions needed. In the following, we present the solutions needed en route to support the single steps as introduced above and illustrated in Figure 2. Please note that the numbering of the paragraphs follows the numbering in Figure Provision of privacy policy of the user In our proposed architecture, a user provides a privacy policy to the mediator that describes how the mediator has to treat the user s personal information, i.e., which information of the profile can be revealed to the personalization service providers in which way. As a solution, we see the P3P standard here as this is the only satisfactory, even though criticized, development for the exchanging and establishing privacy policies. Related approaches like [10] rather address anonymization rather than the definition and enforcement of privacy policies. We propose that users specify their policy with the upcoming P3P Preference Exchange Language 1.0 (APPEL1.0) [6], i.e., how they want to have their privacy policy enforced. The P3P standard is intended for a agreeing on privacy policies between two parties. In our architecture these two parties are the user and the service provider. The mediator enforces this privacy policy on behalf of the user before mapping the user profile information to the service s parameters. Consequently, there is an additional agreement or at least trust needed between the user and the mediator that allows the mediator to actually act on behalf of the user in privacy policy issues according to a P3P privacy policy. 8. Provision of user profile schema description to the user To provide the personalization services with the necessary user information, the personalization component needs access to user profile information. As discussed in Step 2, the mediator defines a user profile schema and the parameter mapping for the service request. The user profile schema description is provided to the user which then knows which information the mediator needs to carry out the personalization tasks. The schema description can identify mandatory and optional entries not to dismay and detain the user in the

6 first place. With this provision the user reveals profile information following a common user profile schema only to one singular mediator to use a entire set of personalization services. 9. Receive user profile information from the users Employing a CC/PP vocabulary as the model of choice for user profiles, the user application provides its CC/PP client profile to the mediator. Following the CC/PP standard, a client profile will typically contain references to default profiles describing a range of common capabilities for the client concerned (e.g., particular model of mobile device), and values that are variations from the default profile. The exchange of profile information can be realized using the CC/PP exchange protocol based on HTTP Extension Framework and sending a user profile schema compliant XML document. 10. Insert user profile information into the user profile store The actual storage of the profile depends on the selected technology for the user profile store. For example a commercial XML storage solution can be employed. As mentioned before, this step is not mandatory Usage of the personalization services This section is concerned with the steps of actually using the personalization service via the mediator. Figure 3 illustrates these single steps. Overview. Once the system is equipped with services and registered users, requests for personalization services can be issued. Figure 3 shows how the architecture works when the services are used. The user application provides a description of the desired service or names the service explicitly. This request is sent to the mediator (11). With this information the personalization mediator queries the user profile information for the user s profile and privacy information (12). Note: The user s profile need not necessarily be stored at the mediator but could also be delivered with the request. Then the mediator queries the personalization service registry for a suitable service (13). For this the semantic service description is exploited. Once a service is found the mediator maps the user request and profile information to the service s parameters (14). The mapping information has already been provided during the registration and has also been inserted into the registry. With the mapping and binding information the actual call to the personalization service is generated and issued to the service provider (15). The corresponding personalized content is created by the provider and delivered to the user application (16). Technological solutions needed. In the following, we present the solutions needed en route to support the single steps as introduced above and illustrated in Figure 2. Please note that the numbering of the paragraphs follows the numbering in Figure Request for personalization service The personalization mediator provides a Web service request interface to the personalized portal. The service request itself contains a description of the desired personalized content. This description is preferably also ontology based, the same ontology which the service providers use to classify their services. Another solution would be a set of natural language keywords that are provided to the mediator. This makes efficient retrieval of suitable service difficult. The request also contains the reply to address as this is needed for the delivery of the personalized content (see Steps 15 and 16). 12. Retrieve profile and privacy information from the user profile store For the service request mapping the mediator retrieves the user s profile from the user profile store. The mediator provides accesses the user profile store to read out the user profile and the user s privacy policy. The actual access method and the result depends on the selected technology for the profile storage and profile format. Note: For maintenance of profiles and privacy policies the mediator needs to provide an interface to the user to check and (re)-submit user profile information. 13. Retrieve service description from the personalization service registry Furthermore, the mediator s service registry supports the search of services in the registry according to their semantic description. This means to search along the ontology for service descriptions. An open issue here is of how to find the best match(es) within the services if more than one suitable service is found in the registry. With the result from search in the ontology the registry also delivers the necessary mapping and binding information for the next step. 14. Enforce privacy policy In this step, before actually generating the request, the privacy policy of the user is enforced. The request is only generated and sent to the service providers if the P3P policies of user and provider match, i.e., the user s APPEL rule set must evaluate to true with regard to the service providers P3P policy. 15. Generating the service request With the mapping specification at hand the mediator takes the profile information retrieved in Step 12 and maps the user information to the service parameters. It is just mapping that makes the mediator so valuable to the users

7 Personalized Web Portal User A 11 Request: personalization service Mediator M Service Registry 13 retrieve: service description of X 14 enforce: privacy policy for using X 12 retrieve: profile & privacy of A 15 Generate: service request X Service Provider Service X Profile & Privacy Store 16 Deliver: personalized content Figure 3. service usage and the service providers as this goes far beyond the mere mediation of Web services. By means of the mapping information, specified in Step 4, the users profile information is best matched to the services capabilities. The actual mapping process exploits this description. The mapping goes together with actually binding the service request to transport syntax, protocol, etc. The resulting request for the usage of the personalization service is issued to the provider. It is important to note that the reply address is not the mediator but the user application. 16. Delivery of personalized content The personalized content is delivered directly to the customer. The type of result is not specified, the handling of the result is left to the user application. This has the advantage that the personalization service can not only send a personalized Web page but also a personalized video stream or multimedia presentation. 4 Related Work Our focus is on service integration for the special field of services that provide personalized content in response to information about the user. The mediator architecture is responsible for selecting the suitable service and the mapping from profile to service parameters. The expected result is personalized content best matching the user profile information There are many approaches related to ours with regards to the concepts and technology we employ. For example, existing MyPortals, standards for the semantic description of Web services, user profile modeling, privacy issues, communication protocols, and registries. These have already been addressed in Section 3. In the following, we refer to the very few approaches that more or less aim at an integrated view/access to personalized content. The approach MyOwnWeb [2] more or less addresses the same idea as ours but with a different, not at all flexible and generic solution. The information about the personalization services is extracted by MyOwnWeb and not provided by the service providers. Everything has to be selected and configured manually, there is no mediating functionality or flexible service integration. The Lucent Personalized Web Assistant (LPWA) [10] provides aliases to its users. By these aliases it achieves anonymous access to personalization sites. A mediating functionality and a mapping of user profile parameters to service parameters, however, is not at all part of the system. With Web Services for Remote Portals [8] IBM has just recently proposed an architecture in which different Web services from different providers can easily be employed by a Web portal. The specification defines only a limited predefined set of attributes for the description of services. The usage and exploitation of user profile information is, if at all part of the request to the intermediary application, left to the service provider. 5 Conclusion The hype in personalization so far did only lead to different Web sites that offer different personalization features that are differently accessed. The next step must, from our point of view, be a rather modular and flexible architecture. In this paper, we have been proposing such an architecture for providing and using modular personalization services from different providers via a personalization mediator. The architecture proposed provides an infrastructure for the unified provision to the different personalization services at a mediator. User profile information follows one general schema for the entire set of services available at the mediator. Semantic service descriptions along an ontology at the

8 mediator and the available user profile information achieve that the user s profile and request can best be best mapped to the most suitable service and its parameters. We have been discussing the solutions needed to realize the architecture. We have been developing a very first prototype in the context of the development of a new Web site for our institute. The focus of the prototype was to gain first experiences with both the usage and the implementation of such an architecture. Equipped with these results we are currently reviewing the system and redefine the components developed and interfaces chosen for an revised prototype. One of the major benefits for the user of applications based on the proposed architecture is that users do not need to change the site for accessing different personal services. The users profit from the anonymizing effect the personalization mediator has as the user s identity need not necessarily be revealed to the provider. The profile information has to be provided and maintained only once to access a number of different personalization services. Service providers find an architecture in which they can adjust to once and then easily provide their services to mediators of choice without additional implementation effort. The same applies to portal providers as the flexible architecture allows a kind of plug and run of additional services. Being part of different Web portals proposed architecture service extends the service provider s scope of potential customers. service providers with little or few personalization services can obtain a visibility they probably would not have not be able to attain on their own. As the personalization mediator trades the personalized services from the providers to the users and provides user information to personalized content providers. The valuechain in this process must be investigated in more detail to elaborate a suitable business model. References [1] Universal Standard Products and Services Classification (UNSPSC). URL: [2] V. Anupam, Y. Breitbart, J. Freire, and B. Kumar. Personalizing the Web Using Site Descriptions. In Proceedings of the 10th International Workshop on Database and Expert Systems Applications, Florence, Italy, August 30 - September [3] K. Bohrer and B. Holland. Customer Profile Exchange (CPExchange) Specification Version 1.0, October URL: 0F.pdf. [4] D. Brickley and R. Guha. Resource Description Framework (RDF) Schema Specification 1.0. W3C Candidate Recommendation, World Wide Web Consortium (W3C), URL: , Mar [5] E. Christensen, F. Curbera, G. Meredith, and S. Weerawarana. Web Service Description Language (WSDL) 1.1. W3C Note 15 March 2001, World Wide Web Consortium (W3C), URL: Mar [6] L. Cranor, M. Langheinrich, and M. Marchiori. A P3P Preference Exchange Language 1.0 (APPEL1.0). W3C Working Draft 15 April 2002, World Wide Web Consortium (W3C), URL: Apr [7] L. Cranor, M. Langheinrich, M. Marchiori, M. Presler- Marshall, and J. Reagle. Platform for Privacy Preferences (P3P) Project. W3C Working Draft 28 September 2001, World Wide Web Consortium (W3C), URL: Sept [8] A. L. Diaz, P. Fischer, C. Leue, and T. Schaeck. Web Services for Remote Portals (WSRP). Note 21 January 2002, International Business Machines Corporation, URL: ibm.com/developerworks/webservices/library/wswsrp/, Jan [9] ebxml Registry Project Team. ebxml Registry Information Model v1.0. DRAFT STANDARD, UN/CEFACT and OASIS, URL: May [10] E. Gabber, P. Gibbons, D. Kristol, Y. Matias, and A. Mayer. Consistent, Yet Anonymous Web Access with LPWA. Communications of the ACM, 42(2), [11] K. Govindarajan, H. K. A. Karp, D. Beringer, and A. Banerji. Conversation Definitions: defining interfaces of web services. In World Wide Web Consortium Workshop on Web services: Position papers, San Jose, CA, USA, April [12] P. Hensley, M. Metral, U. Shardanand, and D. Converse. Proposal for an Open Profiling Standard. W3C NOTE - Submitted to W3C on 02 June 1997, World Wide Web Consortium (W3C), URL: FrameWork.html, June [13] ISO/IEC JTC 1/SC34/WG3. ISO/IEC 13250:2000 Topic Maps. IS, International Organization for Standardization (ISO), [14] G. Klyne, F. Reynolds, C. Woodrow, and H. Ohto. Composite Capability/Preference Profiles (CC/PP): Structure and Vocabularies. W3C Working Draft 15 March 2001, World Wide Web Consortium (W3C), URL: Mar [15] E. Mena, V. Kashyap, A. Sheth, and A. Illarramendi. Domain specific ontologies for semantic information brokering on the global information infrastructure. In Proceedings of the First International Conference on Formal Ontologies in Information Systems. Trento, Italy. June 1998, June [16] F. Reynolds, J. Hjelm, S. Dawkins, and S. Singhal. Composite Capability/Preference Profiles (CC/PP): A user side framework for content negotiation. W3C Note 27 July 1999, World Wide Web Consortium (W3C), July 1999.