- From: Seaborne, Andy <Andy_Seaborne@hplb.hpl.hp.com>
- Date: Wed, 5 Nov 2003 10:41:25 -0000
- To: www-rdf-rules@w3.org
> What do you mean with merging in this context? Only that if you want a single graph (I don't mind if that graph has partitions - graphs don't have to be a single connected region) that is the set of all triples matching the query, not each solution. That is, merge the sepoarate solutions together because that gives you a smaller subgraph of original that has the same query results. Suppose I have 10 properties p1 (different values!) and 10 properties p2. The query (<x> <p> ?x) (<x> <p2> ?y) has 100 binding combinations but only 20 triples. I wondered if there is a well known faster algorithm for calculating the matching subgraph (the 20 triples) than finding 100 binding combinations. Andy -------- Original Message -------- > From: Jeen Broekstra <mailto:jeen@aduna.biz> > Date: 4 November 2003 14:55 > > Seaborne, Andy wrote: > > I'm not quite clear on the query: > > > > Does this query give a sequence of "graphlets", one per soltuion > > to the FROM clause, or a single graph of all the triples from all > > the solutions? > > It returns a single result set, consisting of statements that match > the from clause. It's not necessarily a single graph because the > results from different matches may well be disconnected, but there > is no explicit support for identifying these individual matches, if > that's what you mean: you get one set of statements that contains > all answers. > > > Another sort fo related question: in the case where the result of > > a query is a subgrapgh of the original, does anyone know of any > > literature describing algorithms for this subgraph calculation > > that is faster than simply taking each solution and merging (that > > can lead to a lot of unnecessary work)? > > Now I'm confused :) What do you mean with merging in this context? > Filtering duplicate statements? If so, then I can't help you with > literature refs from the top of my head, but we have implemented > this by pushing a DISTINCT modifier down to the SQL engine to filter > out duplicate variable-binding combinations, and an additional > triple filter on top of that. We haven't spent too much time on > optimizing this, but sofar it has not given us any serious > performance problems. Of course this approach is only used when the > user specifies a DISTINCT modifier in the SeRQL query, so it might > just not have come up yet :) > > Cheers, > > Jeen
Received on Wednesday, 5 November 2003 05:45:44 UTC