On 12/29/08 1:19 PM, Kjetil Kjernsmo wrote:
All,
I'm trying to do something analogous to this example from the SPARQL spec:
http://www.w3.org/TR/rdf-sparql-query/#namedAndDefaultGraph
which I have now gotten working, but I'd like to do a DESCRIBE. Now, the
problem is that the client doesn't know the graph names, but it what kind of
graph it is. Thus, I have inserted the following
INSERT DATA INTO GRAPH<http://msone.computas.no/graphs/> {
<http://msone.computas.no/graphs/instance/nfi> a
<http://msone.computas.no/graphs/vocab/mediasone#InstanceGraph> . }
i.e. http://msone.computas.no/graphs/ is my default graph and
http://msone.computas.no/graphs/instance/nfi is the graph where the triples
I'm interested in are.
My simplest test query is
DESCRIBE<http://www.wizardis.com.au/2005/12/MAVIS#TitleWorkkey48739> FROM
NAMED<http://msone.computas.no/graphs/instance/nfi>
Now, analogous to the example in the SPARQL spec, I would like to DESCRIBE
this URI, but using an IFP to identify it rather than directly name it. Since
the client doesn't know the graph URI, I would rather reference it
by :InstanceGraph, like this:
DESCRIBE ?uri WHERE { ?g a
<http://msone.computas.no/graphs/vocab/mediasone#InstanceGraph> .
GRAPH ?g { ?uri<http://www.computas.com/mediasone#coverArt>
<http://ruby3.computas.no/covers/nfi/48739.jpg> . } }
this returns no result, so I try two things:
SELECT ?uri WHERE { ?g a
<http://msone.computas.no/graphs/vocab/mediasone#InstanceGraph> .
GRAPH ?g { ?uri<http://www.computas.com/mediasone#coverArt>
<http://ruby3.computas.no/covers/nfi/48739.jpg> . } }
This returns the correct URI, so the solution is OK. Then I do:
DESCRIBE ?uri FROM NAMED<http://msone.computas.no/graphs/instance/nfi>
WHERE {
?g a<http://msone.computas.no/graphs/vocab/mediasone#InstanceGraph> .
GRAPH ?g
{
?uri<http://www.computas.com/mediasone#coverArt>
<http://ruby3.computas.no/covers/nfi/48739.jpg> . }
This returns the desired result.
So, it seems that the match is OK, but to get the actual data from a DESCRIBE,
I have to explicitly name the graph. Which creates problems on the client
side... I have to admit that I am a bit confused about graph naming.
Does this problem have a more trivial solution?
The endpoint where all this runs is a public test endpoint at
http://msone.computas.no:8890/sparql
Kind regards
Kjetil Kjernsmo
Kjetil,
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) ;
Ideally, you could use a new Virtuoso instance for this and proceed as
follows:
1. Instantiate new instance
2. Run command: alter table RDF_QUAD modify primary key (S,P,O,G)
3. Load RDF data
Otherwise, you can do it against the existing instance, but it will take
a while to complete.
The other option in the pipeline is the addition of VoiD triples
(automatically) that connect each resource URI to its Graph IRI. This
will then enable clients to de-reference the Graph IRIs from the
description of a resource when executing DESCRIBE <resource-URI> etc..
Graph IRIs are Local or Internal Identifiers of the Containers of
Triples. The Named Clause when used in conjunction with the Graph IRI or
?<var> (e.g. ?g) delivers graph specificity to associated graph patterns.
I must admit, reading the specs can be confusing re. these matters :-)
--
Regards,
Kingsley Idehen Weblog: http://www.openlinksw.com/blog/~kidehen
President& CEO
OpenLink Software Web: http://www.openlinksw.com
