Re: PROPOSED RESOLUTION on Arbitrary RDF in POWDER

I wanted to separate out my own view on this issue from the proposal e-mail.

Having begun work on a POWDER Processor, I've got a long way without any 
RDF processing. I will need to add it in order to parse external FOAF 
files but the basic PP conformance requirements do not call for any RDF 
ability [1]. For that reason, I support the resolution to drop this feature.

I have another reason too, though. Since this work began way back, Dan 
Brickley and others have been saying things like "it matters what you 
want to express" and "avoid blank nodes." The semantics are strained by 
our use of it and arbitrary RDF in a POWDER doc can break it if we're 
not careful [2].

[1] 
http://keg.icra.org/cgi-bin/processor.cgi?u=http://www.example.com/home.html&d=&list=http://keg.icra.org/powder_examples/example_2_1.xml

[2] http://lists.w3.org/Archives/Public/public-xg-wcl/2006Jun/0000.html

Phil Archer wrote:
> 
> 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] http://www.w3.org/TR/2008/WD-powder-formal-20080815/#status
> [2] http://lists.w3.org/Archives/Public/public-powderwg/2008Sep/0020.html
> [3] http://lists.w3.org/Archives/Public/public-powderwg/2008Sep/0022.html
>

Received on Wednesday, 24 September 2008 14:06:57 UTC