Reasoning via set graph

Support Bug
1

Hi. I have Stardog 4.2.4, and i created two named graph (urn:graph1, urn:graph2). When i run query to first graph with reasoning, i see inferences both graphs.

First graph set query:

insert data {
    graph <urn:graph1> {
        <urn:Class1> a owl:Class .
        <urn:Class2> a owl:Class .

        <urn:Class1> rdfs:subClassOf <urn:Class2> .
    }
}

Second graph set query:

insert data {
    graph <urn:graph2> {
        <urn:class3-0001> a owl:NamedIndividual .
        <urn:class3-0001> a <urn:Class3> .
    }
}

Query with first graph:

select * from <urn:graph1> where {
	?subClass <tag:stardog:api:property:directSubClassOf> ?class .
}

Result:

subClass		class

<urn:Class1>	<urn:Class2>
<urn:Class3>	owl:Thing
owl:Nothing		<urn:Class1>
owl:Nothing		<urn:Class3>
<urn:Class2>	owl:Thing

Why the result is present urn:Class3? This is a bug?

2

Can you describe what part of the output is causing the confusion?

3

Graph 1 not includes info about urn:Class3. I have many graphs and in each graph different data and rules.

4

I can see how that would be a little confusing. I’d have to look closely at the specs to see if that’s correct or not but I’ll let someone else who is more knowledgeable jump in. It might be correct if the extracted TBOX is added to the context of the query as possible solutions.

5

If i set TBOX to only urn:graph1, that result remains the same.

6

Once extracted, the schema is global for the database and results of the schema queries, including triple patterns with the special predicates, are not affected by FROM, FROM NAMED, or GRAPH clauses in the query.

We’ll improve the documentation to make this clearer.

Cheers,
Pavel

7

When you say you set TBOX to only urn:graph1 do you mean that you set the reasoning.schema.graphs to urn:graph1 or was there something about your query that you thought was restricting the TBOX?

Pavel, if they set reasoning.schema.graphs to urn:graph1 is there a possibility that Stardog is not re-extracting the schema when that option is being changed?

8

This option can only be set when the database is taken offline first. Schema should be re-extracted when the database is brought back online.

The schema is still global though, even when it’s extracted from a subset of named graphs. AFAICT, this the thing that causes confusion here.

Cheers,
Pavel

9

I gave the example provided a try and tried setting reasoning.schema.graphs to urn:graph1 and when running the query provided

select * from <urn:graph1> where {
?subClass <tag:stardog:api:property:directSubClassOf> ?class .
}

get back urn:Class3 which is only contained in urn:graph2 which seems odd.

10

Seems like graph IRIs are lost from your last message.

11

Whoops, it looks like the angle brackets are picked up as markup.

I gave the example provided a try and tried setting reasoning.schema.graphs to <urn:graph1>and when running the query provided

select * from <urn:graph1> where {
?subClass <tag:stardog:api:property:directSubClassOf> ?class .
}

get back <urn:Class3> which is only contained in <urn:graph2> which seems odd.

12

Yes, there’s another thing going on here.

In addition to loading axioms and rules, Stardog also extracts class and property names which aren’t explicitly declared and don’t occur in TBox axioms. For example, :s rdf:type :A implies that :A is a class (under the RDFS semantics). Stardog runs queries against the full database to extract such untyped terms, and that’s how <urn:Class3> ended up in the schema.

I agree that ignoring reasoning.schema.graphs while doing it could be confusing because some parts of the schema (albeit trivial) come from outside of the schema graphs. OTOH, running such queries against the schema graphs would be useless in many cases since data is often stored separately from the schema.

I’ll create a ticket to provide more options to either disable this behavior or restrict it to particular graphs.

Cheers,
Pavel