- From: Danny Ayers <danny@panlanka.net>
- Date: Mon, 16 Apr 2001 12:32:43 +0600
- To: <johan.hjelm@nrj.ericsson.se>
- Cc: "Stuart Naylor" <indtec@eircom.net>, <www-rdf-interest@w3.org>
<- I hate to say this over and over, but CC/PP is exactly what you <- describe: A <- metadata framework for agent description. In the WAP context <- (since they are the <- only ones to develop a metadata vocabulary, they are the only <- ones we know <- about) it works exactly as you describe: The profile of the <- client is matched <- against the profile on the server (that for instance describes <- the document). CC/PP is *not* exactly what I describe, though there is considerable overlap. I'm not sure what you mean about saying it over and over - is this a future intention? I must admit my earlier opinion of CC/PP was largely coloured by scanning rather than thoroughly reading the CC/PP specs [1, 2, 3, 4], largely becoause much of these emphasise profiling the 'user agent' (a recurring phrase), and focuses on a narrow range of applications (e.g. supplying data in a suitable format for mobile devices). This 'user agent' is nothing like the the generic 'process' I've been talking about (though it could be seen as a specific instance). After some re-reading of the CC/PP docs, I can still identify significant differences between the intended role of this and what I had in mind with RPP [5]. To quote the abstract of [1] : "In this document we describe a method for using RDF, the Resource Description Framework of the W3C, to create a general, yet extensible framework for describing user preferences and device capabilities. This information can be collected into a profile and provided by user agents to servers and content providers. The user's preferences and the capabilities of the user's agents can be used to customize a service or content provided by a service." If I'm not very mistaken, what is being profiled by CC/PP is user preferences & the capabilities of their agents, and this profile is for use by a service provider to customize services. What I was primarily aiming for was a profile of the *services*. Ok, I'm sure it could be argued that CC/PP is capable of doing what I'm talking about - but my point there would be that CC/PP is really geared up for telling services the kind of content or service the client wants, rather than describing what the service does in general terms. Ok, taking your WAP example - as you say, the profile of the client is matched against the profile on the server (that for instance describes the document). The end result in this instance is exactly the same using CC/PP as in manner I'm suggesting. Similarly the use of proxies in CC/PP to chain transcoding operations is the same in principle as referring-on that I suggested. The difference really lies in the emphasis - CC/PP strikes me as being very content-orientated (i.e. data) rather than service-oriented (i.e. process). The profile seems to be about what a particular agent (usually a client, 'user agent') can handle, rather than what that agent (client/service/process) can *do*. If my client wants to e.g. convert a gif image into a png, then what is important is the required process (transforming a into b) and the input and output data formats (gif & png). Whether or not my client can view gif or png images (potentially parts of the CC/PP profile) is irrelevant. I believe CC/PP was an attempt to solve a specific set of real-world problems, typified by the requirement to supply data in an appropriate format to clients with differing capabilities (it looks like it has been successful in this). However, as with many such problem-solving activities, the scope expanded back to generalize the system. Due to this expansion, I'm willing to accept that CC/PP could potentially be used to profile processes as I'm suggesting with RPP. But I would say approaching the problem from a more general case (that of processes), and then narrowing to a specific case (e.g. WAP content provision) stands a better chance of producing a system that can be applied to other cases in a 'natural' fashion. I'm currently thinking the way forward is to purloin some of the better features of CC/PP (and WSDL for that matter) and incorporate them into the RPP schema. [1] http://www.w3.org/TR/CCPP-struct/ [2, 3, 4] etc [5] http://www.isacat.net/citnames/2001/04/rpp.htm
Received on Monday, 16 April 2001 02:36:24 UTC