Kjetil, I'm afraid I have on easy way to make this behavior for DESCRIBE. If you need that then you really had to write a CONSTRUCT instead of DESCRIBE.
One of problems is that in PREFIX ms: <http://www.computas.com/mediasone#> DESCRIBE ?uri FROM <http://msone.computas.no/graphs/> WHERE { ?g a <http://msone.computas.no/graphs/vocab/mediasone#InstanceGraph> . GRAPH ?g { ?uri ms:coverArt <http://ruby3.computas.no/covers/nfi/48739.jpg> . } } it is DESCRIBE ?uri FROM <http://msone.computas.no/graphs/> in its core, the rest does not patter as soon as the result set is retrieved. If you don't want to restrict DESCRIBE with single graph <http://msone.computas.no/graphs/> then it should be DESCRIBE ?uri WHERE { GRAPH <http://msone.computas.no/graphs/> { ?g a <http://msone.computas.no/graphs/vocab/mediasone#InstanceGraph> . } GRAPH ?g { ?uri ms:coverArt <http://ruby3.computas.no/covers/nfi/48739.jpg> . } } I'm sorry I have no idea how to make DESCRIBE smarter. Best Regards, Ivan Mikhailov OpenLink Software http://virtuoso.openlinksw.com On Mon, 2009-01-05 at 13:26 +0100, Kjetil Kjernsmo wrote: > Hi Kingsley and thanks for the response! > > On Monday 29 December 2008 22:19:01 Kingsley Idehen wrote: > > If possible, you can just rebuild the RDF_QUAD table with a different > > primary key, and once done the overhead associated with not specifying a > > graph IRI in the FROM clause re. Virtuoso goes away courtesy of the > > column order (and associated re-indexing) in the revised primary key. > > The command for altering the primary key is: > > alter table db..RDF_QUAD modify primary key (S,P,O,G) ; > > I must admit that I do not appreciate the full depth of what you are saying > here. I have done a little more research though, and before diving further > into your suggestion, I'd like to raise another point. > > DESCRIBE isn't well specified, and I hope to join DAWG NG to share my > experiences. Let us nevertheless see if we can agree on what is the most > intuitive result. > > For example, I'd expect the result of this query: > > PREFIX ms: <http://www.computas.com/mediasone#> > DESCRIBE ?uri > FROM <http://msone.computas.no/graphs/> > WHERE { > ?g a <http://msone.computas.no/graphs/vocab/mediasone#InstanceGraph> . > GRAPH ?g > { > ?uri ms:coverArt <http://ruby3.computas.no/covers/nfi/48739.jpg> > . > } > } > > To return the same as this query: > > > PREFIX ms: <http://www.computas.com/mediasone#> > CONSTRUCT { ?uri ?p ?s ; > ms:coverArt <http://ruby3.computas.no/covers/nfi/48739.jpg> . > } > FROM <http://msone.computas.no/graphs/> > WHERE { > ?g a <http://msone.computas.no/graphs/vocab/mediasone#InstanceGraph> . > GRAPH ?g > { > ?uri ?p ?s ; > ms:coverArt <http://ruby3.computas.no/covers/nfi/48739.jpg> > . > } > } > > The latter query returns what I'd expect from them both, whereas the former > has no result (I've set the default graph both as above, and with a protocol > query parameter). Again, this can be tested live at > http://msone.computas.no:8890/sparql > > So, then you might say "just use the construct and be done with it, then", > but > that will create troubles later, when I want to set a LIMIT, since I want to > limit on the number of unique subject URIs, which is what the DESCRIBE in > practise, whereas the CONSTRUCT would limit on the number of solutions, and I > don't know how many of them I'd like. Also, the CONSTRUCT is arguably more > complex (for the programmer) than the DESCRIBE query. > > Kind regards > > Kjetil Kjernsmo
