Hello Lorena,
I'm thinking about this feature, but it's useless without good
optimization and at the same time the optimization is quite
sophisticated there. So the "request_count/effort" ratio stays low and
the feature is regularly postponed.
As an example of troubles to be solved, consider
select *
from construct { ?s <p1> ?o1 ; <p2> ?o2 ; <p3> ?o1 }
from <g1> where { ?s <p13g1> ?o1; <p2g1> ?o2 }
where
{ { ?s <p1> <o1-sample> }
union
{ ?s <p2> <o2-sample> } }
For { ?s <p1> <o1-sample> }, the optimizer should check all constructor
templates and select templates that can create triples that can match
the pattern. Only { ?s <p1> ?o1 } is selected. Now the body of the
construct should be reduced to the smallest template that will generate
same set of { ?s <p1> ?o1 } triples as the original, but faster. It's
not a trivial thing BTW, and it should compose
from <g1> where { ?s <p13g1> ?o1 . filter exists {?s <p2g1> ?o2} }
Note that ?o1 should be equal to <o1-sample> in order to match the
triple pattern of the main query. So a mixed computation should be
performed to benefit from this knowledge. After this nontrivial
transformation, the constructor body should become
from <g1> where { ?s <p13g1> <o1-sample> . filter exists {?s
<p2g1> ?o2} }
Similarly,
?s <p2> <o2-sample>
should reduce construct template to single { ?s <p2> ?o2 }
and construct body to
from <g1> where { ?s <p2g1> ?o2 . filter exists {?s <p13g1> ?o1} }
and then to
from <g1> where { ?s <p2g1> <o2-sample> . filter exists {?s
<p13g1> ?o1} }
Finally, everything should be turned into single query
select ?s
where
{ { graph <g1> {
?s <p13g1> <o1-sample> . filter exists {?s <p2g1> ?o2} } }
union
{ graph <g1> {
?s <p2g1> <o2-sample> . filter exists {?s <p13g1> ?o2} } }
}
...if it were simpler, we'd rather implemented it years ago :|
Best Regards,
Ivan Mikhailov
OpenLink Software
http://virtuoso.openlinksw.com
On Tue, 2012-01-03 at 17:17 -0200, lorena wrote:
> Hi!
>
> I would like to dynamically populate graphs with the results of a
> query, and be able to store these graphs and reuse them in further
> queries.
> This could be accomplished, for example, If I could store a CONSTRUCT
> query and use a reference to this graph in other queries.
> I do not want to statically store the results of the CONSTRUCT query,
> because I want this new graph to reflect changes in the underlying
> graphs.
>
> Is this possible in Virtuoso?
>
> As far as I know Virtuoso implements something called RDF views, but
> this provides an RDF representation of relational data and is not what
> I need.
>
> Any help will be appreciated
> Thanks in advance
>
>
> --
> Lorena Etcheverry
> ------------------------------------------------------------------------------
> Write once. Port to many.
> Get the SDK and tools to simplify cross-platform app development. Create
> new or port existing apps to sell to consumers worldwide. Explore the
> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
> http://p.sf.net/sfu/intel-appdev
> _______________________________________________ Virtuoso-users mailing list
> Virtuoso-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/virtuoso-users
