- From: NMP-MSW/Tampere <patrick.stickler@nokia.com>
- Date: Sun, 16 Nov 2003 10:40:13 +0200
- To: "ext Arjohn Kampman" <arjohn.kampman@aduna.biz>
- Cc: Damian Steer <pldms@mac.com>, Jeen Broekstra <jeen@aduna.biz>, "Seaborne, Andy" <Andy_Seaborne@hplb.hpl.hp.com>, "'Steve Harris'" <S.W.Harris@ecs.soton.ac.uk>, www-rdf-interest@w3.org, sesame-devel@lists.sourceforge.net
On Friday, Nov 14, 2003, at 17:35 Europe/Helsinki, ext Arjohn Kampman wrote: >> I should add that I did consider returning graphs rather than variable >> bindings, which has the virtue that the results are >> unambiguous. However this, in my case, was essentially useless as I >> was trying to retrieve information from a graph, and returning a graph >> seemed a little perverse. > > Amen. This is exactly why SeRQL offers both: you need table-like query > results in the end because otherwise you stuck with graphs forever. > Well, for those manipulating the knowledge expressed in the graph, one eventually needs a means of extracting particular nodes, but I don't agree that that necessarily requires a table-like query result. There are many ways to accomplish that in an API without resorting to tables. I'm not against variable binding tables. I use them daily. I just wanted to point out that, since we're talking here within the context of standardization and requirements, that how one manipulates a graph returned as the result of a query need not absolutely involve a table of bindings. You're quite right that, at somepoint, you have to go beyond the graph and get at the individual nodes. But tables are only one way to do that. I'd like to see the graph manipulation/consumption part left out-of-scope by an RDF query standard so that APIs are free to optimize as they like. There may later arise a standardized API for manipulating RDF graphs, to aid in software portability and integration (e.g. an RDF "DOM") but there is IMO no hard dependency between a standardized language for expressing queries, the execution of which returns subgraphs of the kb queried, and a language for manipulating graphs to do particular things with particular nodes. I think the industry is well ready to standardize the former, but not yet (if ever) the latter. Cheers, Patrick
Received on Sunday, 16 November 2003 03:43:04 UTC