I think that dropping this outweighs the inconvenience of having to
create a separate profile.
I am a fan of separation of concerns, especially in the early stages.
Opera's point of view goes in the direction of potentially increasing
the uptake for this technology.

Furthermore I think it would be a good think for companies and
organizations to create profiles that describe them. This information
could be used all over the place.

What I cannot judge is if we loose flexibility by limiting the RDF in
POWDER docs.
However, I think this ability may well be reserved for future versions


> -----Original Message-----
> From: 
> [] On Behalf Of Phil Archer
> Sent: Wednesday, September 24, 2008 3:59 PM
> To: Public POWDER
> During Monday's telecon, it was agreed that all WG members 
> should have a chance to express an opinion on the issue of 
> whether or not we allow unrestricted RDF to be included 
> within POWDER documents. Specifically this affects:
> 1. The ability to include FOAF/DC info within the document as 
> opposed to separately
> 2. The ability to include arbitrary RDF in the descriptor sets.
> This issue is flagged as a Feature at Risk within the Formal doc [1]. 
> Opera has made the case for dropping this feature [2] - i.e. 
> *requiring* all POWDER documents to be attributed to an 
> entity described in a separate file and limiting the 
> expressivity of descriptor sets to literal values and RDF resources.
> Opera's principal reason for asking for this to be dropped is 
> that for some applications, processing of POWDER purely as 
> XML is possible without the need for an RDF processor to be 
> included. Such applications include the mobile device 
> paradigm where processing power, memory etc. 
> are limited.
> Vodafone has indicated support for this position [3].
> In the other corner is NCSR who argue that requiring an 
> external FOAF file (or its DC homologue) is an unnecessary 
> burden on POWDER authors (as evidence, Ivan H points out that 
> W3C doesn't have a FOAF file). 
> Limiting the expressivity of POWDER by design goes against 
> natural best practice (I paraphrase - Stasinos/Antonis may 
> wish to correct me).
> I am keen to get this resolved no later than Monday's call. 
> If you have a view, please express it on this list.
> Thanks.
> Phil.
> [1]
> [2] 
> [3] 
> --
> Phil Archer
> Chief Technical Officer,
> Family Online Safety Institute
> w.
> Register now for the annual Family Online Safety Institute 
> Conference and Exhibition, December 11th, 2008, Washington, DC.
> See

Received on Thursday, 25 September 2008 08:59:29 UTC