How to get pystardog to construct from a named graph with virtual transparency on

Support
1

Hi everybody,

I am using pystardog to perform a constructs (or select) on a named graph. Using Studio, the construct query returns results in about 1.5 seconds, while pystardog timesout.

Here is the form of the construct call:

CONSTRUCT {    
GRAPH <urn:foo> {
?s ?p ?o.
?s2 ?p2 ?o2.
}}
WHERE{
?s :predefined_predicate ?s2.
?s ?p ?o.
?s2 ?p2 ?o2.

}

In studio, I have the db and the named graph selected in the Workplace tab. If I did not select the named graph in the gui, and instead queried from tag:stardog:api:context:all (virtual transparency is on) with the above construct call, it also timed out.

In pystardog, I ran the above construct call through:

 with stardog.Admin(**conn_details) as admin:
        db= admin.database('db')

        with stardog.Connection('db', **conn_details) as conn:
            conn.begin()

            resultsconstruct=conn.graph(sparql,limit=100)

            conn.end()

It times out independent of the limit on the number of triples returned.

does anyone know how to solve this issue?

2

I should note that the named graph urn:foo was constructed from virtual graphs and it is not itself a virtual graph.

Further, I noted that the query plan in studio (from what I could tell) did not change when adding or removing the named graph, GRAPH urn:foo{...}, from the query in either case (context:all or the named graph foo selected in the worksheet). Changing between context:all and named graph in the worksheet did change the query plan. Context:all utilized the virtual graphs rather than being overridden by the GRAPH urn:foo call.... likely because virtual transparency is on.

3

I'm having a hard time following exactly what you did, what the expected out come was and what you result you actually got. Can you be a little more explicit about what exact queries you ran with what options. What version of Stardog are you running? Are there any errors or warnings in stardog.log?

4

Okay.... I guess I solved it...? I turned virtual transparency to false and I was able to query in pystardog without changing anything else. Is this truly the desired functionality of virtual transparency = true? Shouldn't the logic be to check if a call has been constrained to query from a particular graph rather than querying from all of the transparent virtual graphs first? If virtual transparency is on, shouldn't there be a way to override this in the sparql query?

5

What exact functionality are you referring to? I'm still having difficulty following your description of the problem. It would help if you could expand on what "this" is in your question. There should be no difference between a query in Studio and a query in pystardog so I would not characterize the difference as the desired functionality of the virtual transparency feature. It's more likely a problem with either the way you're using pystardog or pystardog itself.

6

I turned virtual transparency to false and I was able to query [the named graph directly] in pystardog without changing anything else.

hope that helps!

7

Hi All,

I am continuing this post. I really need to have virtual transparency on but there is no way to change the query plan from pystardog such that pystardog queries straight from the specified named graph urn:foo instead of querying through the virtual graphs and ignoring the named graph completely. Studio has this capability because one may change the query plan with the gui:

image
image1166×72 8.13 KB

8

I think it would be more helpful if you explained what you want to do and how what you're seeing differs from what you expect. It's probably just casual use of the term query plan but Studio is changing the query which changes the query plan to match but there isn't a way to modify the query plan directly.

If I understand your question correctly I have I related question. How does virtual transparency interact with the use of FROM and FROM NAMED. My expectation would be that the use of a FROM clause overrides virtual transparency and effectively turns that feature off for that query but that's just conjecture. Have you tried including a FROM NAMED clause in your query?

I've always found the use of FROM and FROM NAMED a little confusing especially when you combine it with query.all.graphs. ex. FROM overrides the default graph. If you have just a FROM NAMED what is the default graph? empty? same as it was before? I think it's empty but I'm never confident about that answer.

9

Kevin,

I am able to reproduce an issue (returning no results) using a CONSTRUCT query and two variable predicates (?p and ?p2) joined. If I turn on VT then I get results. If I modify the query like this:

CONSTRUCT {    
GRAPH <urn:foo> {
?s ?p ?o.
?s2 ?p2 ?o2.
}}
FROM <virtual://theVg>
WHERE{
?s :predefined_predicate ?s2.
?s ?p ?o.
?s2 ?p2 ?o2.
}

or

CONSTRUCT {    
GRAPH <urn:foo> {
?s ?p ?o.
?s2 ?p2 ?o2.
}}
WHERE{
    GRAPH <virtual://theVg> {
       ?s :predefined_predicate ?s2.
       ?s ?p ?o.
       ?s2 ?p2 ?o2.
    }
}

I also do not get results. I'm looking into a fix now.

I'm not clear on what feature is available in Studio that isn't in pystardog. The drop-down with the named graphs is equivalent to including FROM NAMED in your query. Are you saying you need pystardog to support that in the API?

-Paul

10

I don't know if this helps, but here is my situation:

I have a db that I created with virtual transparency on. I then used that db and some virtual graphs to hit a postgres db and constructed a named graph, urn:foo.

I would then like to perform a construct (or select) query on the named graph I created *without instantiating the virtual graphs as they would hit the postgres db again. If i write the call

CONSTRUCT {    
GRAPH <urn:foo> {
?s ?p ?o.
?s2 ?p2 ?o2.
}}
WHERE{
?s :predefined_predicate ?s2.
?s ?p ?o.
?s2 ?p2 ?o2.

}

and click show plan

image
image1154×163 9.34 KB

then there is a simple query plan that hits the named graph.

If instead I do not have urn:foo selected (i.e i put it on ...context:all) and show plan, then it involves unions of the vgs because vg transparency is on. The query plan does not change in this case if I use FROM NAMED urn:foo or GRAPH urn:foo (seemingly) anywhere in the sparql body, which seems at odds with

Do you see a similar issue?

11

Are there any updates on the above post?

Also:

The feature that seemingly available in studio is to bypass the virtual graphs (while virtual transparency is on) and query a named graph directly (as could be seen from the query plan) while pystardog seems to always go through the virtual graphs when virtual transparency is on even knowing they are not needed (in my case) to query the named graph.

12

Paul, I think that we had an error in our query and are testing a solution now.

Will let you know....

Andrea

13

Hi Kevin,

Just saw this.

The named graph <tag:stardog:api:context:local> can be used to prevent queries from accessing virtual graphs.

It doesn't look like pystardog exposes the option to set the dataset.
I'm looking at https://pystardog.readthedocs.io/en/latest/source/stardog.html#stardog.connection.Connection.select and there should be a couple options for setting the default-graph-uri and named-graph-uri. I'll create a ticket for that.

-Paul

1 Like
14

Thanks Paul, this is great.

It may make sense to add a similar ticket for connection.graph in case one is interested in constructing named subgraphs from a named graph.

15

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.