- From: Johan Hjelm (NRJ) <Johan.Hjelm@nrj.ericsson.se>
- Date: Mon, 16 Apr 2001 14:44:31 +0800
- To: "'Danny Ayers'" <danny@panlanka.net>
- Cc: Stuart Naylor <indtec@eircom.net>, www-rdf-interest@w3.org
> -----Original Message----- > From: Danny Ayers [mailto:danny@panlanka.net] > Sent: Monday, April 16, 2001 3:33 PM > To: johan.hjelm@nrj.ericsson.se > Cc: Stuart Naylor; www-rdf-interest@w3.org > Subject: RE: Zen & Chinwag > > > <- 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? > "Over and over" was not only on this list... > 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*. CC/PP is not *just* a client-side framework, even if that is the use case we describe. It can as well be applied to server-side profiles, i.e. exactly what you describe. It is a framework, after all. What you would need to do would be to define a vocabulary. > > 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 > > > > Any standard is the result of compromises. If you want to see your system used outside research, please try to use CC/PP and tell us why it did not work, so we can fix it. I believe the overlap is big enough for them to converge, if that is what is required. Johan
Received on Monday, 16 April 2001 02:45:00 UTC