SPARQL query to SELECT available Named Graphs

[danielbakas (Daniel B.)]

Hi!!

Quick question on working with Named Graphs

I was performing this query in Stardog Studio

SELECT DISTINCT ?graph
WHERE {
  GRAPH ?graph {
    ?s ?p ?o
  }
}

And I got an empty result, even though our database has many named graphs with many resources.

If I switch to a known named graph and perform a query without the GRAPH term, that works:

But using the GRAPH term does not work.

Is this expected?

Thanks!

[pavel (Pavel Klinov)]

Hi Daniel,

you should define the dataset for the query: either by adding FROM NAMED stardog:context:local or by choosing that stardog:context:local in the graph drop-down list.

Cheers,
Pavel

[danielbakas (Daniel B.)]

Hi @pavel!

The FROM and FROM NAMED queries worked without the GRAPH clause. But using the GRAPH clause still doesn't seem to work.

Might I be missing something?

Here's a screenshot of one failed test I did with the FROM NAMED with the GRAPH clause:

Thing is, I do have data in multiple named graphs as shown in the same SELECT query without the GRAPH clause:

Looking forward to your thoughts.

Thanks!!

[pavel (Pavel Klinov)]

I suggest the following:

• remove FROM NAMED from the query
• select context:local in the drop-down list
• un-toggle reasoning (just to rule out a reasoning-related issue)
• re-run your query with GRAPH and also show its query plan.

Best,
Pavel

[danielbakas (Daniel B.)]

Hi @pavel!

• I removed FROM NAMED from the query
• I selected stardog:local in the drop-down list
• I un-toggled resoning
• And I re-run my query with the GRAPH

Here is the query result:

And here is the query plan:

Looking forward to your thoughts.

Thanks!

[pavel (Pavel Klinov)]

There's something strange with your IRIs: it should be stardog:context:local, not stardog:local. Maybe some of your graphs in the data use the reserved IRIs, or something like that. Can you execute

select * from named <tag:stardog:api:context:local> { graph ?g { ?s ?p ?o } }

using the command line interface (i.e. stardog query execute)?

[danielbakas (Daniel B.)]

Hi @pavel!

That's only because I added the @prefix stardog: tag:stardog:api:context: to my namespaces.

This is how the result of the suggested query, and my list of named graphs looks without the namespace:

It works in the CLI though:

Looking forward to your thoughts.

Thanks!

[danielbakas (Daniel B.)]

Hi @pavel!

I noticed something.

If I select the database dev but do not select any named graphs, and I perform the query, then it works:

But as soon as I select any named graph it stops working:

Hope this is useful

[pavel (Pavel Klinov)]

Hi Daniel,

OK, I have reproduced the issue and can explain what happens. In SPARQL, the set of graphs (default or named) that your query accesses consists of two parts:

• the default part: the graphs that triple patterns outside of graph ?g { .. } match
• the named part: the graphs that triple patterns inside graph ?g { .. } match.

the default part is defined using FROM. the named part is defined using FROM NAMED. Your query is correct: it uses graph ?g and thus defines the graphs using FROM NAMED. Stardog backend also handles it correctly, this is why CLI returns the expected results.

However, when you select stardog:context:all (or anything) in Studio's drop-down list, it defines the default scope using HTTP parameters (as defined in the SPARQL Protocol spec). That spec requires that if different datasets are specified in the query string and in the protocol request, then the latter takes precedence (see 2.1.4 in SPARQL 1.1 Protocol).

What this effectively means is that Stardog gets a query that is functionally equivalent to

select * 
from <tag:stardog:api:context:named> {
  graph ?g { ?s ?p ?o }
}

(from instead of from named) and that must return the empty results.

Hope this helps,
Pavel

[danielbakas (Daniel B.)]

Hi Pavel!

Thank you for that! I made a couple of tests and all but one worked!

1. If I do not select any named graphs from the drop down, this query works:

SELECT *
WHERE {
    GRAPH ?g {
        ?s ?p ?o .
    }
}

2. Also, if I try this without selection, this works as well:

PREFIX stardog: <tag:stardog:api:context:>
SELECT *
FROM NAMED stardog:named
WHERE {
    GRAPH ?g {
        ?s ?p ?o .
    }
}

3. Finally, if I select a named graph from the drop down, and remove the GRAPH ?g, that also works.

This solves my original question, so thank you so very much!

4. Last question for this thread would be, would you be so kind as to provide an example for a FROM query? It is the only one I couldn't get.

Thanks again!

[pavel (Pavel Klinov)]

Re: your tests:

1. it works because by default (that is, there're no FROM or FROM NAMED keywords in the query), the backend is free to choose the dataset. In Stardog the dataset depends on the value of the query.all.graphs database option. If you didn't change it, the dataset in this case would be tag:stardog:api:context:default for the default part and tag:stardog:api:context:named for the named part. I.e. the query is functionally equivalent to FROM <tag:stardog:api:context:default> FROM NAMED <tag:stardog:api:context:named>. For your query only FROM NAMED is relevant since the pattern is inside graph ?g.
2. Now your query defined the dataset: the default part is empty but the named part is <tag:stardog:api:context:named>. Only the latter is relevant and the query works again.
3. That's right: now since you removed graph ?g, the triple pattern matches data in the default part of the dataset. That is specified either in the query itself (that'd be FROM) or in the drop-down list. You chose the latter.

PREFIX stardog: <tag:stardog:api:context:>
SELECT *
FROM stardog:local
WHERE {
        ?s ?p ?o .
}

that should work too (from CLI or Studio wiithout selecting anything in the drop-down list).

Cheers,
Pavel