W3C home > Mailing lists > Public > www-rdf-rules@w3.org > January 2004

Re: !

From: Patrick Stickler <patrick.stickler@nokia.com>
Date: Thu, 8 Jan 2004 13:25:19 +0200
Message-Id: <574F053E-41CD-11D8-8AD0-000A95EAFCEA@nokia.com>
Cc: "ext Eric Prud'hommeaux" <eric@w3.org>, Brian McBride <brian.mcbride@hp.com>, www-rdf-rules@w3.org
To: "ext Seaborne, Andy" <Andy_Seaborne@hplb.hpl.hp.com>

On Jan 08, 2004, at 13:01, ext Seaborne, Andy wrote:

>> I would like to see in the charter some indication that the
>> conveyance of results, whether subgraph and/or bindings, be
>> in RDF/XML -- i.e. that we eat our own dog food, and also,
>> having the results as RDF/XML minimizes the infrastructure
>> required to process results (parsers, APIs, etc.) and allows
>> query execution to be pipelined, with the results of one
>> query serving as the kb for subsequent queries, etc.
> I agree.  Results should be in RDF/XML - I would hope this would come 
> out in
> the requirments stage so I would not mandate it as the only format but 
> it
> should be the default one.

Right. I was speaking mostly in terms of limiting the WG's focus,
rather than the resulting specification, per se.

I wouldn't expect that other forms of expression would be
prohibited, but I don't think the WG should focus on anything
but RDF/XML.

I.e., the current RDF specs define only RDF/XML as an official
serialization for interchange of RDF graphs, and say nothing about
other serializations for interchange (as opposed to test cases),
but that doesn't prevent most RDF tools from also supporting N3,
N-Triples, etc.

Likewise, if the DAWG limits its focus solely to RDF/XML output,
that does not preclude tools providing other forms of expression
for query results.

What I would not like to see happen is time spent on defining
a non-RDF/XML output format as a standardized alternative.

i.e. keep it simple, and keep the WG focus tight, lean and mean...




Patrick Stickler
Nokia, Finland
Received on Thursday, 8 January 2004 06:41:26 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:46:17 UTC