Missing query results

0 views
Skip to first unread message

jrh...@thematix.com

unread,
Jun 19, 2015, 4:16:54 PM6/19/15
to sta...@clarkparsia.com
I have two queries that differ only in the filter restrictions. The more restrictive of the queries returns the correct result while the less restrictive query returns nothing.
Here's the more restrictive query: SELECT DISTINCT ?s ?p ?o ?op ?ot WHERE { ?s ?p ?o . ?o ?op ?ot FILTER (?s = nm-tr:RelationshipManager && ?p = rdfs:subClassOf) }
Here's the less restrictive query: SELECT DISTINCT ?s ?p ?o ?op ?ot WHERE { ?s ?p ?o . ?o ?op ?ot FILTER (?s = nm-tr:RelationshipManager ) } - returns nothing
I do not understand how adding a filter predicate caused Stardog to find a binding that it was unable to find previously.
As you can see in the results, ?o should have bound to bnode .bnode_5f216aed_42e5_4515_811f_5473cabb63d0_849 in the second query as it did in the first.
Below are the queries and JSON results. After the JSON result of the query that returned nothing is the query plan. SELECT DISTINCT ?s ?p ?o ?op ?ot WHERE { ?s ?p ?o . ?o ?op ?ot FILTER (?s = nm-tr:RelationshipManager && ?p = rdfs:subClassOf) }

{
  "head" : {
    "vars" : [ "s", "p", "o", "op", "ot" ]
  },
  "results" : {
    "bindings" : [ {
      "s" : {
        "type" : "uri",
      },
      "p" : {
        "type" : "uri",
      },
      "o" : {
        "type" : "bnode",
        "value" : "bnode_5f216aed_42e5_4515_811f_5473cabb63d0_849"
      },
      "op" : {
        "type" : "uri",
      },
      "ot" : {
        "type" : "uri",
        "value" : "http://www.w3.org/2002/07/owl#Class"
      }
    }, {
      "s" : {
        "type" : "uri",
      },
      "p" : {
        "type" : "uri",
      },
      "o" : {
        "type" : "bnode",
        "value" : "bnode_5f216aed_42e5_4515_811f_5473cabb63d0_849"
      },
      "op" : {
        "type" : "uri",
      },
      "ot" : {
        "type" : "bnode",
        "value" : "bnode_5f216aed_42e5_4515_811f_5473cabb63d0_850"
      }
    } ]
  }
}

SELECT DISTINCT ?s ?p ?o ?op ?ot WHERE { ?s ?p ?o . ?o ?op ?ot FILTER (?s = nm-tr:RelationshipManager ) }
{
  "head" : {
    "vars" : [ "s", "p", "o", "op", "ot" ]
  },
  "results" : {
    "bindings" : [ ]
  }
}

SELECT DISTINCT ?s ?p ?o ?op ?ot WHERE { ?s ?p ?o . ?o ?op ?ot FILTER (?s = nm-t
r:RelationshipManager ) }

The Query Plan:

Distinct [cardinality=0]
  Projection(?s, ?p, ?o, ?op, ?ot) [cardinality=0]
sentation/RelationshipManager> AS ?s)) [cardinality=0]
      MergeJoin[?o] [cardinality=0]
radeRepresentation/RelationshipManager>, ?p, ?o){all} [cardinality=8.2K]
        Scan[SPOC](?o, ?op, ?ot){all} [cardinality=8.2K]


Evren Sirin

unread,
Jun 23, 2015, 12:22:04 AM6/23/15
to Stardog
I'm guessing you are using reasoning which would explain the behavior
because the pattern {CLASS ?p ?o} would only return (?p=rdf:type,
?o=owl:Class) with reasoning. But when you ask {CLASS rdfs:subClassOf
?o} you get all the superclasses. We might improve this behavior in
the future.

Best,
Evren
> --
> -- --
> You received this message because you are subscribed to the C&P "Stardog"
> group.
> To post to this group, send email to sta...@clarkparsia.com
> To unsubscribe from this group, send email to
> stardog+u...@clarkparsia.com
> For more options, visit this group at
> http://groups.google.com/a/clarkparsia.com/group/stardog?hl=en

jrh...@thematix.com

unread,
Jun 23, 2015, 2:57:45 PM6/23/15
to sta...@clarkparsia.com
That is not the case - reasoning is turned off because I only want immediate parents in the case of this query. The problem seems to occur in part because I added a pattern ?o ?op ?ot to capture the rdf:type of the parent, which can either be owl:Class or owl:Restriction. My original query is a bit more complicated than this one, but I was able to simplify it to this query to illustrate the problem. I can attach the query plan for the query that worked if that would help.


Evren Sirin

unread,
Jun 23, 2015, 3:23:22 PM6/23/15
to Stardog
Ok, yes, I see that the query plan you shared actually shows the
problem. This looks like a bug in the query planner related to inlined
variables. We created ticket #2362 for this issue. In the meantime,
there are several possible workarounds: 1) Use the constant in the
query directly and optionally use a BIND clause to bind ?s to that
value 2) Use VALUES instead of FILTER 3) Do not use the constant in
the query directly and pass it as an extra binding. In CLI, this would
look like:

bin/stardog query -b "s=<...URI...>" -- test "select * { ?s ?p ?o . ?o ?op ?ot}"

Best,
Evren

jrh...@thematix.com

unread,
Jun 23, 2015, 4:45:05 PM6/23/15
to sta...@clarkparsia.com
One of the reasons why I am using FILTERS is that there is a case where the filter predicate is a disjunction that allows the results to contain multiple bindings for ?s. The original query is used repetitively to retrieve the DAG structure of superclasses for a given class. The DAG has a single root that is the starting point, and the query looks for the next set of superclasses for all of the classes at distance n away from the root. The workaround would cause a separate query for every class in the DAG. BIND does not let me do this. I tried to use VALUES, but that does not produce results for the case where the value is a bnode. I understand that SPARQL does not require an implementation that permits bnodes to be treated as IRIs, but both BIND and FILTER work with bnodes, so I assumed that Stardog supported treating bnodes as IRIs except in the VALUES clause. IWBNI bnodes would work in the VALUES clause also.

Yeah, the query does some of the same reasoning that Pellet does, But, I can't build the DAG from the reasoning results - that is why I am doing this query.

Bottom line is that I am going to have to wait for you to fix this as the workaround would cause too much wreckage in my existing code. Any predictions?
Reply all
Reply to author
Forward
0 new messages