RE: Zen & Chinwag

> -----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